需求与需求获取技术方案.ppt

用例图示例 Step 5：给出用例的详细描述 单纯的用例图并不能描述完整的信息，需要用文字描述不能反映在图形上的信息。 用例名： 参与者及关注点： 主成功场景： 事件1 事件2 …… 扩展 前置条件： 后置条件： …… 事件流（场景） 用例的事件流： 说明用例如何启动，即哪些参与者在何种情况下启动用例？ 说明参与者与用例之间的信息处理过程； 说明用例在不同条件下可以选择执行的多种方案； 说明用例在什么情况下才能被视作完成； 分为常规流和扩展流两类： 常规流：描述该用例最正常的一种场景，系统执行一系列活动步骤来响应参与者提出的服务请求； 扩展流：负责描述用例执行过程中异常的或偶尔发生的一些场景。 常规事件流（场景） 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序 用一句简短的标题来概括每一步骤的主要内容 对每一步骤，从正反两个方面来描述 参与者向系统提交了什么信息 对此系统有什么样的响应 Step 1 Step 2 Step 3 Step 4 Step 5 Step 3a Step 3b Step 3c 扩展事件流（场景） 扩展流的描述格式可以与基本流的格式一致，也需要编号并以标题概述其内容。 起点：该扩展流从事件流的哪一步开始； 条件：在什么条件下会触发该扩展流； 动作：系统在该扩展流下会采取哪些动作； 恢复：该扩展流结束之后，该用例应如何继续执行。 Step 1 Step 2 Step 3 Step 4 Step 5 Step 3a Step 3b Step 3c 编写用例文本的准则 以无用户界面约束的本质风格编写用例 编写简洁的用例 编写黑盒用例 采用参与者和参与者目标的视角 [案例]用例描述1 用例：登记借书 1. 目标： 本用例允许图书管理员登记普通读者的借书记录 2 事件流： 2.1 常规流程 当读者希望借书、图书管理员准备登记有关的借书记录时，本用例开始执行。 (1) 系统要求管理员输入读者的注册号和所借图书号； (2) 图书管理员输入信息后，系统产生一个唯一的借书记录号； (3) 系统显示新生成的借书记录； (4) 图书管理员确认后，系统增加一个新的借书记录 2.2 扩展流程 (1) 读者没有注册 在主流程中，如果系统没有读者的注册信息，系统将显示错误信息，用例结束； (2) 所借图书不存在 在主流程中，如果所借图书已被借出或者系统中无该图书，系统将显示错误信息，用例结束。 3 前置条件：用例开始前，图书管理员必须在系统登录成功； 4 后置条件：如果用例执行成功，该读者的借书记录被更新，否则，系统状态不变。 [案例]用例描述2 用例名称：处理销售 参与者与关注点： 收银员：希望准确、快速地输入，而且没有支付错误，因为如果少收货款，将从其工资中扣除。 … … 前置条件：收银员必须经过确认和认证 成功保证（或后置条件）：存储销售信息。准确计算税金。更新账务和库存信息。 主成功场景（或基本流程）： 顾客携带所购商品或服务到收银台通过POS机付款。 收银员开始一次新的销售交易。 收银员输入商品条码 扩展（或替代流程）： 3a.无效商品ID（在系统中未发现）： 系统提示错误并拒绝输入该ID。 收银员响应该错误 特殊需求： 使用大尺寸平面显示器触摸屏，文本信息可见距离为1米 。。。 发生频率：可能会不断地发生 未解决问题： 提成处理规则不确定 收银员换班时如何处理 … … Step 6：细化用例模型 在一般的用例图中，只需表述参与者和用例之间的通讯关联，除此之外，还可以描述： 参与者与参与者之间的泛化(generalization) 用例和用例之间的包含(include) 用例和用例之间的扩展(extend) 根据用例描述绘制活动图 补充非功能性需求 参与者之间的关系 参与者之间可以有泛化(Generalization)关系。 actor 2 actor 1 用例之间的关系：包含(include) “包含关系”是通过在关联关系上加入include标记来表示； 语义：用例1会用到用例2（无条件执行），用例2的事件流将被插入到用例1的事件流中 一般表示为公共功能 用例1 用例2 include 用例之间的关系：扩展(extend) “扩展关系”是通过在关联关系上加入extend标记来表示； 语义：用例2在某些特定情况下（有条件执行）会用到用例1，此时，用例1的事件流将被插入到用例2的事件流中。 一般表示为异常功能，大多是扩展流程 用例1 用例2 extend 用例之间的关系：扩展(extend) 常规流： 1 拨号 2 建立通话链路 3 通话 4 挂机 扩展流： 1a 如果应答方正忙，用铃声提示应答方并保持拨号呼叫 扩展流： 1