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