系统重建先前的状态.ppt

正式型（详细型）-扩展2 系统重建先前的状态 2a 系统检测阻止恢复的异常状态 系统给出纳员发出一个出错信号，记录该错误并进入一个干净的状态 出纳员开始一次新的销售 正式型（详细型）-扩展3 3a 无效标识码： 系统发出一个出错信号并拒绝输入 出纳员可以手工输入商品标识码 2a 输入无效标识码，系统拒绝输入 4a 顾客可能购买多件相同类别的商品，因此记不记录每件商品的标识码并不重要 出纳员可以输入商品类别号以及数量 正式型（详细型）-扩展4 3-6a 顾客请求出纳员从购买的货物中去掉一件商品 3-6b 顾客告诉出纳员取消销售 3-6c 出纳员中止销售 4a 系统所输出的商品单价不是顾客所想要的 正式型（详细型）-扩展5 5a 系统检测到和外部税金计算系统之间的通信失败 5b顾客说他们符合打折条件 5c 顾客说他们帐上的存款为此次销售付款 6a 顾客说他们想付钱但没有带足够的现金 正式型（详细型）-扩展6 7a 用现金付账 出纳员输入顾客所付总款数 系统计算出应找的余款，并弹出现金抽屉 出纳员存放现金并找零给顾客 系统记录此次现金支付情况 软 件 工 程 概 论 软 件 工 程 概 论 * 参与者：系统的使用者 用例：代表系统向使用者提供的服务 用例规约 回顾 用例的概念 用例的关系 参与者的定义与关系 用例图 系统内部 系统外部 整车销售 主要内容 用例规约 黑盒用例与白盒用例 用例规约组成 用例规约类型与书写风格 简单型 非正式型 正式型（详细型） 用例规约--进行用例阐述 用例规约：更进一步的精度 用例文档的核心，而用例图作为用例文档的总图 进一步的精度：有层次的文档 文档中每一句话都有其价值 用例图是骨架 而用例规约则是其内在的肉 黑盒用例 建模人员常用，不描述系统的内部工作流程，也不描述其组成成分或设计。 白盒用例 借助责任描述系统，指出系统应该具有什么职责，具有各种职责的软件元素之间是如何合作的 黑盒用例与白盒用例 黑盒用例 白盒用例 该系统记录销售情况 该系统将销售情况写到一个数据库中或者该系统为销售情况生成一个SQL语句 用例规约组成1 用例名称：处理销售 用例标识 涉及的参与者 涉及的用例 描述 用例规约组成2 用例的规格说明 前置条件 与 后置条件 正常事件流 备选事件流 其它 非功能需求、设计约束、尚存在的问题 前置条件约束在用例开始前系统的状态 把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件 说明在用例触发之前什么必须为真 前置条件 后置条件约束用例执行后系统的状态 用例执行后什么必须为真 对于有多个事件流的用例，则应该有多个后置条件 后置条件 前置、后置条件注意 某些用例依赖于其他用例 一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”） 有助于识别漏掉的用例 如果一个用例的前置条件不执行，就不能执行其他用例，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例） 事件流-用例交互四部曲 1. 动 作 4. 回 应 2.改变 3.验证 系 统 写：可观测的、 体现客户利益的文字 事件流描述要点 一个正常的业务事件流描述 只书写“可观测”的 使用主动语句 句子必须以参与者或系统作为主语 不要涉及界面细节 分支和循环 要点1-只写“可观测”的 系统通过ADO建立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息… 系统按照查询条件搜索商品的详细信息 要点2-主动语句 欧文从贝克汉姆处得到传球，守门员… 贝克汉姆传球给欧文，欧文射门，守门员扑救… 要点3-以参与者或系统作主语 参与者…… 出纳员接收顾客的付款—顾客的付款数可能高于商品总额 出纳员录入顾客所付的现金总额 系统…… 系统显示出应找还给顾客的余额，打印付款收据 要点4-不涉及界面细节 会员从下拉框中选择类别 会员在相应文本框中输入查询条件 会员点击“确定”按钮 要点5-分支和循环 分支：放到扩展路径 参与者的选择 另一条成功线路 系统进行验证 …… 循环：直接描述 简单型 用简洁的一段话来描述用例，通常只给出主要成功场景 处理销售 一个顾客带着商品在收款处准备交费购买。 出纳员使用POS终端记录所购买的每一件商品 POS系统给出所应收的总款数以及每件商品的价格细节。 顾客键入支付信息，系统进行确认并记录。 然后，系统更新商品的存货清单 顾客拿着系统打印的收条并带着商品离开。 非正式型 用若干非正式段落来描述用例，通常给出多个不同场景 处理退货 主要成功场景：顾客带着商品到收款处退货，出纳员使用POS终端记录每一件被退回的商品。。。。 可选场景：如果系统中找不到商品标识，那么就通知出纳员并建议他手工输入商品标识码（或许商品的标识已经破损）；如果系统检测到和外部税金计算系统之间