• / 54
  • 下载费用:10 金币  

用例规约

关 键 词:
例规
资源描述:
用例规约 潘正军 [email protected] 13928748182 回顾 &用例的概念 &用例的关系 &参与者的定义与关系 用例图1 基于用例的需求分析过程 &详细 、完整地描述需求 Ì 用例描述 Ì 事件流描述要点 &实例 Ì POS销售 Ì 记录时间 &小结与试验 用例描述 &用例规约 &黑盒用例与白盒用例 &用例规约组 成 &用例规约类 型与书写风格 Ì 简单 型 Ì 非正式型 Ì 正式型(详细 型) 用例规约--进行用例阐述 &用例规约:更进一步的精度 Ì 用例文档的核心,而用例图作为 用例文档的总图 Ì 进一步的精度:有层次的文档 Ì 文档中每一句话都有其价值 用例图是骨架用例图是骨架 而用例规约则是其内在的肉而用例规约则是其内在的肉 谁来写用例文档 &最完美:业务 人员接受训练 ,写出 优美的用例文档 &最现实 :业务 人员提供素材,开发 人员写用例文档 &最糟糕:业务 人员不管,完全由开 发人员杜撰 &黑盒用例 Ì 建模人员常用,不描述系统的内部 工作流程,也不描述其组成成分或 设计 。 &白盒用例 Ì 借助责任描述系统,指出系统应该 具有什么职责 ,具有各种职责 的软 件元素之间是如何合作的 黑盒用例与白盒用例 黑盒用例白盒用例 该系统记录销 售情况 该系统将销售情况写到 一个数据库中或者该系 统为销售情况生成一个 SQL语句 用例规约组成 1. 用例名称:处处理销销售 2. 用例标识标识 3. 涉及的参与者 4. 涉及的用例 5. 描述 用例规约组成 6. 用例的规规格说说明 1. 前置条件 与 后置条件 2. 正常事件流 3. 备选备选 事件流 7. 其它 Ì 非功能需求、设计约设计约 束、尚存在的 问题问题 &前置条件约束在用 例开始前系统的状 态 Ì 把它们看做是看门人 ,它阻止参与者触发 该用例直到满足所有 条件 Ì 说明在用例触发之前 什么必须为 真 前置条件 &后置条件约束用 例执行后系统的 状态 Ì 用例执行后什么必 须为 真 Ì 对于有多个事件流 的用例,则应该 有多个后置条件 后置条件 前置、后置条件注意 &某些用例依赖于其他用例 Ì 一个用例在离开系统时 ,可能是另一个用 例的前置条件(例如:“登录”和“管理 系统”) &有助于识别 漏掉的用例 Ì 如果一个用例的前置条件不执行,就不能 执行其他用例,可能意味着丢失了用例( 例如:“管理订单 ”却没有“登录”用 例) 事件流-用例交互四部曲 1. 动 作 4. 回 应 2.改变 3.验证 系 统 写:可观测的、写:可观测的、 体现客户利益的体现客户利益的 文字文字 简单型 &用简洁 的一段话来描述用例,通常只 给出主要成功场景 &处理销售 Ì一个顾客带着商品在收款处准备交费购买 。 Ì出纳员使用POS终端记录所购买的每一件商品 ÌPOS系统给出所应收的总款数以及每件商品的 价格细节。 Ì顾客键入支付信息,系统进行确认并记录。 Ì然后,系统更新商品的存货清单 Ì顾客拿着系统打印的收条并带着商品离开。 非正式型 &用若干非正式段落来描述用例,通常给出 多个不同场景 &处理退货 Ì主要成功场景:顾客带着商品到收款处退货, 出纳员使用POS终端记录每一件被退回的商 品。。。。 Ì可选场景:如果系统中找不到商品标识,那么 就通知出纳员并建议他手工输入商品标识码 ( 或许商品的标识已经破损);如果系统检测 到 和外部税金计算系统之间的通信失败,那么 就。。。 &描述更多细节并以结构化方法组 织这些细节,对理解系统非常有意 &参考:http://www.usecases.org 正式型(详细型) 正式型(详细型)-处理销售1 1. 用例 UC1:处理销售 2. 主要参与者:出纳员 3. 受益人及其利益: 1.出纳员:需要精确、快速的输入,并 且不出现支付错误 2.销售人员:需要销售款得到更新 3.顾客:需要购买并花费最小的精力得 到快速的服务,并需要支持退货功能 正式型(详细型)-处理销售2 3. 受益人及其利益: 3. 公司:需要精确地记录 交易并满 足客户的利益。需要支付授权服 务记录 可接受的支付。需要一些 容错功能。需要账目和存货清单 得到自动的快速更新 正式型(详细型)-处理销售3 3. 受益人及其利益: 5.政府税务机构:需要从每一次销售 中收税。 6.支付授权服务:需要用正确的格式 和协议传 来的数字授权请 求。需 要精确计算它们可支付给商店的 款额 正式型(详细型)-处理销售4 4. 前置条件:出纳员 需要身份识别 并授权 5. 后置条件:存储了销售情况,正 确地计算了税金,更新了账目和 存货清单,记录 了销售额,打 印了收据 正式型(详细型)-处理销售5 6. 主要成功场景: 1.顾客带着商品到POS终端出准备 购买 2.出纳员开始一次新的销售 3.出纳员输入商品标识码 4.系统记录销售的商品并给出商品 的描述、单价和折扣,并根据某些 价格规则计算所应付的款额。出纳 员重复步骤3和步骤4,一直到处理 完所有商品为止。 正式型(详细型)-处理销售6 6. 主要成功场景: 5. 系统给出所应支付的总款额并计算 税金 6. 出纳员告诉顾客总价并请求付款 7. 顾客付款,系统处理支付 8. 系统记录下已完成的销售,并将销 售和支付信息发送给外部的账目系 统以及存货清单系统 正式型(详细型)-处理销售7 6. 主要成功场景: 9. 系统打印收据 10.顾客带着收据和商品离开 正式型(详细型)-扩展1 1. 在系统失败时 ,要恢复和校正 账目,确保所有的交易敏感状 态以及事件能够从场景的任何 步骤中恢复 1.出纳员 重启系统和登录,并请 求恢复先前的状态 正式型(详细型)-扩展2 2. 系统重建先前的状态 2a 系统检测 阻止恢复的异常状态 1.系统给 出纳员发 出一个出错信号 ,记录该错误 并进入一个干净的状 态 2.出纳员 开始一次新的销售 正式型(详细型)-扩展3 3a 无效标识码: 1.系统发出一个出错信号并拒绝输 入 2.出纳员可以手工输入商品标识码 2a 输入无效标识码,系统拒绝输入 4a 顾客可能购买多件相同类别的商品 ,因此记不记录每件商品的标识码 并不重要 1.出纳员可以输入商品类别号以及 数量 正式型(详细型)-扩展4 3-6a 顾客请求出纳员从购买的货物 中去掉一件商品 3-6b 顾客告诉出纳员取消销售 3-6c 出纳员中止销售 4a 系统所输出的商品单价不是顾客 所想要的 正式型(详细型)-扩展5 5a 系统检测到和外部税金计算系统 之间的通信失败 5b顾客说他们符合打折条件 5c 顾客说他们帐上的存款为此次销 售付款 6a 顾客说他们想付钱但没有带足够 的现金 正式型(详细型)-扩展6 7a 用现金付账 1.出纳员输入顾客所付总款数 2.系统计算出应找的余款,并弹出 现金抽屉 3.出纳员存放现金并找零给顾客 4.系统记录此次现金支付情况 正式型(详细型)-扩展7 7b 用信用卡付账 1.顾客输入他们的信用卡帐户信息 2.系统向外部支付授权服务系统发出支 付请求授权,并请求支付批准 2a系统检测到和外部系统之间协作上的失败 : 1.系统给出纳员发出一个出错信号 2.出纳员请顾客用其他方式付款 正式型(详细型)-扩展8 7b 用信用卡付账 3.系统收到批准支付回应并向出纳员发 出一个批准支付信号 3a 系统受到拒绝该支付信号 1.系统发拒绝支付信号给出纳员 2.出纳员请顾客用其他方式付款 4.系统记录信用卡支付情况,其中包 括批准支付情况 正式型(详细型)-扩展9 7b 用信用卡付账 5. 系统给出信用卡支付签名输入机 制 6.出纳员请客户进行信用卡支付签 名,客户输入签名 正式型(详细型)-其他扩展 7c 用帐单付款 7d 赊账 7e 顾客拿出优惠券 9a 商品打折 9b 顾客请求赠品收据 正式型(详细型)-特殊需求 &应具有一个大的扁平面板监视器上的 触摸屏界面,并可在1m之外看清屏幕 上的字 &信用卡授权90%的情况下能在30s内作 出响应 &当访问诸如库存清单等这类远程服务 时,应具有健壮的恢复功能 正式型(详细型)-特殊需求 &文本显示应语言国际化 &可在步骤3和步骤7插入业务规则 &。。。。。 正式型(详细型)-其它1 &技术和数据约束列表 3a 商品标识码由条形码激光扫描器或键盘输入 3b 商品标识符可以使UPC、EAN、JAN、SKU编码 格式 7a 信用卡账目信息由信用卡阅读器或键盘输入 7b 信用卡支付签名可以在纸上进行。但未来两 年内,顾客可能更愿使用数字签名 正式型(详细型)-其它2 &发生频率:几乎可以连续发 生 &尚未解决的问题 Ì税法变化怎么办 Ì远程服务恢复问题 Ì不同的业务 需要什么样的自定义功能 Ì出纳员 退出系统时 必须带 走现金抽 屉吗 Ì顾客使用信用卡阅读 器还是出纳员 使 用 事件流描述要点 一个正常的业务 事件流描述 1. 只书写“可观测 ”的 2. 使用主动语 句 3. 句子必须以参与者或系统作为 主语 4. 不要涉及界面细节 5. 分支和循环 要点1-只写“可观测”的 &系统通过ADO建立数据库连接 ,传送SQL查询语句,从“商品 表”查询商品的详细信息… &系统按照查询条件搜索商品的 详细信息 要点2-主动语句 &欧文从贝克汉姆处得到传球 ,守门员… &贝克汉姆传球给欧文,欧文 射门,守门员扑救… 要点3-以参与者或系统作主语 &参与者…… Ì 出纳员接收顾客的付款—顾客的付 款数可能高于商品总额 Ì 出纳员录入顾客所付的现金总额 &系统…… Ì 系统显示出应找还给顾客的余额, 打印付款收据 要点4-不涉及界面细节 &会员从下拉框中选择类别 &会员在相应文本框中输入查询 条 件 &会员点击“确定”按钮 要点5-分支和循环 &分支:放到扩展路径 Ì 参与者的选择 Ì 另一条成功线路 Ì 系统进 行验证 Ì …… &循环:直接描述 用例规约:记录时间 &UC01:“Record Time”用例文档 &用例名称:Record Time(记录时间 ) &用例标识 :UC01 &涉及的参与者:雇员员、系统统管理员员 &涉及的用例:无 &描述:雇员员利用“Record Time”用例来登记记 他们们的工时时,系统统用这这个用例为为任何雇员员 登记时间记时间 用例规约:记录时间(续) &前置条件: Ì 用户户必须须已经经登录录到这这个系统统 &后置条件: Ì 系统统将雇员员的工时时正确的记录记录 到 数据库库中 用例规约:记录时间(续) &正常事件流: 1.雇员查员查 看当前时间时间 之前输输入的 数据; 2.雇员员从已有的支付号码码中选择选择 一 个,这这些收费费代码码是按客户户和项项目 组织组织 的; 3.雇员员从当前的时间时间 段选择选择 一个 日期; 4.雇员输员输 入以正整数表示的工时时 ; 5.系统统在视图视图 中显显示这这个数据,并 在以后的视图视图 中看到这这个数据。 用例规约:记录时间(续) &备选 事件流1:雇员更改他的时 间 1.雇员查员查 看当前时间时间 之前输输入 的数据; 2.雇员选择员选择 一个已有的条目; 3.雇员员改变变工时时; 4.在视图视图 中更新这这个信息,并在 以后的视图视图 中都可以看到。 用例规约:记录时间(续) &非功能需求:无 &设计约 束:无 &部署约束: Ì用户户可以从客户户端或雇员员的家中访访 问问到“Record Time”用例,如果 是从客户户端访问访问 ,则则要考虑虑到客 户户端的防火墙墙 用例规约:记录时间(续) &未解决的问题 1. 雇员员是否可以在以前的考勤卡 上输输入和更改时间时间 2. 雇员员是否可以在以后的考勤卡上 输输入和更改时间时间 ,例如,在休假之 前? 小结 &进行用例阐述 Ì 成功场景(正常事件流的描述) Ì 扩展场景(备选 事件流) Ì 约束等 Ì 需要解决的问题 思考 &用例阐述有几种方法 ? &各使用在什么情况下 ? &什么是事件流? 实验05 &编写用例规约 &要求每个成员都要分配一个 或多个,形成word文档。 谢谢谢谢
展开阅读全文
  麦档网所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
0条评论

还可以输入200字符

暂无评论,赶快抢占沙发吧。

关于本文
本文标题:用例规约
链接地址:https://www.maidoc.com/p-15699669.html

当前资源信息

农民佰佰

编号: 20180817234348112721

类型: 共享资源

格式: PPTX

大小: 704.92KB

上传时间: 2019-11-09

相关搜索

关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

[email protected] 2018-2020 maidoc.com版权所有  文库上传用户QQ群:3303921 

麦档网为“文档C2C模式”,即用户上传的文档所得金币直接给(下载)用户,本站只是中间服务平台,本站所有文档下载所得的金币归上传人(含作者)所有。
备案号:蜀ICP备17040478号-3  
川公网安备:51019002001290号 

本站提供办公文档学习资料考试资料文档下载


收起
展开