2012-2013 第二学期 11本 UML 第三章 用例和用例图
UML用例和用例图
h
18
主要内容
基本概念：Use case、Actor、
Scenario Use case间的关系 Use Case 分析技术 案例讲解
h
19
关系
• 参与者与用例之间
– 关联关系
• 用例与用例之间
– 包含关系 (include) – 扩展关系 (extend) – 泛化关系 (generalization)
• 主事件流： • 1、系统显示ID和密码窗口； • 2、顾客键入ID和密码，然后按OK键； • 3、系统验证顾客ID和密码，并显示个人信息窗口； • 4、顾客键入姓名、街道地址、城市、邮政编码、电话号码，然
后按OK键； • 5、系统验证用户是否为老顾客； • 6、系统显示可以卖的商品列表； • 7、顾客在准备购买的商品图片上单击，并在图片旁边输入要购
• 用例结束后的系统状态
• 其他需要描述的内容
用例描述原则：尽可能写的“充分”，而不是追求写的形 式化、完整或漂亮。
h
32
h
33
书写用例文档
——路径交互步骤的描述
只书写“可观测”的 使用主动语句 句子必须以执行者或系统作为主语 每一句都要朝目标迈进 分支和循环 不要涉及界面细节
h
34
书写用例文档
买的数量。选购商品完毕后按Done按钮； • 8、系统通过库存系统验证要购买的商品是否有足够库存； • …….（后续描述省略）
问题：对用户界面的描述过于详细，对于需求文档来说， 详细的用户描述对获取需求并无帮助。
h
45
改进后的描述
• Use Case：Buy Something • 参与者：Customer • 主事件流： • 1、顾客使用ID和密码进入系统； • 2、系统验证顾客身份； • 3、顾客提供姓名、地址、电话号码； • 4、系统验证顾客是否为老顾客； • 5、顾客选择要购买的商品和数量； • 6、系统通过库存系统验证要购买的商品是否有足
第3章 用例图
为了保证系统正常运行，谁将对系统进行维护管理
（副参与者）？ 谁将完成系统数据的录入、导出及修改等工作（主 动参与者）？ 谁或什么系统对系统产生的结果感兴趣（被动参与 外部系统进行交互？ 在预定的时间，是否有事件自动触发？ 系统从何处获取信息？
（2）参与者不一定是人，也可以是一个外部系统， 该系统与本系统相互作用。代表的是一种角色。 （3）在系统的实际运作中，多个不同的用户可能 只对应于一个参与者；同时一个实际用户也可 能对应系统的多个参与者。
例如： 在“房地产开发经营管理系统”中，
所有的购房者作为一个集合，在“房屋销售子 系统”中作为购房合同的签约方出现，多个个 体在系统中担任一个参与者；同时，某个独立 的购房者在“物业管理子系统”中又作为房屋 的业主出现，同一个人在系统中担任了两类参 与者。
主参与者和副参与者
主参与者使用系统的主要功能，是使用系统较 频繁、业务量较大的用户。 副参与者处理系统的辅助功能，它与用例进行 交互的主要目的是为了给其他的参与者提供某些服 务。如管理数据库、通信、系统备份以及其他管理
等系统维护工作。
主动参与者和被动参与者
主动参与者是系统的启动者，负责启动一个或多
借阅图书用例的描述
用例名称 标识符 用例描述 参与者 状态 BorrowBook UC0001 图书管理员代理借阅者办理借阅手续 图书管理员 通过审查
前置条件
后置条件 假设 基本操作流程
图书管理员登录进入系统
如果这个用例成功，在系统中建立并存储借阅记录 图书管理员已经成功地登录到系统 1. 2. 3. 4. 5. 管理员输入借书证信息 系统验证借阅证的有效性 图书管理员输入图书信息 添加新的借阅记录 显示借书后的借阅信息
用例和用例图ppt课件
精选课件
6
参与者间的关系
▪ 在用例图中，使用泛化关系 来描述多个参与者之间的公 共行为。
▪ 示例：
父参与者
子参与者
子参与者
▪ 子参与者继承父参与者的 行为和含义，并能增加自 己特有的行为和含义
▪ 子参与者可以出现在父参
与者能出现的任何位置上
精选课件
7
3.3 用例
定义：
对一组动作序列的描述，系统通过执行这一 组动作序列为参与者产生一个可观察的结果
使用扩展关系 ▪ 扩展用例总是在一个或多个扩展点处来扩展基本用例，或
处于特定条件下， 才扩展基本用例。
基本用例
扩展点 扩展点名称
<<extend>>
扩展用例
精选课件
21
扩展关系
使用情形
a.两个用例相似但不完全相同时 b.当要对多个额外情况逐一建模时，使用扩展关
系，用一个独立的用例替代每个额外的情况 c.如果用例涵盖了所有的情况变化，则该用例将
识别用例
用例识别
识别用例最好的方法就是从分析系统的参与者开 始，考虑每个参与者是如何使用系统的。
➢ 参与者要向系统请求什么功能？
➢ 每个参与者的特定任务是什么？
➢ 参与者需要读取、创建、撤消、修改、或存储 系统的某些信息吗？
➢ 是否任何一个参与者都要向系统通知有关突发 性的、外部的改变？或者必须通知参与者关于 系统中的发生的事件？
会变得十分复杂，应该考虑使用扩展关系
精选课件
22
例
项目经理
扩展关系
项目管理系统
<<extend>> ( 任务函数)
[ 选择任务选项]
管理任务
UML用例和用例图
25
UML用例图的建模
1. 找出系统中的角色和用例。
2) 如何从系统中识别出用例 基于这些角色及其需求，通过回答前面的问题，可以建立如下用 例： 记录成绩（Record grades） 更新成绩（update grades） 生成报告卡（generate report cards） 检查报告卡（check report cards) 分发报告卡（distribute report cards ） 浏览成绩（view grades)
15
UML用例图组成
3、用例图的关联
2)用例与用例的扩展关联 例如，系统中允许用户对查询的结果进行导出、打印。对于查询而 言，能不能导出、打印查询都是一样的，导出、打印是不可见的。 导入、打印和查询相对独立，而且为查询添加了新行为。因此可以 采用扩展关系来描述：
16
UML用例图组成
3、用例图的关联
19
UML用例图的建模
1. 找出系统中的角色和用例。
创建用例图的第一项任务是找出要建立的系统模型中的角色和用例。 这项任务通常是由与潜在用户会见的系统分析员完成的。在某些情况 下，该任务还包括与顾客面对面的访谈，在访谈中可以提出问题，了 解他们的需求。访谈过程中，可以多做些记录以备后用。在另外一些 情况下，其他人会提供项目的业务需求列表。对于这些业务需求，需 要向提供者提出一些问题以得到所需要的答案。这些需求和得到的答 案将成为创建用例图的笔记。
22
UML用例图的建模
1. 找出系统中的角色和用例。
1) 如何从系统中识别出角色
23
UML用例图的建模
1. 找出系统中的角色和用例。
2) 如何从系统中识别出用例 用例的获取是需求分析阶段的主要任务之一。但对于一个大系统， 要直接列出用例清单常常是十分困难的。这时可先列出角色清单， 再对每个角色列出它的用例，问题就会变得容易得多。在识别出 了角色之后，就可以通过回答下述问题来帮助识别用例:
UML-用例图
2012年 2012年4月
UML与设计模式 与设计模式
18/60 18/60
要点2 要点2：主动语句
欧文丛贝克汉姆处得到传球，守门员 欧文丛贝克汉姆处得到传球，守门员… 贝克汉姆传球给欧文，欧文射门，守门员扑救… 贝克汉姆传球给欧文，欧文射门，守门员扑救 图书管理员…… 图书管理员 系统…… 系统
UML与设计模式 与设计模式
17/60 17/60
要点1 只写“可观测” 要点1：只写“可观测”的
系统通过ADO建立数据库连接，传送SQL查询语 建立数据库连接，传送 系统通过 建立数据库连接 查询语 商品表”查询商品的详细信息… 句，从“商品表”查询商品的详细信息 系统按照查询条件搜索商品的详细信息
2012年 2012年4月
UML与设计模式 与设计模式
13/60 13/60
用例阐述组成
用例名称 用例概述 涉及的参与者 前置条件Preconditions 前置条件 后置条件Postcondition 后置条件 事件流Flow of events 事件流 分支流Subflows 备选流Alternate flow
2012年 2012年4月
UML与设计模式 与设计模式
11/60 11/60
“Borrow Book”用例中的场景 Book”用例中的场景
如，在“Borrow Book”这个用例中，包含着几 ”这个用例中， 个相关的scenario： 个相关的 ： Scenario-1：顺利地借到书 ： Scenario-2：该种书刊不存在 ： Scenario-3：物理书刊都已借出 ： Scenario-4：没有该借阅者信息 ：
2012年 2012年4月 UML与设计模式 与设计模式
3/60
2012-2013 第二学期 11本 UML 第三章 用例和用例图
代表两个用例之间的关系， 其中一个用例（基本用例base use case）的行为包含另 一个用例（包含用例inclusion use case）的行为的关系。 例子一：
确 认
取
款
转
账
查询余额
17
§3.4.2 包含关系（续）
例子二：从基本用例指向包含用例。 基本用例：ATM System 包含用例：Identify Customer ; Validate Account
11
§3.3 脚本（scenario）
脚本又称为情景、场景、情节、剧本等 在UML中，脚本贯穿用例的一条单一路径。 脚本的定义：脚本是用例的实例(instance)。 脚本与用例之间是对象与类的关系。 例如：针对‘取钱’的用例，脚本就会有 1、正常完成取钱的脚本。 2、账户拒绝、取不出钱的处理脚本。 3、取出钱不对后的处理脚本。 但是有1、2、3、…构成了一个用例。 脚本的描述：一个脚本是用具体的文字加以描述的。
用例驱动的方法论。 用例是各种交互的动作序列之间的说明与描述。 用例的描述、表示与命名方法、规律。 用例描述的是系统功能性的需求。 理解用例之间相互关系（泛化、包含、扩展）。 脚本是用例的实例。 参与者在系统中的含义。参与者之间同样有泛化关系。 用例描述是用例的主要部分。 用例描述无统一的标准。 用例分析结果与分析人员的水平与领域知识相关
由以上例子看出： 其用例描述并无一个固定的模式可循，各自有理解和侧重， 关键是要多加练习。
25
§3.7 寻找用例的方法
用例分析可遵循的步骤：
1、找出系统外部的参与者和外部系统，确定系统的边界； 2、确定每一个参与者所期望的系统行为； 3、命名这些系统行为为用例； 4、使用泛化\包含\扩展关系处理系统行为的公共或变更部分； 5、编制每一个用例的脚本； 6、绘制用例图； 7、区分主事件流和异常事件流，单独处理异常事件流用例； 8、细化用例图，去掉重复与冲突；
UML系统用例及用例关系.ppt
用户 收邮件
时间
提醒新邮件
下一讲内容
用例规约
历史ⅱ岳麓版第13课交通与通讯 的变化资料
精品课件欢迎使用
[自读教材· 填要点] 一、铁路，更多的铁路 1．地位
铁路是
交通运输 建设的重点，便于国计民生，成为国民经济
发展的动脉。 2．出现 1881年，中国自建的第一条铁路——唐山 路建成通车。 1888年，宫廷专用铁路落成。 至胥各庄铁 开平
统一建模语言
11软件工程
CH4 用例图 系统用例及用例关系
知识回顾—需求获取
需求工程
需求管理
需求开发
问题获取
分析
编写规格说明
验证
教学目标
掌握用例图的地位作用及定义
重 点 掌握用例图模型元素 能够根据需求分析使用用例图建模
难 点
确定用例及用例间的关系
教学内容
用例图建模应用 用例图 需求获取
需求获取及分析 需求的基本方法 什么叫用例图 用例图的构成要素 用例的重要元素 用例之间的各种重 要关系 识别参与者 确定用例
客户
商业客户
个体客户
用例1
定义：Use Case 用例表示系统的一项外部
用例
功能，它从用户的角度分析 所得的需求。为完成一个相 对完整的一种功能，系统执 行的一系列动作的集合
是外部可见的一种系统功能 代表的是一个完整的功能 有一系列动作
用例2
用例捕获某些角色可见的需求，实现 一个具体的角色需求 用例由其用户角色使用，并提供确切 的输出给角色 用例可大可小，但它必须是对一个具 体的角色目标实现的完整描述 用例的动态执行过程可以用UML的交互 作用来说明，可以用状态图、顺序图、 协作图或非正式的文字描述来表示
第三章 用例和用例图PPT课件
精选课件
9
3.2.2 识别参与者(actor)
对于一个大系统，难以列出所有用例的清单。此时，应先 列出所有的参与者，然后在对每个参与者列出他所需的所 有用例。即提供了一种获取用例的系统化过程。
“参与者”（活动者、执行…者）是指在系统之外，透过系 统边界与系统进行有意义交互的任何事物。
精选课件
10
3.2 识别参与者
精选课件
14
思考：识别参与者？
• 寻呼台系统：用户如果预定了天气预报，系统每天定
时给他发天气消息；如果当天气温高于35度，还要提 醒用户注意防暑；
在这个叙述里，谁是寻呼台系统的Actor？ 用户？气温？时间？
时间作为参与者，一种习惯用法，用于激活那些系统定 期的、自动执行的用例
精选课件
15
3.2.2 识别参与者：参与者与系统边界
精选课件
40
3.2.4 用例之间的关系
Generalization 泛化关系中，子用例继承父用例的行为和含义，子用例也 可以增加新的行为和含义或覆盖父用例中的行为和含义
<<include>> Include
一个用例（称作基本用例）的行为包含了另一个用例（称 作包含用例）的行为
<<extend>> Extend 扩展关系比泛化关系用更多的规则限制，基础用例提供扩 展点，扩展用例只能在这些扩展点上增加新的行为。
精选课件
19
识别参与者：棋牌馆管理系统
目标：构建一个棋牌馆管理系统 问题描述： 客户通过Internet预订座位，检查座位详情，如果没有空闲 的座位或满意的座位，可以选择进入等候队列。 总台服务员在客户到棋牌馆时，根据客户的预订信息，安排 客户座位。 当客户要离开棋牌馆时，客户到总台服务员办理结账，可以 采用两种方式，一种是现金结账，另一种是银行卡结账，而 银行卡结账将通过与银联POS系统交互来完成。
uml 基础教程 第三章-用例图
• 用例具有3个明显的特征： （1）用例表明的是一个类，而不是某个具体的实例 （2）用例必须由某一个参与者触发激活后才能执行，即
每个用例至少应该涉及一个参与者 （3）用例是一个完整的描述
椭圆来表示用例
“回顾”饮料销售机
• 在前面的分析中，我们获得了系统中有3个用例，分别是 “Buy soda（买饮料）”、“Restock（供货）”、“Collect（ 收款）”。
• 假设正在对一台饮料机建模，这台饮料销售机允许顾 客选择买一罐饮料或是买一杯饮料。在这种情况下，“Buy Soda”就是一个父用例，“Buy a can of soda”和“Buy a cup of Soda”就是子用例。用例之间的泛化关系建模与类之间 泛化关系建模方法相同，用一条带空心三角形箭头的实线 从子用例指向父用例。
• 要用在用例图上显示某个用例：
➢使用人形符号绘制一个参与者；
➢绘制一个椭圆表示用例，将用例的名称放在椭 圆的中心或椭圆下面的中间位置；
➢使用带箭头或不带箭头的线段来描述参与者和 用例之间的关系。
举例：饮料销售机
• 假设你现在正着手设计一台饮料销售机。为了获得用户 的观点，你会见了许多可能的用户以了解这些用户将如何 与这台机器交互。
“取钱”用例
• 还有一个“取钱”用例，同样也是因为一段时间的流逝， 收款人发起了这个用例。它的前期工作步骤与”供货“一 样，也是打开销售机前端架子。收款人从机器中取出钱， 然后按照”供货“步骤，放回架子锁好机器。 这个用例的前置条件也是时间间隔的流逝，后置条件 是收款人收到了钱。
3.1.1 参与者
• 理想情况下，顾客看到这条消息后会立即选择其它品牌 的饮料。销售机也必须提供给顾客取回原来的钱的选项。 这表示，销售机应给顾客两种选择：让顾客选择另一种饮 料并且给顾客提供这种饮料（如果这种饮料还有存货的话） 或者让顾客选择退钱。
第2讲用例与UML用例图精品PPT课件
学习目标
上讲回顾 用例的概念 用例分析的过程 使用用例模型捕获系统需求
上讲回顾
UML的全称__________________________________. UML的图基本构造块包括_______和______. UML的基本构造块中的关系包括哪几种__________. UML的图包括哪几种____________. 动态图包括哪些_____________________________. 静态图包括哪些_____________________________. RUP是______________________________________.
评价应聘者
录用应聘者
录用应聘者
拒绝应聘者
拒绝应聘者
参与者的泛化
Employee Manager
面试面应试聘应者 聘者 评评价价应应聘聘者 者 录录用用应应聘聘者者
拒拒绝绝应应聘者聘者
参与者的泛化
• 只有在子参与者使用了父参与者所使用的 所有用例时，参与者泛化才是合适的。
• 参与者泛化会带来不必要的复杂性，所以 不要强加一个不存在的关系。
用例的特点 ： 用例捕获某些用户可见的需求，实现一个具 体的用户目标。 用例由参与者激活，并提供确切的值给参与 者。 用例可大可小，但它必须是对一个具体的用 户目标实现的完整描述。
参与者（Actor）
参与者是指对用例所描述的事件序列的发 起者。
参与者可以是一个人、另一个系统、一台 硬件设备或某段时间的流逝。
后置条件：顾客得到现金
事件流
（1）事件流由简短步骤的序列组成。 （2）陈述性的、带编号、按时间排序 （3）每个步骤简单地描述了什么东西执
行了什么动作。 每个步骤应该具有如下格式： <编号> <某事> <行为> （4）一个事件流仅描述用例中的一条路径， 不包括其它的分支。
UML用例图
UML⽤例图前些时间参加了潘加宇⽼师的技术讲座，UML建模技术受益匪浅。
我也把平时的⼀些积累和上次的收获总结在这篇⽂章中，主要讲解⽤例图相关的知识。
⽤例图是软件需求分析到最终实现的第⼀步，它描述⽤户如何使⽤系统及使⽤系统什么样的功能。
⽤例图从业务⾓度上体现谁来使⽤系统、⽤户希望系统提供什么样的服务，以及⽤户需要为系统提供的服务，也便于软件开发⼈员最终实现这些功能。
⽤例图在开发中被⼴泛的应⽤，但是它最常⽤来描述系统提供了什么样的功能给什么样的⽤户使⽤。
在官⽅⽂档中⽤例图包含六个元素，分别是：执⾏者(Actor)、⽤例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
但是有些UML的绘图⼯具多提供了⼀种直接关联关系(DirectedAssociation)。
⽤例图可⼀个包含注释和约束，还可⼀个包含包，⽤于将模型中的元素组合成更⼤的模块。
有时，可以将⽤例的实例引⼊到图中。
⽤例图模型如下所⽰，执⾏者⽤⼈形图标来标识，⽤例⽤椭圆来表⽰，连线表⽰它们之间的关系。
⼀、执⾏者（Actor）1、执⾏者概念是指⽤户在系统中扮演的⾓⾊。
如图1-1是⼀个⽤户管理的⽤例图，图中的⽤户、管理员就是⽤例的执⾏者。
图1-12、从业务中找出执⾏者获取系统⽤例⾸先要找出系统的执⾏者。
我们可以通过⽤户回答⼀些问题的答案来识别执⾏者。
可以参考以下问题：1. 谁使⽤系统的主要功能（主要使⽤者）？2. 谁需要系统⽀持他们⽇常⼯作？3. 谁来维护、管理系统使其正常⼯作（辅助使⽤者）？4. 系统需要控制哪些硬件？5. 系统需要其他哪些系统交互？这⾥包含其他计算机系统或者应⽤程序。
6. 对系统产⽣结果感兴趣的是哪些⼈和哪些事物？3、执⾏者之间关系因为执⾏者是类，所以多个执⾏者之间可以具有与类相同的关系。
在⽤例图中，使⽤了泛化关系来描述多个执⾏者之间的公共⾏为。
UML各种图例—用例图、类图、状态图、包图、协作图、顺序图
UML各种图例——用例图、类图、状态图、包图、协作图、顺序图面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.∙决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.每个类图包括类，关联和多样性表示.方向性和角色是为了使图示得更清楚时可选的项目.包和对象图为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型. dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。
2012-2013 第二学期 11本 UML 实验一参答(第三章用例图)
Borrower 借阅 者可 通过 图书 管理 员对 系统 操作 Give Notice 《Extend》
《Include》
Remove Reservation Info of Borrower Librarian Reservation Lend Item
《Include》 Find Borrower Find Title
Delete 《Extend》
Update
《Include》
Return Item 《Include》 《Include》
Find Title Find Borrower
案例4. 设计“图书管理系统”的Use Case 框图1
当通知为借阅成功时 应自动删除预定
通知是一个常规用例参阅者 的几项活动均需要 《Include》 《Extend》 Rerigist Login Telephone 《Include》 Address 《Include》 Name 添加时需 要需要借 阅者信息 《Include》 《Extend》 《Include》 Add Sort Title Query 《Include》
UML 面向对象技术教程
上机实验一 用例及用例图
1
案例1. 绘制“自动饮料机售货”的用例图（含功能扩展）
功能： 1、顾客通过自动饮料售货机, 可以方便地买到一听饮料 2、供应商可以向自动饮料售货机添加饮料（需要开和关自动饮料售货机的门）; 3、收银员可以从自动饮料售货机取钱.（需要开和关自动饮料售货机的门） 参与者：Customer Supplier Cashier 用例： Buy drink Set drink Take money Open machine Close machine
uml第03章 用例和用例图
3.8 用例的描述
ATM系统“取款”用例的两个错误描述： 系统“取款”用例的两个错误描述： 系统
Use case: Withdraw cash Actor: customer 主事件流： 主事件流： (1) 储户插入 储户插入ATM卡,并输入密码 卡 并输入密码 Use case: Withdraw cash Actor: customer 主事件流： 主事件流： • ATM系统获得 系统获得ATM卡和密码 系统获得 卡和密码
例：一个银行业务系统中的参与者 例：一个银行业务系统中的参与者 1. 客户：从系统获取住处并执行金融交易 客户： 2. 管理人员：创建系统的用户, 获取并更新信息 管理人员：创建系统的用户 3. 厂商：接受作为转账支付结果的资金 厂商： 4. Mail系统：与系统交互, 发送或接收邮件 系统：与系统交互 系统
右图的例子演示了 包含关系
注意: 箭头方向为基本用例到包含用例. 注意 箭头方向为基本用例到包含用例
14 面向对象分析与设计 & UML
3.4.2 包含关系
15
面向对象分析与设计 & UML
3.4.3 扩展关系
扩展关系的基本含义与泛化关系类似, 扩展关系的基本含义与泛化关系类似 但对扩展用例 有更多限制, 即基本用例必须声明若干”扩展点” 有更多限制 即基本用例必须声明若干”扩展点”, 扩展用例只能在扩展点上增加行为和含义. 扩展用例只能在扩展点上增加行为和含义 扩展关系是依赖关系版型. 扩展关系是依赖关系版型
例：在“订货”用例中包括几个相关脚本： 订货”用例中包括几个相关脚本： • 订货顺利进行的脚本 订货顺利进行的脚本; • 相关货源不足时的脚本 相关货源不足时的脚本; • 购货者的信用卡被拒绝时的脚本 购货者的信用卡被拒绝时的脚本; • ……
2012-2013 第二学期 11本 UML 课上练习三状态图与活动图_答案
验证登录信息
登录失败
选择下载服务 下载课件 退出系统
验证未通过
验证通过
显示所有服务
注销账户
3、远程网络教学系统中，管理员登录后可处理注册申请 或审核课件.在处理注册申请后需要发送邮件通知用户处 理的结果；审核完课件后需要更新页面信息以保证用户 看到最新的课件，同时系统更新页面完成以上工作后管 理员退出系统，系统则注销管理员帐户，画出管理员的 工作活动图.
练习题：
3、远程网络教学系统中，管理员登录后可处理注册申请 或审核课件。在处理注册申请后需要发送邮件通知用户 处理的结果；审核完课件后需要更新页面信息以保证用 户看到最新的课件，同时系统更新页面。完成以上工作 后管理员退出系统，系统则注销管理员帐户，画出管理 员的工作活动图。
1、远程网络教学系统中学生要下载课件，先需要输入网站的网址， 打开网站的主页。处于主页后输入用户名和密码，验证通过则进入 功能选择页面，反之未通过则需要重新输入。进入功能选择页面可 在课件页面选择需要下载的课件，进入课件下载状态。下载完成后 就完成了此次下载行为，画出学生下载课件的状态图。
UML 面向对象技术教程
课上练习三 状态图、活动图
1
练习题：
1、远程网络教学系统中学生要下载课件，先需要输入 网站的网址，打开网站的主页。处于主页后输入用户名 和密码，验证通过则进入功能选择页面，反之未通过则 需要重新输入。进入功能选择页面可在课件页面选择需 要下载的课件，进入课件下载状态。下载完成后就完成 了此次下载行为，画出学生下载课件的状态图。 2、远程网络教学系统中学生登录后可下载课件，登录 时系统需要验证登录信息，若验证通过系统会显示所有 的可选服务，如验证失败则登录失败。用户看到可选服 务时可选下载服务，然后下载需要的课件。下载完成后 用户退出系统，系统会注销相应的用户信息。画出学生 下载课件的活动图。
UML图例之用例图
UML图例之⽤例图 ⽤例图主要⽤来描述“⽤户、需求、系统功能单元”之间的关系，在需求分析阶段，常会借助⽤例图，从⽤户的⾓度描述系统的功能，以图形可视化的⽅式作为开发团队与客户的交流，同时也有助于形成统⼀语⾔。
⼀、⽤例图描述 ⽤例图（Use Case Diagrame）：描述了⼈们希望如何使⽤⼀个系统，将相关⽤户、⽤户需要系统提供的服务以及系统需要⽤户提供的服务更清晰的显⽰出来，以便使系统⽤户更容易理解这些元素的⽤途，也便于开发⼈员最终实现这些元素。
之所以说⽤例图⾄关重要，是由于⽤户并不关⼼系统的实现和内部结构，只关⼼产品所呈现出来的外部特征动态。
⽽⽤例图恰好就是描述软件产品外部特性的视图，它从⽤户的⾓度⽽不是从开发者的⾓度来描述需求，分析产品的功能和动态⾏为。
⼆、基本元素1、参与者(Actor)，在系统外部与系统直接交互的⾓⾊或外部系统。
可通过与客户的沟通交流，确定利益相关⼈，进⽽确定参与者。
⾓⾊：通常是具体⼈承担着⾓⾊，这是最常见的参与者。
外部系统：如CRM系统要操作OA系统，以⽅便发送通知，那么针对OA系统的调⽤，CRM系统作为外部系统这⼀参与者。
时间：如存在定时任务操作或者类似操作等，则时间作为参与者2、⽤例客户通过对需求的描述(主要为功能需求)，开发团队通过⽤例来体现系统功能和服务，通过参与者与⽤例的交互，来达到客户与开发团队的⽬标⼀致。
3、关联关系1）参与者与参与者间的泛化关系⽐如腾讯⽤户，包括微信⽤户和QQ⽤户两部分，但是使⽤腾讯业务时，只需要是腾讯⽤户即可，此时，可以采⽤泛化关系，采⽤三⾓空⼼箭头作为指向。
2）参与者与⽤例间的关联关系参与者与⽤例间是简单的关联关系，⼀个参与者可以有着多个⽤例3）⽤例与⽤例间的泛化关系⽤例之间可以存在泛化关系，⽐如常见的⽀付，可以选择微信⽀付、⽀付宝⽀付等等，但是这个操作就是⽀付。
泛化关系采⽤三⾓空⼼箭头。
4）⽤例与⽤例间的包含关系包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。
UML软件工程第3章
第3章 用例图
3.4 用例分析
用例分成的步骤：
(1)确定系统的边界范围，找出系统外部的参与者和 外部系统；
(2)确定每一个参与者所希望的系统行为，命名为用 例；
由(1)确定系统有哪些活动者，(2)确定每天个活动者需要 那些需求即那些系统行为，把这些系统行为定义为用例。
(3)把一些公共的系统行为分解为新的用例，供其他 用例引用；
业务实体( Business Entity)
第3章 用例图
3.5 业务用例图
银 行 系 统 业 务 用 例 图
第3章 用例图
3.5 业务用例图
建立业务模型
画完了业务用例图是否就完工了？没有，还需要建立 业务模型。如开发一个“个人储蓄”业务软件，这就 需要对“存、取款业务用例”作进一步的了解分析。
用例名称
应该与用例图相符，并写上其相应的编号；
简要说明/描述(主要描述用例的功能)
对该用例对参与者所传递的价值结果进行描述，应注意语言简 要，使用用户能够阅读的自然语言。
前置条件
是执行用例之前必须存在的系统状态，这部分内容如果在现在 不容易确定可以在后面再细化。
后置条件：
用例执行完毕系统可能处于的一组状态，这部分内容如果在现 在不容易确定也可以在后面再细化。
第3章 用例图
a 与 b 哪种方式更合适？为什么？
第3章 用例图
如果觉得a 方式过于抽象笼统，可以用文本的方式 进行详细描述。
详细描述的主要组成： 用例名称 简要说明/描述(主要描述用例的功能) 优先级 参与者 前置条件 后置条件 扩展点 优先级 主事件流 其他事件流
第3章 用例图
理解详细描述：
扩展( extend )
扩展用例没有活动者参加。
《软件工程》第3章用例图及其应用
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一，它能 够帮助开发团队更好地理解用户需求，明确系统 的功能范围。
2
通过用例图，开发团队可以对系统的交互方式进 行模拟和验证，从而发现潜在的问题和缺陷，提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中，保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率，确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例，可以找出未被测 试到的功能和业务流程，从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率，降低 漏测的风险。
02
针对每个测试场景，细化出具体的测试用例，包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求，从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程，为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系， 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物，它描 述了用户期望的系统功能和行为。
02 在系统设计完成后，可以通过与原始用例图进行 对比，验证设计是否满足原始需求。
03 如果设计不符合原始需求，则需要重新调整设计， 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
第三部分UML基础(第三章用例)
软件技术基础-------PPT课件
4
在一个基本功能集已经实现的系统中，
系统运转的大致过程是：
外部角色先初始化用例
然后用例执行其所代表的功能 执行完后，用例便给角色返回一些值（这
个值可以是角色需要的，来自系统中的任 何东西）。
软件技术基础-------PPT课件
系统控制的硬件设备有哪些，系统需要
与哪些其它系统交互；
其它系统，包括计算机系统、也包括该系
统将要使用的计算机中的其它应用软件。 其它系统也分成二类：
一类是启动该系统的系统 另一类是该系统要使用的系统
对系统产生的结果感兴趣的人或事是哪
些。
软件技术基础-------PPT课件 28
在完成了角色的识别工作之后，建模者
5
在用例模型中，系统仿佛是实现各种用
例的“黑盒子”。 我们只关心该系统实现了哪些功能，并 不关心内部的具体实现细节（比如系统 是如何做的、用例是如何实现的）。 用例模型主要应用在工程开发的初期— —进行系统需求分析时使用，通过分析 描述，使开发者在头脑中明确需要开发 的系统功能有哪些。
7
为系统验证工作打下基础。通过验证最
终实现的系统能够执行的功能是否与最 初需求的功能相一致，保证系统的实用 性。 从需求的功能（用例）出发，提供跟踪 进入系统中具体实现的类和方法，检查 其是否正确的能力。
软件技术基础-------PPT课件
8
特别是为复杂系统建模时，常用用例模
型构造系统的简化版本
35
用例具有以下的特征： 1、用例总由角色初始化 用例所代表的功能必须由角色激活，而 后才能执行。 一般情况下，角色可能并没有意识到初 始化了一个用例。换句话说，角色需要 系统完成的功能其实都是通过用例具体 完成的，角色一定会直接或间接地命令 系统执行用例。
UML 新(第三章 用例和用例图练习题及参考答案)解析
第三章 用例及用例图 练习题及参考答案
1
练习题：
试画出学院班级管理系统的用例图。 用例有：登录；找回密码；查看、修改、删除、录入班级基本 信息，参与者有管理员与系院领导。 试画出学生成绩管理的用例图。 用例有：登录；找回密码；录入、修改、保存、查询、删除成 绩，参与者有教师与学生。 试画出网上选课系统的用例图。 用例有：登录；找回密码；查看课程信息；按课程编号查询； 按课程名查询；选择课程；删除已选课程；维护课程信息；参与 者有系统管理员与学生。 试画出帐号管理系统的用例图。 用例有：创建新账户；设置账户；设置账户基本信息；设置账 户权限；删除帐户；查询账户。参与者有系统管理员。 一台自动饮料售货机共有6种不同饮料，售货机上有6个按钮，分 别对应6种饮料，顾客可以通过按钮来选择所要的饮料。每个按 钮旁有一个指示灯，用来表示该售货机中是否还有这种饮料可售。 售货机有一个硬币槽的找零槽，用来收钱和找钱，假设一位顾客 购买矿泉水，不用找零，请给出描述上述场景的用例图。
付 款 自动售货机 顾 客 找 钱
提供饮料
收 钱
学院班级管理系统的用例图登录extend查询班级基本信息找回密码系统管理员录入班级基本信息删除班级基本信息修改班级基本信息系院领导学生成绩管理的用例图录入成绩include修改成绩保存成绩教师extend登录查询成绩删除成绩学生找回密码网上选课系统的用例图的用例图查询课程信息选择课程按课程编号查询按课程名查询学生extend维护课程信息删除已选课程登录找回密码系统管理员帐号管理系统的用例图创建新帐号设置帐号设置帐号基本信息系统管理员设置帐号权限查询帐号删除帐号饮料自动售货机顾客购买矿泉水的用例图选择饮料付款显示是否有饮料自动售货机找钱提供饮料收钱顾客
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
参与者父类
8
参与者之间的关系
参与者也是类，因此它拥有与类相同的关系 主要是继承（泛化）关系。 参与者之间大量地反映出的‚权限‛关系。 公司管理系统
常规操作
职 员
销售经理
销售管理
人事经理
人事管理
9
参与者之间的关系的泛化
将销售经理与人事经理看成是特殊的参与者，不仅 有职员的功能，还有其特殊职务所赋予的功能，是职 员的泛化。
用例驱动的方法论。 用例是各种交互的动作序列之间的说明与描述。 用例的描述、表示与命名方法、规律。 用例描述的是系统功能性的需求。 理解用例之间相互关系（泛化、包含、扩展）。 脚本是用例的实例。 参与者在系统中的含义。参与者之间同样有泛化关系。 用例描述是用例的主要部分。 用例描述无统一的标准。 用例分析结果与分析人员的水平与领域知识相关
基本用例
扩展用例1
扩展用例2
19
§3.4.3 扩展关系（续）
一个用例相对于包含和扩展关系来讲是变换的。 例如：网上买东西
对应于包含关系来讲是基本用例 对应于扩展关系来讲是扩展用例
Customer
Buy Merchandise
<<extend >>
<<include>>
Browse Web Site
由以上例子看出： 其用例描述并无一个固定的模式可循，各自有理解和侧重， 关键是要多加练习。
25
§3.7 寻找用例的方法
用例分析可遵循的步骤：
1、找出系统外部的参与者和外部系统，确定系统的边界； 2、确定每一个参与者所期望的系统行为； 3、命名这些系统行为为用例； 4、使用泛化\包含\扩展关系处理系统行为的公共或变更部分； 5、编制每一个用例的脚本； 6、绘制用例图； 7、区分主事件流和异常事件流，单独处理异常事件流用例； 8、细化用例图，去掉重复与冲突；
11
§3.3 脚本（scenario）
脚本又称为情景、场景、情节、剧本等 在UML中，脚本贯穿用例的一条单一路径。 脚本的定义：脚本是用例的实例(instance)。 脚本与用例之间是对象与类的关系。 例如：针对‘取钱’的用例，脚本就会有 1、正常完成取钱的脚本。 2、账户拒绝、取不出钱的处理脚本。 3、取出钱不对后的处理脚本。 但是有1、2、3、…构成了一个用例。 脚本的描述：一个脚本是用具体的文字加以描述的。
取钱
WithDrawe Money
用例名
3
§3.1 用例（续）
用例的特点：
1、从系统外看系统功能。 2、描述一个系统可见需求，对应于一个具体的用户目标。 3、是系统行为的动态描述，属于动态建模范畴。
软件开发过程是由用例驱动的。 用例将软件开发过程中各个阶段捆绑在一起， 以实现功能的系统行为作为所达成的契约。 例如：来看银行对外业务系统的简单描述： 查询账户余额 列出业务菜单项 转账 存款与支付 登录与退出系统
5
§3.1 用例（续三）
寻找用例及识别用例的方法 参与者希望系统提供什么功能？ 参与者是否会读取、创建、修改、删除、存储系统 的某种信息？若是又是如何完成这些操作？ 参与者是否会将外部的某些事件通知系统的？ 系统中发生的事件是否会通知参与者？ 是否存在影响系统的外部事件？
6
§3.2 参与者（actor）
用‘启发性原则’检验用例分析的方法：
和用户交互 和系统交互 参与者与用例的关系不可分割。
26
§3.8 常见问题分析
问题：同学们自己看书即可，不再赘述。 根据看书关注思考一下问题？ 1、用例的粒度问题？ 2、组合用例还是分解用例？ 并注意着重理解细化用例与合并用例。
27
§3.9 第三章用例章节小结
UML 面向对象技术教程
第三章 用例及用例图
1
本章中所涉及的内容
用例 参与者 脚本 用例间关系（泛化、包含、扩展、三种关系 的比较） 用例图 用例的描述 寻找用例的方法 常见问题的分析 小结
2
§3.1 用例
用例（use case） 用例就是对包含变量在内的一组活动序列的描述，系统执 行这些活动，并产生传递特定参与者的价值的可观察结果。 定义一：用例是对一个活动者(actor)使用系统的一项功 能时所进行的交互过程的一个文字描述。 定义二：用例是系统、子系统或类和外部的参与者(actor) 交互动作序列的说明，包括可选的动作序列和会 出现异常的动作序列。 如何在UML中表示用例： 用例用一个椭圆来表示，用例名下在下面，其用例名往 往是一个动宾结构。如‚取钱‛是一个用例,它的表示如 下：
在UML中表示法
<<extend>>
（包含参与者之间的泛化表示方法） 包含 在基础用例上插入附加的行为
<<include>>
______________________________________________
14
§3.4 用例间关系（续二）
关联关系（association） 用来描述参与者与用例之间的通信。 通俗地讲就是参与者与用例之间所形成的关系。
4
§3.1 用例（续二）
用例是UML建模过程中一个非常重要概念，它处于核 心位置。 不能指望在一个系统分析中列出全部的用例。 用例是外部可见的一个系统功能单元。用途在于不 揭示系统内部构造的情况下定义一组连贯的行为。 用例可大可小，但它必须是对一个具体的用户实现 目标的完整描述。 用例的动态执行过程 在UML中可以交互表现在‘用例图’、‘顺序图’、 ‘协作图’ 或文字描述来表示。功能的执行过程用 ‚类‛之间的协作来实现。
Add Order to Warehouse Syatem 对应于包含关系来讲是包含用例
20
对应于包含关系来讲是基本用例 对应于扩展关系来讲是扩展用例
例如：还书的扩展用例
借书学生
还书
缴纳过期或破损罚款
21
§3.4.4 用例的泛化、包含、扩展关系的比较
关系是模型元素之间的语义联系。 关联是两个或多个类元（classfier）之间的关系 类元包括：类、参与者、组件、数据类型、接口、结点、 信号、子系统、用例等，在UML中用 表示关联。 泛化表示的是两个类元之间（通用和特殊）的关系。 二者的结构和行为上一致，其特殊类元包含更多信息。在 UML中用 表示泛化，特殊指向通用。 依赖关系的二种形式：包含和扩展 依赖是指两个元素或元素类集之间（行为涵盖）的关系。 它们之间存在依赖关系，被依赖元素目标元素，依赖元 素源元素，源元素随目标元素改变而调整。 包含：基本指向包含，UML中用 <<include >> 表示。 扩展：扩展指向基本，UML中用 <<extend >> 表示。 22
职 员
常规操作
销售经理
销售管理
人事经理
人事管理
10
寻找参与者的参考方法
系统开发出来后，是谁使用系统的主要功能。 谁需要借助系统来完成日常工作。 系统需要从哪些人或其他系统中获取数据。 系统会为哪些人或其他系统提供数据。 系统会与哪些系统交互？这些系统分为两类，一是 该系统要使用的系统，二是启动该系统的系统，包 括其他软件。 系统由谁来维护和管理的，以保证系统处于工作状 态？ 系统控制的硬件设备有哪些？ 谁对系统产生的结果感兴趣2 参与者（actor）续
参与者事实上就是一个类。
继承关系 泛化关系（在系统分析阶段是相等的） 参与者可以被一组定义它状态的属性加以描述，代 表一个角色。 参与者的重要性有分级：主要角色、次要角色 参与者的性质有主动参与（执行主要功能）、 被动参与（执行次要功能）。
参与者子类
12
§3.4 用例间关系
针对用例的描述要遵循的几个要点： 清楚地确定系统的边界。 用标准模板书写用例说明。 关注用例的真正目的。 不能将用例说明与用户接口设计相混淆。 实现使用例交互与用户接口之间的松散耦合。 不要在用例与用户接口之间建立通信。
13
§3.4 用例间关系（续）
用例之间关系有以下几种： 关系 所表示的功能 关联 参与者与用例之间通信 扩展 在基础用例上插入扩展部分 泛化 表示用例间的一般和特殊关系
24
§3.6 用例的描述（续）
p30表3.2 用例的描述格式（参考的描述问题样本） p31表3.3 用例处理订单的描述（参考的具体） P31例3.5 Withdraw Case的用例描述(缺少系统行为) p32例3.6 Withdraw Case的用例描述(缺少参与者行为) p32例3.7 Buy something 的用例描述(界面描述过于详细) p33例3.8 Buy something 的用例描述(描述冗长，应合并)
§3.5 用例图（use case diagram）
显示一组用例、参与者以及它们之间关系的图。
在UML中，由若干个用例图组成一组用例模型。 用例图又称为‘用户模型图’，属于OOA的第一步。 是系统功能细节的最高形式。只关注系统功能不关心内部 实现细节。 教材上的用例图例子可见P29中图3.9 金融贸易系统用例 图，这个例子是使用Rational Rose 2003绘制的。 例子：银行日常业务用例图：
用 例 参与者
15
§3.4.1 泛化关系
泛化（generalization） 代表一般和特殊的关系。 例如：付款、订票等。
在UML中泛化关 系的表示，由子 用例指向父用例
父用例
付款
子用例，它 继承了父用例 的行为和含义， 同时也可以增 加新行为