第三讲课堂练习 用例图与用例规约.
用例规约
用户登录用例图用例规约：用例名称：登录用例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. 扩展关系
扩展关系表示基本用例在扩展点要增加新的 行为或功能，以扩展到新用例。
- 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%定金。六个小时之内旅 店允许旅客取消预定，并退回所有定金，超过六个小时 定金不退还。每周一系统自动打印一周预定情况清单。 采用哪种费用支付方式和何种类型操作界面尚不确定。