UML用例规约

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