第三讲课堂练习用例图与用例规约演示文稿
合集下载
第3章(用例图)
识别用例
从分析系统的参与者开始，考虑每个参与者是怎样使用系统。
①参与者希望系统提供什么功能； ②系统是否存储和检索信息； ③当系统改变状态时，是否通知参与者； ④是否存在影响系统的外部事件，是哪个参与者通知系
统这些外部事件。
用例
识别用例 例1：Email客户端（如:outlook express），A在北京发邮件给深 圳的B，系统提醒B”你有新邮件”，B收邮件。
参与者的表示方法
参与者
如何发现系统的参与者 ①谁使用系统？ ②谁安装系统、维护系统？ ③谁启动系统、关闭系统？ ④谁从系统中获取信息，谁提供信息给系统？ ⑤在系统交互中，谁扮演了什么角色？ ⑥系统会与哪些其他系统相关联？
参与者
如何发现系统的参与者 例1：客户给销售员发来传真订货， 销售员下班前将当日订货单汇总 输入系统。
用例
用例的粒度 用例所包含的系统服务或功能单元的多少。
用例
用例规约 对每一个用例的详细描述信息，以便于其他人对整个系统有一
个更加详细地了解。
用例规约的内容
（1）简要说明 （2）前置条件 （3）基本事件流 （4）其他事件流 （5）异常事件流 （6）后置条件
前置条件 扩展事件流 基本事件流
后置条件
用例
事件流
例：将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。 提款─基本事件流
基本流步骤1：用户插入信用卡 基本流步骤2：输入密码 基本流步骤3：输入提款金额 基本流步骤4：提取现金 基本流步骤5：退出系统，取回信用卡
用例
事件流
例：将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。
问题：谁是系统的Actor？
答案： 销售员
参与者
从分析系统的参与者开始，考虑每个参与者是怎样使用系统。
①参与者希望系统提供什么功能； ②系统是否存储和检索信息； ③当系统改变状态时，是否通知参与者； ④是否存在影响系统的外部事件，是哪个参与者通知系
统这些外部事件。
用例
识别用例 例1：Email客户端（如:outlook express），A在北京发邮件给深 圳的B，系统提醒B”你有新邮件”，B收邮件。
参与者的表示方法
参与者
如何发现系统的参与者 ①谁使用系统？ ②谁安装系统、维护系统？ ③谁启动系统、关闭系统？ ④谁从系统中获取信息，谁提供信息给系统？ ⑤在系统交互中，谁扮演了什么角色？ ⑥系统会与哪些其他系统相关联？
参与者
如何发现系统的参与者 例1：客户给销售员发来传真订货， 销售员下班前将当日订货单汇总 输入系统。
用例
用例的粒度 用例所包含的系统服务或功能单元的多少。
用例
用例规约 对每一个用例的详细描述信息，以便于其他人对整个系统有一
个更加详细地了解。
用例规约的内容
（1）简要说明 （2）前置条件 （3）基本事件流 （4）其他事件流 （5）异常事件流 （6）后置条件
前置条件 扩展事件流 基本事件流
后置条件
用例
事件流
例：将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。 提款─基本事件流
基本流步骤1：用户插入信用卡 基本流步骤2：输入密码 基本流步骤3：输入提款金额 基本流步骤4：提取现金 基本流步骤5：退出系统，取回信用卡
用例
事件流
例：将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。
问题：谁是系统的Actor？
答案： 销售员
参与者
第3章用例及用例图-案例学习资料
16
● ① 找出系统外部参与者，确定系统边界和范围。
17
● ② 确定各参与者所期望的系统行为。
柜台人员 客房预订 预订变更 入住登记 退房结帐 选择课程 信息查询
18
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
19
● ④ 确定各用例之间的关系(泛化，包含，扩展)。
13
● ⑥ 编制用例说明。
● 用例：增加课程
●参与者：管理员
●操作流：
① 管理员选择进入管理界面，用例开始。
② 系统提示输入管理员密码。
③ 管理员输入密码。
④ 系统检验密码。
A1：密码出错。
⑤ 进入管理界面，系统显示当前所建立的全部课程信息。
⑥ 管理员选择增加课程，管理员输入新课程信息。
⑦系统验证是否与已有课程冲突。
2
3.7 业务用例图
4
3.8 实例
• 案例1：
– 有一个爱书之人，家里各类书籍已过千册，平时又 时常有朋友外借，因此需要一个图书管理系统。该 系统应该能够将书籍的基本信息按计算机类、非计 算机类分别建档，实现按书名、作者、类别、出版 社等关键字的组合查询功能。在使用系统录入新书 籍时系统会自动按规则生成书号，以修改信息，但 不能够删除记录。该系统还应该能够对书籍的外借 情况进行记录，可对外借情况列出打印。另外，还 希望能够对书籍的购买金额、册数按特定时限进行 统计。
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例：客房预订 ●参与者：柜台工作人员 ●说明：
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
● ① 找出系统外部参与者，确定系统边界和范围。
17
● ② 确定各参与者所期望的系统行为。
柜台人员 客房预订 预订变更 入住登记 退房结帐 选择课程 信息查询
18
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
19
● ④ 确定各用例之间的关系(泛化，包含，扩展)。
13
● ⑥ 编制用例说明。
● 用例：增加课程
●参与者：管理员
●操作流：
① 管理员选择进入管理界面，用例开始。
② 系统提示输入管理员密码。
③ 管理员输入密码。
④ 系统检验密码。
A1：密码出错。
⑤ 进入管理界面，系统显示当前所建立的全部课程信息。
⑥ 管理员选择增加课程，管理员输入新课程信息。
⑦系统验证是否与已有课程冲突。
2
3.7 业务用例图
4
3.8 实例
• 案例1：
– 有一个爱书之人，家里各类书籍已过千册，平时又 时常有朋友外借，因此需要一个图书管理系统。该 系统应该能够将书籍的基本信息按计算机类、非计 算机类分别建档，实现按书名、作者、类别、出版 社等关键字的组合查询功能。在使用系统录入新书 籍时系统会自动按规则生成书号，以修改信息，但 不能够删除记录。该系统还应该能够对书籍的外借 情况进行记录，可对外借情况列出打印。另外，还 希望能够对书籍的购买金额、册数按特定时限进行 统计。
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例：客房预订 ●参与者：柜台工作人员 ●说明：
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
需求分析-用例图-用例规约
用例名:帖子管理 相关需求:版主对相应版块的帖子进行管理 参与者:版主 前置信息:版主登陆管理系统，进行相应操作 后置信息:相应版块下的帖子更新 主成功场景下的事件流: →1.版主登陆管理系统 ←2.系统跳转到管理界面 →3.版主删除相应版块帖子，或在相应版块设置或撤销热帖，或在相应版块发布公告 ←4.服务器响应操作，更新当前版块内容 扩展事件流: →3a.版主设置新热帖时热帖数量达到上限
2a.1 游客重新注册 2b.游客输入密码过短
2b.1 游客重新注册
用例名:登陆 参与者:普通用户 事件流: 1.用户访问论坛首页，选择登陆按钮，进入登陆界面 2.用户输入用户名、密码，完成登陆 可选路径: 2a.用户输入用户名或密码错误
2a.1 系统提示出错，并要求用户重新输入用户名及密码
用例名:个人资料管理 参与者:普通用户 事件流: 1.用户登陆并进入个人中心
3a.1 系统提示待添加用户与已有用户重复 3b.相应版块版主设置数量达到上限
3b.1 系统提示该版块版主数量设置达到上限
用例名:报表管理 参与者:管理员 事件流: 1.管理员登陆管理系统 2.管理员查看报表，或打印报表
用例图
用例规约
用例名:浏览帖子 相关需求:选择相应版块、浏览帖子 参与者:游客、用户 前置信息:游客访问论坛首页并选择相应版块 后置信息:显示当前帖子 主成功场景的事件流: →1.用户访问论坛首页，选择版块 ←2.服务器响应点击事件，跳转页面 →3.用户浏览版块下的帖子
←3a.1 系统提示错误 →3a.2 游客重新输入注册信息 →3b.游客填写的密码过短 ←3b.1 系统提示错误 →3b.2 游客重新输入注册信息
用例名:登陆 相关需求:用户登陆论坛 参与者:用户 前置信息:用户点击登陆按钮进入登陆界面，输入用户名和密码 后置信息:登陆成功进入论坛 主成功场景的事件流: →1.用户点击登陆按钮 ←2.服务器响应点击事件，跳转到登陆界面 →3.用户输入用户名和密码 ←4.登陆成功，用户进入论坛页面 扩展事件流: →3a.用户输入错误的用户名或密码
2a.1 游客重新注册 2b.游客输入密码过短
2b.1 游客重新注册
用例名:登陆 参与者:普通用户 事件流: 1.用户访问论坛首页，选择登陆按钮，进入登陆界面 2.用户输入用户名、密码，完成登陆 可选路径: 2a.用户输入用户名或密码错误
2a.1 系统提示出错，并要求用户重新输入用户名及密码
用例名:个人资料管理 参与者:普通用户 事件流: 1.用户登陆并进入个人中心
3a.1 系统提示待添加用户与已有用户重复 3b.相应版块版主设置数量达到上限
3b.1 系统提示该版块版主数量设置达到上限
用例名:报表管理 参与者:管理员 事件流: 1.管理员登陆管理系统 2.管理员查看报表，或打印报表
用例图
用例规约
用例名:浏览帖子 相关需求:选择相应版块、浏览帖子 参与者:游客、用户 前置信息:游客访问论坛首页并选择相应版块 后置信息:显示当前帖子 主成功场景的事件流: →1.用户访问论坛首页，选择版块 ←2.服务器响应点击事件，跳转页面 →3.用户浏览版块下的帖子
←3a.1 系统提示错误 →3a.2 游客重新输入注册信息 →3b.游客填写的密码过短 ←3b.1 系统提示错误 →3b.2 游客重新输入注册信息
用例名:登陆 相关需求:用户登陆论坛 参与者:用户 前置信息:用户点击登陆按钮进入登陆界面，输入用户名和密码 后置信息:登陆成功进入论坛 主成功场景的事件流: →1.用户点击登陆按钮 ←2.服务器响应点击事件，跳转到登陆界面 →3.用户输入用户名和密码 ←4.登陆成功，用户进入论坛页面 扩展事件流: →3a.用户输入错误的用户名或密码
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、细化用例图，去掉重复与冲突；
第三章 用例和用例图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 参与者
• 理想情况下，顾客看到这条消息后会立即选择其它品牌 的饮料。销售机也必须提供给顾客取回原来的钱的选项。 这表示，销售机应给顾客两种选择：让顾客选择另一种饮 料并且给顾客提供这种饮料（如果这种饮料还有存货的话） 或者让顾客选择退钱。
• 用例具有3个明显的特征： （1）用例表明的是一个类，而不是某个具体的实例 （2）用例必须由某一个参与者触发激活后才能执行，即
每个用例至少应该涉及一个参与者 （3）用例是一个完整的描述
椭圆来表示用例
“回顾”饮料销售机
• 在前面的分析中，我们获得了系统中有3个用例，分别是 “Buy soda（买饮料）”、“Restock（供货）”、“Collect（ 收款）”。
• 假设正在对一台饮料机建模，这台饮料销售机允许顾 客选择买一罐饮料或是买一杯饮料。在这种情况下，“Buy Soda”就是一个父用例，“Buy a can of soda”和“Buy a cup of Soda”就是子用例。用例之间的泛化关系建模与类之间 泛化关系建模方法相同，用一条带空心三角形箭头的实线 从子用例指向父用例。
• 要用在用例图上显示某个用例：
➢使用人形符号绘制一个参与者；
➢绘制一个椭圆表示用例，将用例的名称放在椭 圆的中心或椭圆下面的中间位置；
➢使用带箭头或不带箭头的线段来描述参与者和 用例之间的关系。
举例：饮料销售机
• 假设你现在正着手设计一台饮料销售机。为了获得用户 的观点，你会见了许多可能的用户以了解这些用户将如何 与这台机器交互。
“取钱”用例
• 还有一个“取钱”用例，同样也是因为一段时间的流逝， 收款人发起了这个用例。它的前期工作步骤与”供货“一 样，也是打开销售机前端架子。收款人从机器中取出钱， 然后按照”供货“步骤，放回架子锁好机器。 这个用例的前置条件也是时间间隔的流逝，后置条件 是收款人收到了钱。
3.1.1 参与者
• 理想情况下，顾客看到这条消息后会立即选择其它品牌 的饮料。销售机也必须提供给顾客取回原来的钱的选项。 这表示，销售机应给顾客两种选择：让顾客选择另一种饮 料并且给顾客提供这种饮料（如果这种饮料还有存货的话） 或者让顾客选择退钱。
用例规约(实例)
课程注册系统用例规约版本<1.0>查看成绩报告卡用例1.简要说明本用例允许学生查看他（她）刚结束学期的成绩报告卡。
本用例的Actor 是学生。
2.事件流当学生从主表格中选择“查看成绩报告卡”活动时，用例开始。
1.基本流—查看成绩报告卡1.系统检索出学生上个学期所修完的每门课程的成绩信息。
2.系统准备、排版并显示成绩信息。
3.当学生完成查看成绩信息后，选择“关闭”。
2.备选流1.没有可以查看的成绩信息如果在基本流中，系统不能找到这个学生上个学期的任何成绩信息，将会显示一个消息。
学生确认这条消息后，用例终止。
3.特殊需求没有和本用例有关的特殊需求。
4.前置条件1. 登录在本用例开始之前，学生要登录到系统。
5.后置条件没有和本用例有关的后置条件。
6.扩展点没有和本用例有关的扩展点。
课程注册用例1. 简要说明此用例允许学生登记当前学期的课程。
如果在学期开始的选/退课期间情况发生一些变化，那么学生也可以修改或删除自己所选的课程。
课程目录系统提供一个本学期所有课程的列表。
本用例主要的主角是学生。
课程目录系统是用例中包含的一个主角。
2. 事件流当学生从主窗体中选择“维护课程表”活动时，此用例就开始使用了。
1. 基本流—创建课程表1.学生选择“创建课程表”。
2.系统会显示一张空白课程表。
3.系统从课程目录系统中检索可选课程的列表。
4.学生从可选课程列表中选择 4 门主修课程和 2 门选修课程。
在完成选择后，学生选择“提交”。
5.在此步骤中为每一门所选课程执行“添加课程”子流程。
6.系统保存该课程表。
2. 备选流1. 修改课程表1.学生选择“修改课程表”。
2.系统检索并显示学生现在的课程表（例如，本学期的课程表）。
3.系统从课程目录系统中检索本学期所有可选课程的列表。
系统向学生显示该列表。
4.这样，学生就可以通过删除或者添加新课程来修改所选的课程。
学生从可选课程列表中选择要添加的课程。
学生也可以从目前的课程表中选择要删除的课程。
第三讲课堂练习-用例图与用例规约
4a2.前台人员确认已退还定金；
4a3.系统统计定金已退还。
17
2
要求：
按需求简要描述为旅店预订系统创建用 例图；
选择一种用例进行场景描述； 为该用例建立用例表； 为该用例创建活动图。
3
问题用例图1
4
问题用 例图2
5
问题用例图3
6
1. 不恰当旳“时间”参加者
✓ 时间：参加者，一种习常使用方法，用于激 活那些系统定时旳、自动执行旳用例
✓ “检验是否能够退定金”旳时候，时间仅仅 是一种系统内部旳判断条件，而不是参加者
12
5.参加者和用例间旳关系
✓ “打印报表” 和“酒店管理 员”之间旳关 联是有意义旳 交互吗？
13
6. 用例粒度太小
14
较为合理旳用例图
酒店前台
<<include>>
查找房间 <<include>> 预订房间
计算总费用
<<extend>>
取消预订
退还定金
管理人员
调整价格
时间
打印预订清单
15
较为合理旳用例规格阐明1
✓ 扩展关系： “extend”关系旳 方向，子用例对主用 例旳扩展
9
3. 错误旳用例关系
✓ 用例旳顺序在活动 图中体现
10
3. 错误旳用例关系
11
4. “其他”用例？
✓ “其他”、“打印清 单”用例和外围没有 任何有意义交互，和 其他用例也没有任何 关系，这么旳用例有 意义吗？
✓ “其他”用例又代表 什么呢？想阐明什么 样旳功能需求？
用例名称：预定房间 涉及旳参加者：酒店前台 描述：酒店前台人员根据旅客旳入住祈求，预定某个时间指定档次旳房间，预定
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
✓ 扩展关系： “extend”关系的方 向，子用例对主用例 的扩展
10
3. 错误的用例关系
✓ 用例的顺序在活动 图中表现
11
3. 错误的用例关系
12
4. “其他”用例？
✓ “其他”、“打印清单” 用例和外围没有任何 有意义交互，和其他 用例也没有任何关系， 这样的用例有意义吗？
✓ “其他”用例又代表 什么呢？想说明什么 样的功能需求？
13
5.参与者和用例间的关系
✓ “打印报表”和 “酒店管理员” 之间的关联是 有意义的交互 吗？
14
6. 用例粒度太小
15
较为合理的用例图
酒店前台
<<include>>
查找房间 <<include>> 预订房间
计算总费用
<<extend>>
取消预订
退还定金
管理人员
调整价格
时间
打印预订清单
16
3
要求：
按需求简要描述为旅店预订系统创建用 例图；
选择一个用例进行场景描述； 为该用例建立用例表； 为该用例创建活动图。
4
问题用例图1
5
问题用 例图2
6
问题用例图3
7
1. 不恰当的“时间”参与者
✓ 时间：参与者，一种习惯用法，用于激活那 些系统定期的、自动执行的用例
✓ “检查是否可以退定金”的时候，时间仅仅 是一个系统内部的判断条件，而不是参与者
8
2. 无效的参与者泛化
✓ 参与者泛化：特殊参与者会继承泛化参与者所有的要素！ ✓ 参与者的重要性在一识别用例，如果泛化没有带来任何用例，则
这样的方法没有任何意义 ✓ 在源自统中如果两个参与者涉及相同的用例，则合并
9
3. 错误的用例关系
✓ 依赖关系：include, extend都是依赖关 系(dependency)的 构造型(stereotype)， 带箭头的虚线表示
第三讲课堂练习用例图与用例 规约演示文稿
第三讲课堂练习用例图与用例 规约
用户需求简要描述
某公司要开发一个旅店预定系统，该旅店可对外开 放豪华双人间、双人间、三人间和单人间，房间费用视 情况按季节调整，但周一到周五半价（周末全价）折扣 不变。对于外界请求，该系统应能根据请求入住时间预 定指定档次的房间，记录旅客姓名、地址、联系电话、 有效证件号、房间类型和预定天数，并计算出总费用。 预定的同时旅客按规定须提交10%定金。六个小时之内 旅店允许旅客取消预定，并退回所有定金，超过六个小 时定金不退还。每周一系统自动打印一周预定情况清单。 采用哪种费用支付方式和何种类型操作界面尚不确定。
10
3. 错误的用例关系
✓ 用例的顺序在活动 图中表现
11
3. 错误的用例关系
12
4. “其他”用例？
✓ “其他”、“打印清单” 用例和外围没有任何 有意义交互，和其他 用例也没有任何关系， 这样的用例有意义吗？
✓ “其他”用例又代表 什么呢？想说明什么 样的功能需求？
13
5.参与者和用例间的关系
✓ “打印报表”和 “酒店管理员” 之间的关联是 有意义的交互 吗？
14
6. 用例粒度太小
15
较为合理的用例图
酒店前台
<<include>>
查找房间 <<include>> 预订房间
计算总费用
<<extend>>
取消预订
退还定金
管理人员
调整价格
时间
打印预订清单
16
3
要求：
按需求简要描述为旅店预订系统创建用 例图；
选择一个用例进行场景描述； 为该用例建立用例表； 为该用例创建活动图。
4
问题用例图1
5
问题用 例图2
6
问题用例图3
7
1. 不恰当的“时间”参与者
✓ 时间：参与者，一种习惯用法，用于激活那 些系统定期的、自动执行的用例
✓ “检查是否可以退定金”的时候，时间仅仅 是一个系统内部的判断条件，而不是参与者
8
2. 无效的参与者泛化
✓ 参与者泛化：特殊参与者会继承泛化参与者所有的要素！ ✓ 参与者的重要性在一识别用例，如果泛化没有带来任何用例，则
这样的方法没有任何意义 ✓ 在源自统中如果两个参与者涉及相同的用例，则合并
9
3. 错误的用例关系
✓ 依赖关系：include, extend都是依赖关 系(dependency)的 构造型(stereotype)， 带箭头的虚线表示
第三讲课堂练习用例图与用例 规约演示文稿
第三讲课堂练习用例图与用例 规约
用户需求简要描述
某公司要开发一个旅店预定系统，该旅店可对外开 放豪华双人间、双人间、三人间和单人间，房间费用视 情况按季节调整，但周一到周五半价（周末全价）折扣 不变。对于外界请求，该系统应能根据请求入住时间预 定指定档次的房间，记录旅客姓名、地址、联系电话、 有效证件号、房间类型和预定天数，并计算出总费用。 预定的同时旅客按规定须提交10%定金。六个小时之内 旅店允许旅客取消预定，并退回所有定金，超过六个小 时定金不退还。每周一系统自动打印一周预定情况清单。 采用哪种费用支付方式和何种类型操作界面尚不确定。