chapter06用例图用例建模作业.ppt

  1. 1、本文档共36页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
* 用例规约 用例规约用来描述用例的,不是用例图 用例规约该写什么? 用例规约需要与用例图相对应 用例的名称 用例描述:一句完整的话 用例间的关系 用例与参与者的关系 事件流的详细程度 事件流之间的流转 * 用例规格描述常见错误 用例描述中没有主参与者。 用例描述中只有参与者动作,没有系统动作。 事件流中的动作没有主语。 描述中有过多的用户操作细节,如按钮等界面元素的具体实现。 描述过低的目标级别。 * 较为合理的用例图(二) 争论: 使用包含还是扩展? * 较为合理的用例规格说明1 用例名称:预定房间 涉及的参与者:酒店前台 描述:酒店前台人员根据旅客的入住请求,预定某个时间指定档次的房间,预定的同时旅客按规定须提交10%定金。 前置条件:前台工作人员必须已经登录到这个系统 后置条件:预定信息正确的记录到系统中 主事件流: 1) 前台人员向系统提供需要预定房间的类型、时间和预定天数。 2) 系统确认有相应档次的空闲房间,并计算出总费用和定金。 3) 前台人员向系统提供旅客信息(姓名、地址、联系电话、证件号等)。 4) 系统记录旅客信息。 5) 前台人员确认已经交纳定金。 6) 系统记录房间已经预定,工作完成。 备选事件流: 2a.没有指定类型的空闲房间,可以转到第一步或者取消预定,用例结束 5a.顾客没有交纳定金,前台工作人员取消预定,用例结束。 * 较为合理的用例规格说明2 n用例名称:取消预订 n主要参与者:酒店前台 n描述:酒店前台利用该用例来取消顾客的预定,如果在指定时间内,则取消时需要返还顾客定金 n前置条件:用户必须已经预订了某个房间 n后置条件:系统将取消预定的房间恢复为空闲,并且定金已返还给顾客 n正常事件流: 前台人员提供给系统顾客信息,比如顾客姓名或证件号码; 系统进行检查并返回该顾客的预订信息,包括顾客姓名、证件号码、联系电话、房间类型、预订时间、预订天数和总费用; 前台人员确认取消该预定; 系统取消该房间预订 n备选事件流: 2a.系统提示没有该顾客的预定信息。 4a.当取消预订在六小时之内,系统提示需要退还顾客定金。 4a1. 系统提示返回金额; 4a2.前台人员确认已退还定金; 4a3.系统记录定金已退还。 * 用例规约:预定房间 …… 涉及的用例:计算总费用 前置条件:用户成功登录 正常事件流: 1.用户选择预定房间后启动该用例 2.系统显示用户可以预定的房间列表 3.用户选择某一个房间 4.系统启动“计算总费用”用例,来计算该房间的费用 5.用户确认本次预定业务 6.用户选择支付方式,以便预付定金 …… 知识回顾Knowledge Review * * * * 系统边界问题:业务建模,定义业务活动,识别相关的业务参与者 * * 周一问题 * * * * * * 如何理解存在的问题?写用例规约就知道了! * 李鹏飞 pengfei0302@ UML系统分析与设计 UML-System Analysis Design 第6 章用例建模作业 Use-Case Modeling * 旅店管理系统 某公司要开发一个旅店管理系统,该旅店可对外开放10个双人间和10个单人间,房间费用视情况按季节调整,但周一到周五半价(周末全价)折扣不变。对于外界请求,该系统应能根据请求入住时间预定指定档次的房间,记录旅客姓名、地址、联系电话、有效证件号、房间类型和预定天数,并计算出总费用。预定的同时旅客按规定须提交10%定金。六个小时之内旅店允许旅客取消预定,并退回所有定金,超过六个小时定金不退还。每周一系统自动打印一周预定情况清单。采用哪种费用支付方式和何种类型操作界面尚不确定。 * 问题用例图1 领导的角色没有价值; 旅店房间预订系统用例没有意义 * 问题用例图2 用例图不描述业务流程 图中箭头不代表前后顺序 * 问题用例图3 用例图不描述程序流程 不描述控制逻辑 * 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 识别参与者 识别用例 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 识别用例间的关系 对用例进行组织和分包 * 1 识别参与者 参与者,Actor 关键词:边界 参与者:在系统之外,透过系统边界与系统进行有意义交互的任何事物 * 1 识别参与者 参与者要点 系统外 参与者代表在系统边界之外的真实事物,并不是系统的成分 系统边界 参与者透过系统边界直接与系统交互,参与者的确定代表系统边界的确定 有意义的交互 考虑责任边界,非物理边界 任何事物 人、外系统、外部因素、时间 * 识别参与者思路 谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维

文档评论(0)

xiangxiang + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档