第三讲课堂练习 用例图与用例规约.
用例规约
用户登录用例图用例规约：用例名称：登录用例ID：IBM_ESHOP_002.1角色：普通用户用例说明：用例主要功能是实现登录,起始于普通用户的登录前置条件：启动程序，进入登录界面基本事件流：参与者动作系统响应1. 用户输入基本信息（登录名和密码），点击确定按钮2.系统查找数据库，看该用户是否在数据库中。
若存在则进入主页面,若不存在，则进入2.1.1;若未输入，则进入2.2.2其它事件流：无异常事件流：参与者动作系统响应2.1.1未输入用户名2.2.1用户名不存在2.1.2未输入密码2.2.2密码不正确2.1.1 提示用户名或密码不能为空2.2.2提示用户名或密码不正确。
后置条件：登录成功添加联系人用例图用例规约：修改联系人用例图用例规约：用例名称：修改联系人用例ID：IBM_ESHOP_002.3角色：普通用户用例说明：该用例主要实现的功能是用户实现对联系人信息的修改操作前置条件：进入主界面基本事件流：参与者动作系统响应1.选择想要修改的联系人，然后点击“修改”按钮3.用户对联系人姓名、性别、出生日期、Email、职务、固定电话、手机、住址、备注信息进行修改，点击“确定”按钮2.系统响应点击事件，跳转至“修改联系人信息”界面5．系统对用户的输入进行判断，若合法，则弹出对话框，提示“修改联系人成功”其它事件流：无异常事件流： 5.1姓名未输入，系统给出提示对话框“必须输入姓名”5.2 Email未输入，系统给出提示对话框“必填”后置条件：修改信息成功，返回主界面删除联系人用例图用例规约：用例名称：删除联系人用例ID：IBM_ESHOP_002.4角色：普通用户用例说明：该用例主要功能是删除联系人,用例起始用户点击“删除”按钮前置条件：进入主界面基本事件流：参与者动作系统响应1.用户确定要的联系人，然后点击“删除”3.1.1若确定删除联系人，点击“确定”按钮；2.系统弹出对话框，给出提示信息“是否删除”3.1.2进入“删除联系人成功界面”3.2系统返回主界面3.1．1用户点击返回按钮。
uml用例规约
uml用例规约UML（统一建模语言）用例规约是指对系统中某一特定功能或行为的详细说明和定义。
用例规约被用来描述系统中所需的所有输入、输出、前置条件、后置条件和用例执行步骤等信息。
在UML中，用例规约通常被用来描述用例的所有方面，包括预期的行为和系统响应。
下面将详细介绍一下UML用例规约。
UML用例规约通常包含以下几个方面：1. 名称：用例规约必须具有唯一的名称，以便与系统中的其他用例区分开来。
2. 概述：用例规约需要简要描述该用例的作用和目的。
3. 前置条件：描述执行该用例前必须满足的条件，这些条件可以是系统状态、数据要求、前置操作等。
4. 后置条件：描述执行该用例后的状态。
即系统状态、数据状态、后置操作等。
5. 执行步骤：用例规约必须描述用例的详细执行步骤，包括所有输入和输出。
6. 异常情况：描述当某个步骤失败或者出现错误时，应该采取的措施。
7. 优先级：描述该用例的优先级，以便团队能够确定该用例的重要性。
在编写UML用例规约时，需要遵循一些规则：1. 用例规约必须与用例图中的用例匹配。
2. 确保用例规约中包含所有必要的信息，以便其他团队成员能够理解和实现该用例。
3. 用例规约必须是准确的和一致的，以便与其他用例规约和系统文档相匹配。
在编写UML用例规约时需要注意以下几点：1. 用例规约应该易于理解和阅读，以便其他团队成员能够理解该用例的目的和执行步骤。
2. 用例规约应该尽可能清晰和简明，同时包含所有必要的信息。
3. 用例规约应该是一致的，遵循团队的规范和标准，以便与其他文档相匹配。
总之，UML用例规约是系统中描述某一特定功能或行为的详细说明和定义。
编写UML用例规约需要遵循一些规则和注意事项，以便其他团队成员能够理解和实现该用例。
UML旅店管理系统用例图、用例规约
一.旅店管理系统用例图
二．用例规约
1.预定房间
1 .1简要说明
本用例允许客户预订旅店的未被预订的房间，系统提供未被预订的房间的信息列表。
1.2 先置条件
客户进入旅店管理系统，并选择预订房间功能。
1.3 事件流
（1）基本事件流
A 客户选择要预订的房间的类型，双人间或单人间。
B 根据客户选择的房间类型，从所有该类型房间中，筛选未被预定的房间，将这些房间的信息列表显示，供客户查询。
C 客户选定房间，并输入要预订的天数。
（2）备选事件流
A 客户所需要类型的房间已全部被预订，则提示客户，该类型房间已全部被预订，询问客户是否选择另一类型的房间。
B 用户选择预订的房间的时间段与已经预订了该房间的其他客户的时间
段发生冲突，则系统提示，该房间在哪些日期里已被预订，并询问当前客户是更换房间还是修改预订天数。
1.4 后置条件
A 客户选择房间和预订天数并确认后，系统要求客户输入客户信息，包括客户的姓名、地址、联系电话、有效证件号。
另外，系统将计算出客户需要缴纳的定金和总费用，并显示出来。
B 客户重新选择房间类型，或修改天数，则刷新用户界面。
需求分析-用例图-用例规约
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.用户输入错误的用户名或密码
下单用例的用例规约
下单用例的用例规约
用例模型是由用例图和用例规约组成的。
一个完整的用例模型应该不仅仅包括用例图部分，还要有完整的用例规约部分。
用例规约是对每一个用例的详细描述，也就是说有多少用例，就要有多少用例规约。
一．用例图和用例规约对比
用例图只是在总体上用图形大致描述系统功能，简单、直观，但是细节缺失、不明确。
用例规约则是一个用例的详细文字描述，采用自然语言，对用例的细节进行详细的描述。
二．包含内容
1.简要说明
用例名称，用例编号，参与者，用例简述。
2.场景描述
触发器，前置条件，基本事件流，扩展事件流，结论，后
置条件。
3.其他事项
特殊需求，扩展点，优先级。
三．简要说明
用例名称：描述用例的意图或实现的目标，要与用例图中的用例名保持一致。
用例编号：用例的唯一标识符，建议以UC(Use Case)作为前缀。
参与者：描述用例的参与者有哪些，包括主要参与者和次要参与者。
用例简述：简要介绍用例的作用和目的。
UML用例图中的用例规约与系统需求细化与优化技巧
UML用例图中的用例规约与系统需求细化与优化技巧引言：UML（Unified Modeling Language）是一种用于软件开发的建模语言，用例图是UML中的一种图表，用于描述系统的功能需求。
在用例图中，用例规约和系统需求细化是非常重要的环节，它们能够帮助开发团队更好地理解和设计系统。
本文将探讨用例规约和系统需求细化的技巧，并提出一些优化的方法。
一、用例规约的重要性用例规约是对用例的详细描述，包括前置条件、后置条件、基本流程和可选流程等。
它能够帮助开发团队更好地理解用户需求，准确地定义系统的功能。
用例规约的编写需要考虑以下几个方面。
1.1 准确性用例规约必须准确地描述用户需求，避免出现歧义和模糊的描述。
开发团队应该与用户充分沟通，确保用例规约能够准确地反映用户的期望。
1.2 完整性用例规约应该尽可能地包含所有可能的场景和流程，以覆盖用户的所有需求。
开发团队需要仔细分析用户需求，确保用例规约的完整性。
1.3 可读性用例规约应该易于理解和阅读，以便开发团队能够清晰地理解用户需求。
开发团队可以使用简洁明了的语言，避免使用过于复杂的术语和句子结构。
二、系统需求细化的技巧系统需求细化是将用户需求转化为系统需求的过程。
它需要开发团队对用户需求进行深入的分析和理解，并将其转化为具体的功能和约束。
以下是一些系统需求细化的技巧。
2.1 分解需求将大的需求分解为小的子需求，以便更好地理解和设计系统。
开发团队可以使用层次结构或树状图等方式将需求进行分解，并为每个子需求编写详细的描述。
2.2 确定优先级根据用户需求的重要性和紧急程度，确定需求的优先级。
开发团队可以与用户进行讨论，共同确定需求的优先级，以便在开发过程中有针对性地进行工作。
2.3 确定约束条件系统需求可能会受到一些约束条件的限制，如时间、成本、技术限制等。
开发团队需要明确这些约束条件，并将其纳入系统需求的范围内。
三、用例规约与系统需求细化的优化方法优化用例规约和系统需求细化可以提高开发效率和系统质量。
第三讲课堂练习-用例图与用例规约
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. “其他”用例？
✓ “其他”、“打印清 单”用例和外围没有 任何有意义交互，和 其他用例也没有任何 关系，这么旳用例有 意义吗？
✓ “其他”用例又代表 什么呢？想阐明什么 样旳功能需求？
用例名称：预定房间 涉及旳参加者：酒店前台 描述：酒店前台人员根据旅客旳入住祈求，预定某个时间指定档次旳房间，预定
第3讲用例图
⑨系统回到管理主界面，显示所有课程，用例结束。
案例2：
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、 客房入住、退房结帐、旅客信息查询几个方面的
功能。
●
① 找出系统外部参与者，确定系统边界和范围。
●
② 确定各参与者所期望的系统行为。
柜台人员 客房预订 预订变更 入住登记 增加旅客 修改旅客信息 退房结账 信息查询
3.1 概述
1. 用例图的概念 用例图: UML用来描述软件功能的一种图形，包括用 例，参与者，及其关系，也可以包括注释和约束。
3.1 概述
2. 用例图的作用
用例图用来展现软件的功能，作用是：
● 展现软件功能； ●
展现软件使用者和软件之间的关系；
● 展现软件功能相互之间的关系。
3.1 概述
3. 用例图的要素 用例图的要素主要有：
3.4 参与者与用例之间的关系
④.给系统提供信息
有些需要给系统提供必要的信息，例如：
3.4 参与者与用例之间的关系
⑤.从系统获取信息
有些参与者需要从系统获取必要的信息，例 如：
3.5 用例之间的关系
用例之间可以具有以下几种关系：
①.泛化关系
②.包含关系
③.扩展关系
1. 泛化关系
参与者与参与者之间，用例与用例之间存在 一般与特殊的泛化关系。
2. 包含关系
两个用例之间，一个用例(基用例)的行为要 用到另外一个用例(包含用例)的行为。
包含关系用依赖关系的<<include>>构造型来 表示。
3. 扩展关系
扩展关系表示基本用例在扩展点要增加新的 行为或功能，以扩展到新用例。
第三讲课堂练习 用例图与用例规约
要求：
• 按需求简要描述为旅店预订系统创建用例 图；
• 选择一个用例进行场景描述； • 为该用例建立用例表； • 为该用例创建活动图。
3
问题用例图1
4
问题用 例图2
5
问题用例图3
6
1. 不恰当的“时间”参与者
✓ 时间：参与者，一种习惯用法，用于激活那 些系统定期的、自动执行的用例
✓ “检查是否可以退定金”的时候，时间仅仅 是一个系统内部的判断条件，而不是参与者
系电话、房间类型、预订时间、预订天数和总费用； 3) 前台人员确认取消该预定； 4) 系统取消该房间预订 n备选事件流： 2a.系统提示没有该顾客的预定信息。 4a.当取消预订在六小时之内，系统提示需要退还顾客定金。 4a1. 系统提示返回金额； 41a72.前台人员确认已退还定金； 4a3.系统记录定金已退还。
课堂练习
---用例图与用例规约
用户需求简要描述
某公司要开发一个旅店预定系统，该旅店可对外开 放豪华双人间、双人间、三人间和单人间，房间费用视 情况按季节调整，但周一到周五半价（周末全价）折扣 不变。对于外界请求，该系统应能根据请求入住时间预 定指定档次的房间，记录旅客姓名、地址、联系电话、 有效证件号、房间类型和预定天数，并计算出总费用。 预定的同时旅客按规定须提交10%定金。六个小时之内 旅店允许旅客取消预定，并退回所有定金，超过六个小 时定金不退还。每周一系统自动打印一周预定情况清单 。采用哪种费用支付方式和何种类型操作界面尚不确定 。
✓ 扩展关系： “extend”关系的方 向，子用例对主用例 的扩展
9
3. 错误的用例关系
✓ 用例的顺序在活动 图中表现
10
3. 错误的用例关系
用例规约例子
用例规约例子
以下是 6 条用例规约例子：
1. 咱就说，你去超市买东西，这不就是一个很常见的用例规约嘛！你知道自己要买啥，什么品牌、多少数量，这不就跟软件里的各种条件、步骤一样一样的嘛？比如说，你决定要买巧克力，然后选了某个牌子，接着看价格和重量，哎呀，这就跟程序里的各种设定和判断太像啦！
2. 你想想看，你每天早上起床后要做的一系列事情，也是个用例规约呀！刷牙、洗脸、换衣服，每一步都有先后顺序和特定的操作呢！就像软件运行时，一个步骤紧接着一个步骤，可不能乱了呀！比如你总不能先换衣服再刷牙吧，这多别扭呀！
3. 嘿，你知道煮饺子也是个好例子呢！先准备水，水开了下饺子，然后等饺子煮熟，捞出来，每一步都不能马虎呀！这在软件里不就相当于一个个明确的流程和规定嘛，水就像是输入，饺子煮熟就是输出，这过程多清晰啊！难道不是吗？
4. 你和朋友约着出去玩，这整个过程也是个用例规约呀！先商量去哪里，再确定时间，然后怎么碰面，一点都不能乱来呢！这不就跟程序里的流程规划一样嘛，一环扣一环的。
你再想想，如果商量不好，那可就玩不成啦，就像程序出错就运行不下去一样呀！真的好形象呀！
5. 哎呀，就连你写作业都是个典型的例子呀！先拿出本子和笔，再看题目，思考怎么做，然后开始写，最后检查。
这和软件中的用例规约简直如出一辙嘛！你可别小瞧这写作业的过程呢，像不像程序在一步步执行任务？
6. 你看那些运动员比赛，也是有他们的用例规约呀！比如跑步比赛，先站在起跑线，听口令，起跑，冲刺，每一步都很关键呀！这多像软件运行时的各种规定呀，每一个动作都得精确无误呀！不然怎么能赢得比赛呢，你说对吧？
我的观点结论就是：生活中到处都是用例规约的例子呀，真的太有意思啦！。
用例图及用例规约
京胜校园软件综合实验室用例图用户登录用例图本图共有三个角色：operator、teacher、student，operator登录到管理员模块，teacher登录到指导教师模块，student登录到学生模块。
三大模块都可以实现退出功能。
学生模块用例图学生模块又分为四大模块：我的实训，我的课程，个人中心，资料中心（如图）。
我的实训我的实训又分为四个小模块：我的消息，通知公告，我的课表，我的实训（如图）。
1.我的消息学生可以查看收件箱和发件箱的信息，并且扩展发送消息、删除消息、回复消息三种功能。
2.通知公告3.我的课表4.我的实训。
我的课程我的课程里只有一个小的模块：我的课程（如图）。
1.我的课程在我的课程里可以查看我的课程，并且扩展功能：进入课程。
资料中心资料中心分为两个小模块：下载资料和链接资料1.下载资料学生选择某一文件，便能够查看要下载的资料，在此处可以下载。
2.链接资料个人信息分为两个小模块：我的资料和修改密码1.我的资料2.更改密码指导教师模块指导教师模块分为信息管理、资源管理、实训组织、课程组织、资料管理5个模块。
信息管理信息管理又分为实训计划和投稿信箱两个模块1.实训计划指导教师可以在此查看实训计划，并且实现查看统计（查看被通知者查看信息的情况）、添加通知、删除通知、修改通知、查询（通过标题查找）5大功能。
2.投稿信箱指导教师可以在此查看投稿信箱，并且实现查询（通过投稿标题查询）功能。
资源管理资源管理模块里包含一个小模块内容管理。
1.内容管理实训组织实训组织模块又分为我的课程、实训管理、成绩管理3个小模块。
1.我的课程指导教师可以查看自己的课程，并实现查询（时间段或全部）功能。
2.实训管理3.成绩管理指导教师可以在此处查看成绩，并能实现查询（学期、班级、课程）、编辑成绩2大功能，其中编辑成绩又可以实现查看成绩、删除成绩、添加成绩、导入成绩（、查询（成绩名称）5大功能课程组织课程组织模块包含一个小的模块：课程管理。
UML用例图中的用例规约与需求分析技巧
UML用例图中的用例规约与需求分析技巧UML（Unified Modeling Language）用例图是一种常用的需求分析工具，它能够清晰地描述系统的功能需求和用户与系统之间的交互。
用例规约是用例图中的一个重要组成部分，它用于详细描述每个用例的前置条件、后置条件、基本流程和可选流程等。
在进行需求分析时，正确编写用例规约是至关重要的。
本文将介绍UML用例图中的用例规约与需求分析技巧。
首先，用例规约中的前置条件是指在执行用例之前必须满足的条件。
在编写前置条件时，需要考虑到系统的状态和环境。
例如，对于一个在线购物系统的用例，前置条件可以是用户已经登录并且购物车中有商品。
通过明确前置条件，可以确保用例的执行是可行的。
其次，用例规约中的后置条件是指在执行用例之后系统应该达到的状态。
后置条件可以是系统状态的改变，也可以是系统对外部事件的响应。
例如，对于一个银行系统的用例，后置条件可以是用户账户余额减少了相应的金额。
通过明确后置条件，可以帮助开发人员理解用例的执行结果。
接下来，用例规约中的基本流程是指用例的主要执行路径。
基本流程应该包含用例的主要步骤和相应的用户与系统之间的交互。
在编写基本流程时，需要注意步骤的顺序和合理性。
可以使用动词来描述用户的操作，使用名词来描述系统的响应。
例如，对于一个注册用户的用例，基本流程可以包括用户输入个人信息、系统验证信息的有效性、系统保存用户信息等步骤。
此外，用例规约中还可以包含可选流程，用于描述用例的扩展或异常情况。
可选流程可以是用户的选择、系统的判断或外部事件的触发。
在编写可选流程时，需要考虑到各种可能的情况，并给出相应的处理步骤。
例如，对于一个在线预订酒店的用例，可选流程可以包括用户选择支付方式、系统检测到余额不足、用户选择其他支付方式等步骤。
在进行需求分析时，编写用例规约时需要注意以下几点技巧。
首先，用例规约应该具有可读性和易理解性。
可以使用简洁明了的语言，避免使用过于复杂的术语和缩写。
UML设计-用例和用例图练习题及参考答案
学院班级管理系Leabharlann 的用例图按课程编号查询 按课程名查询
删除已选课程 <<extend >>
登录
找回密码
维护课程信息
系统管理员
帐号管理系统的用例图
系统管理员
创建新帐号
设置帐号 查询帐号 删除帐号
设置帐号基本信息 设置帐号权限
饮料自动售货机顾客购买矿泉水的用例图
显示是否有饮料 选择饮料
自动售货机
付款 找钱 提供饮料
收钱
顾客
UML 面向对象技术教程
第三章 用例及用例图 练习题及参考答案
1
练习题：
试画出学院班级管理系统的用例图。
用例有：登录；找回密码；查看、修改、删除、录入班级基本 信息，参与者有管理员与系院领导。
试画出学生成绩管理的用例图。
用例有：登录；找回密码；录入、修改、保存、查询、删除成 绩，参与者有教师与学生。
登录
<<extend >> 找回密码
系统管理员
查询班级基本信息 删除班级基本信息 修改班级基本信息 录入班级基本信息
系院领导
学生成绩管理的用例图
<<include >>
录入成绩
保存成绩
教师
修改成绩 查询成绩
学生
删除成绩 <<extend >>
第3章用例及用例图课件
总结 用例的特点
① 用例用于描述系统的功能，这个功能是外部 使用者看到的系统功能，不反映功能的实现方 式。 ② 用例描述用户提出的一些可见需求，对应一 个具体的用户目标。 ③ 用例反映系统与用户的一次交互过程，应该 具有交互的信息的传递。 ④ 用例是对系统功能的描述，属于需求建模。
13
4. 怎样确定用例的粒度
35
3.5 用例描述
• 用例名称
– 应该与用例图相符，并写上其相应的编号
• 简要说明
– 对该用例对参与者所传递的价值结果进行描述，应 注意语言简要，使用用户能够阅读的自然语言
• 前置条件
– 是执行用例之前必须存在的系统状态，这部分内容 如果在现在不容易确定可以在后面再细化
• 后置条件
– 用例执行完毕系统可能处于的一组状态，这部分内 容如果在现在不容易确定可以在后面再细化
9、UML是通过什么方法来对语言进 行扩展的？
6
教学进程
第3章
用例及用例图
3.1 用例 3.2 参与者 3.3 用例之间的关系 3.4 用例图 3.5 用例描述 3.6 用例分析
7
3.1 用例
1. 用例的概念 用例(use case): 系统、子系统或类与外部的参与者
交互的动作序列的说明，包括各种序列及出错序列。简 单的说，表示参与者与系统的一次交互过程。 用例分析可以认为是对系统功能的分解。 2.用例的表示
UML除了可以用于软件建模之外，
还可以用于(
)建模。
3
教学进程
？问题：
4、填空 UML的基本语言要素包括( )、
( ) 和 ( )。
4
教学进程
？问题：
5、UML建模元素之间可以有哪几种 关系？
第三章 用例和用例图
系统边界
… 参与者透过系统边界直接与系统交互，参与者的确定代表
系统边界的确定
有意义交互
任何事物
人、外部系统、外部因素等
武汉大学国际软件学院
12
3.2.2 识别参与者：参与者要点
•
参与者指在系统中所扮演的角色。即在确定参与者时， 应主要考虑他的角色，而不是这个角色的实例。
•
• • •
某些组织中可能有很多营销人员，但他们均起着同 一种作用，扮演着相同的角色。 … 一个用户也可以扮演多种角色：一个高级营销人员
经理
用例C
•
如系统中经理可以参加雇员 的所有用例
武汉大学国际软件学院
21
3.2.2 识别参与者：泛化关系的误用
浏览信息
注册成员
普通浏览者 搜索产品
用户
留言
登录验证身分
系统管理员
回复留言
发送邮件
武汉大学国际软件学院
22
3.2.3 识别用例（use case） 分析典型用例是开发者准确迅速地了解用户要求的最常用 也是最有效的方法，是用户和开发者一起深入剖析系统功 能需求的起点。 “用例”是Ivar Jacobson于20世纪60~70年代在爱立信公 司开发AKE、AXE系列时发明的。
武汉大学国际软件学院
29
用例要点：用户观点而非系统观点
订票 旅客 查看今日航班
处理订票
旅客 显示今日航班
用户观点
系统观点
武汉大学国际软件学院
30
用例 VS. 功能
•呼叫某人
•传输/接收 •电源/基站 •输入输出（显示、键盘） •电话簿管理 •……
•接听电话
•发送短信 •记住电话号码
•…… 用户观点
第3章用例和用例图
动用例 {显示产品类别} 2 系统显示出“在售产品”，突出显示与客户的
配置文件相关的产品类别
3.6 事件流及脚本
5.定义可选事件流
可选事件流所描述的行为是可选的、特殊的， 他总是依赖于其他事件流中某个明显位置所发 生的条件，他允许在移除行为的同时，不会影 响主事件流或其他可选事件流
特点：由基本用例决定是否调用，包含用例对调 用对象一无所知，且不参与其中的选择判断。
图形表示：
包含关系
使用包含关系的三种情况：
a. 多个用例包含大量类似的行为，应该考虑将这 些类似的行为通过包含关系包含到用例中
b.对两个或多个互相独立的用例建模时做了重复 的工作，可以通过包含关系包含这些重复的工 作
对于在某些条件下，或可选情况下的一段动作序 列，可定义为扩展用例。 基本用例本身是完整的。 使用时，基本用例有条件调用扩展用例。
如果一个用例有几种变体，可使用泛化。
常见问题
一个用例应该至少向他的一个参与者提供唯一的、 独立的价值。若发现需要依次执行几个用例来获 取有用的信息，那么一定有问题
用例的粒度大小要合适，过小的用例不会对任何 参与者产生价值，过大的用例其逻辑又比较复杂
用例图工作箱
常用工具
10个按钮
参与者规范及应用
Relations标签
列出了参与者参与的所有 关系。包括参与者与用例、 参与者与其他参与者的一 切关系
参与者规范及应用
参与者的操作
1）增加参与者 2）删除参与者
用例规范及应用
Diagrams标签
用例所拥有的模型图的 信息
用例：提取现金
1 当参与者“客户”插入银行卡时，启动用例 2 系统从卡中读取银行卡信息 3 执行子事件流“验证客户” 4 系统提示客户输入提取金额
第三讲 用例图教学ppt,复习
23
关联关系（Association）
关联关系用于描述参与者与用例之间的通信 不同的参与者可以访问相同的用例
24
包含关系（Include）
虽然每个用例的实例都是独立的，但是一个用例可以
用其他更简单的用例来描述
一个用例可以包含其它用例具有的行为，并把它所包
含的用例行为作为自身行为的一部分，这种关系称之 为“包含关系”
25
扩展关系（Extend）
扩展关系指的是一个用例可以增强另一个用例的行为
扩展用例被定义为基础用例的增量扩展
扩展用例提供了一个离散的行为，可以将自己添加到基
础（执行）用例中
基础用例提供扩展点以添加新的行为
使用扩展可以使我们在不改变基础用例的同时，根据
需要自由地往系统中添加行为
26
人、其它软件、硬件设备、数据存储或者网络 每一个执行者被定义成一种特定的角色。每一个系统之 外的实体可以用一个或者多个执行者来代表 执行者一定是在系统之外 一个执行者可以启动多个用例 一个用例也可以被多个执行者启动
38
对用例进行描述
每一个用例都需要一个描述的名字和一两句简短的话
确定系统边界
软件开发过程的初始阶段一项重要的任务是清
晰地确定未来系统边界
找出系统中有什么（这部分需要我们投入全部
精力） 对需求建模
找出系统外有什么（这部分不需要实现，但需
要考虑系统与它们的接口） 对环境建模
37
通过确定参与者和用例来确定系统边界
参与者是指在系统之外，与系统交互的所有事情，如：
扩展点是一个条件，决定扩展是否会被使用。一旦条
件满足，扩展用例就将自己加入到执行用例中。这是 与包含关系的本质区别
第03章 用例和用例图
前置条件
后置条件
一个条件列表, 这些条件必须在访问用例前得到满足
一个条件列表, 这些条件必须在用例完成之后得到满足
基本操作流程 描述用例中各项工作都顺利进行时用例的工作方式
可选操作流程 描述变异工作方式、出现异常或发生错误的情况下的路径
20 面向对象分析与设计 & UML
3.6 用例的描述
用例的描述格式(续表)
14 面向对象分析与设计 & UML
3.4.4 几种关系的比较
关系类型 关联 泛化 包含 扩展 说明 actor与use case之间 actor之间或use case之间 use case之间 use case之间 表示符号
15
面向对象分析与设计 & UML
3.5 用例图
用例图(use case diagram)是显示一组用例、参与者以及 它们之间的关系的图.
26
面向对象分析与设计 & UML
3.8 常见问题分析
(1) 用例的粒度问题
对于一个目标系统进行用例分析后得到的用 例数目有多少比较合适?
27
面向对象分析与设计 & UML
3.8 常见问题分析
(2) 用例的分解/合并 系统中相似的功能, 是合并为一个用例还是 分解为几个用例?
方法1 一中指贯穿用例的一条单一路径, 用 来显示用例中的某种特殊情况. 其它译名: 情景、场景、情节、剧本. 每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.
例：在“订货”用例中包括几个相关脚本： • 订货顺利进行的脚本; • 相关货源不足时的脚本; • 购货者的信用卡被拒绝时的脚本; • ……
酒店餐馆管理系统用例图及规约
由图可见，该用例图包括8个用例、5个参与者。
用例图的编号和名称是：1.注册与登录，2.个人信息管理，3.食品管理，4.餐台管理，5.核准菜单，6.产生报表，7.采购消费信息处理，8.消费统计。
参与者的名称：顾客，前台客服，厨房工作人员，采购员，收银员。
二、用例规约1.注册与登录1.1 简要说明本用例用于向顾客提供注册功能和注册后的登陆以及前台客服的登陆。
每位顾客必须注册后才能登录系统内订餐。
注册信息包括使用本系统的账号、密码、联系地址和电子邮件等。
注册完成后，可登录餐馆管理系统，系统将会保存这些信息，以方便管理及联系用户。
1.2 事件流1.2.1 基本流当顾客进行注册时，开始执行以下基本流：（1）系统要求顾客填写个人信息，包括使用本系统的账号、密码、联系地址、信用卡卡号、信用卡有效期和电子邮件等。
（2）顾客填写个人信息。
（3）系统验证顾客所填写的信息的格式和内容。
（4）保存该顾客信息。
（5）顾客进入登陆界面进行登录。
1.2.2 备选流1.2.2.1 顾客信息验证错误如果系统检测到顾客输入的信息格式或内容有错，例如账号中含有非法字符、输入密码和确认输入密码不一致，会给予错误提示，并清空填写错误的文本框，要求顾客重新输入。
1.2.2.2 顾客信息保存失败如果系统发现数据库中已经保存了同样账号的顾客记录，会向顾客报告保存失败的错误信息，并使页面跳回注册页面，要求顾客修改注册信息。
1.3 特殊需求无。
1.4 前置条件顾客必须首先访问餐馆管理系统的页面，然后单击注册、登录。
1.5 后置条件如果该用例成功，系统数据库中将增加一条该顾客的信息。
否则，系统维持原状。
1.6 扩展点无。
2.个人信息管理2.1 简要说明顾客注册完成后登陆系统进行订餐操作，同时前台客服也要登陆系统进行顾客信息和点餐信息的管理。
顾客登录进入餐馆个人信息管理系统页面后，通过查看基本信息以后，顾客可以进行信息的一些补充。
在预定结束时，顾客需要填写一些相关资料以形成顾客订单信息保存在该餐馆管理系统的顾客信息库中。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2. 无效的参与者泛化
参与者泛化：特殊参与者会继承泛化参与者所有的要素！ 参与者的重要性在一识别用例，如果泛化没有带来任何用例，则 这样的方法没有任何意义 在系统中如果两个参与者涉及相同的用例，则合并
8
3. 错误的用例关系
依赖关系：include, extend都是依赖关 系(dependency)的 构造型(stereotype)， 带箭头的虚线表示
12Leabharlann 5.参与者和用例间的关系 “打印报表”和 “酒店管理员” 之间的关联是 有意义的交互 吗？
13
6. 用例粒度太小
14
较为合理的用例图
<<include>> <<include>> 预订房间 计算总费用 酒店前台 <<extend>> 取消预订 退还定金 查找房间
管理人员
调整价格
时间
打印预订清单
15
较为合理的用例规格说明1
用例名称：预定房间 涉及的参与者：酒店前台 描述：酒店前台人员根据旅客的入住请求，预定某个时间指定档次的房间，预定 的同时旅客按规定须提交10%定金。 前置条件：前台工作人员必须已经登录到这个系统 后置条件：预定信息正确的记录到系统中 正常事件流： 1) 前台人员向系统提供需要预定房间的类型、时间和预定天数。 2) 系统确认有相应档次的空闲房间，并计算出总费用和定金。 3) 前台人员向系统提供旅客信息（姓名、地址、联系电话、证件号等）。 4) 系统记录旅客信息。 5) 前台人员确认已经交纳定金。 6) 系统记录房间已经预定，工作完成。 备选事件流： 2a.没有指定类型的空闲房间,可以转到第一步或者取消预定，用例结束 5a.顾客没有交纳定金，前台工作人员取消预定，用例结束。
16
较为合理的用例规格说明2
用例名称：取消预订 主要参与者：酒店前台 描述：酒店前台利用该用例来取消顾客的预定，如果在指定时间内，则取消时 需要返还顾客定金 前置条件：用户必须已经预订了某个房间 后置条件：系统将取消预定的房间恢复为空闲，并且定金已返还给顾客 正常事件流： 1) 前台人员提供给系统顾客信息，比如顾客姓名或证件号码； 2) 系统进行检查并返回该顾客的预订信息，包括顾客姓名、证件号码、联 系电话、房间类型、预订时间、预订天数和总费用； 3) 前台人员确认取消该预定； 4) 系统取消该房间预订 备选事件流： 2a.系统提示没有该顾客的预定信息。 4a.当取消预订在六小时之内，系统提示需要退还顾客定金。 4a1. 系统提示返回金额； 4a2.前台人员确认已退还定金； 17 4a3.系统记录定金已退还。
2
要求：
按需求简要描述为旅店预订系统创建用 例图； 选择一个用例进行场景描述； 为该用例建立用例表； 为该用例创建活动图。
3
问题用例图1
4
问题用 例图2
5
问题用例图3
6
1. 不恰当的“时间”参与者
时间：参与者，一种习惯用法，用于激活那 些系统定期的、自动执行的用例
“检查是否可以退定金”的时候，时间仅仅 是一个系统内部的判断条件，而不是参与者
扩展关系： “extend”关系的方 向，子用例对主用例 的扩展
9
3. 错误的用例关系
用例的顺序在活动 图中表现
10
3. 错误的用例关系
11
4. “其他”用例？
“其他”、“打印清单” 用例和外围没有任何 有意义交互，和其他 用例也没有任何关系， 这样的用例有意义吗？ “其他”用例又代表 什么呢？想说明什么 样的功能需求？
课堂练习
---用例图与用例规约
用户需求简要描述
某公司要开发一个旅店预定系统，该旅店可对外开 放豪华双人间、双人间、三人间和单人间，房间费用视 情况按季节调整，但周一到周五半价（周末全价）折扣 不变。对于外界请求，该系统应能根据请求入住时间预 定指定档次的房间，记录旅客姓名、地址、联系电话、 有效证件号、房间类型和预定天数，并计算出总费用。 预定的同时旅客按规定须提交10%定金。六个小时之内旅 店允许旅客取消预定，并退回所有定金，超过六个小时 定金不退还。每周一系统自动打印一周预定情况清单。 采用哪种费用支付方式和何种类型操作界面尚不确定。