2编写用例叙述1.ppt

第1章 业务建模(续) 如何写用例 也称之为用况，是一个描述型文档，用来描述一个参与者（一个外部的主动者）使用系统完成某个过程时的事件发生顺序。 通俗而言，用例就是如何使用系统来达到目标的一组情节，其本质是通过写出多种使用系统的情节来发现和记录功能性需求 怎么开始？ 讲“故事”——高层用例 写出多种使用系统的情节——由一两个人写出一个简短而完整的描述，如： 2.1 描述用例 用例描述了系统和它的用户之间在一定层次上的完整的交互 在用例的不同实例中将发生什么样的细节，会在很多方面有所不同 一个用例实例中可能会出现差错，将不能达到原来的目的 一个用例的完整描述必须指明，在用例所有可能的实例中可能发生什么 2.1 描述用例 用例描述可能包含大量信息，需要某种系统的方法来记录这些信息 UML没有定义一种描述用例的标准形式 许多开发人员定义了用例描述的模板 归档用例 基本用例 每一个用例必须包含这样一些细节，这些细节告诉人们需要完成哪些步骤才能实现这个用例的功能 基本功能 所有可选方案 异常情况 进入用例之前以及退出用例时必须正确的一切 一个用例格式模版 主要参与者 涉众及其兴趣 前置条件 成功后的保证（后置条件） 主要成功场景（或基本流程） 扩展（或替代流程） 特殊需求 技术与数据的变化列表 参与者与涉众的关系 涉众也称干系人,是与要建设的这个系统有利益相关的一切人和事,涉众的利益要求会影响系统的建设。 涉众不等于用户。 涉众建议并界定了系统必须要做的工作。用例应该满足包含所有涉众关注点的事物。 参与者、涉众、用户和角色的关系 涉众（续） 如ＰＯＳ系统进行处理销售用例中，主要参与者是收银员，那么涉众有什么呢？ 前置条件和后置条件 前置和后置条件表示用例开始状态和结束会发生什么 前置：规定了在用例中的一个场景开始之前必须为“真”的条件 后置：规定了在用例中的一个场景成功结束后必须为“真”的条件 以记录销售为例 前置条件：什么情况下销售员可以记录销售？ 收银员必须已经被识别和授权？ 系统启动？ 以记录销售为例 后置条件：记录销售完成后，系统要达到什么状态？ 存储销售信息 生成收据 更新账目和库存 准确计算税金 事件路径 用例描述必须定义在执行用例时用户和系统之间可能的交互 基本事件路径：用例的主要目标可以没有任何问题并且不中断地到达 可选的事件路径：一些可选的功能会被调用 例外的事件路径：发生错误时的处理 主要的成功场景和步骤（基本路径） 它描述了能够满足项目相关人员兴趣的典型的成功路径 参与者与系统的交互 一个验证动作 由系统完成的状态改变 （第一个步骤用来指示一个用来开始场景的触发事件） 事件路径要记录的重要事情是用户输入到系统的信息，而不是该信息是如何获得的。 包含上下文的交互（情景对话）会降低用例的可复用性 例，网上订货基本路径 1.当客户选择订购货物时用例开始 2.客户输入他的姓名和地址 3.客户输入产品代码 4.系统记录单件商品，并显示该商品的描述、价格和累加值。价格可以根据一套定价规格来计算 客户重复3-4步，直到结束 5.客户输入支付信息 6.客户确认订购 7.系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息 8.支付确认后，订单被标记上已经确认，同时返回给客户一个订单ID，用例结束 1.顾客携带购买的商品到达POS机收费口 2.收银员开始一次新的销售 3.收银员输入商品标识 4.系统记录单件商品，并显示该商品的描述、价格和累加值。价格可以根据一套定价规格来计算 收银员重复3-4步，直到结束 5.系统显示总值并计算税金 6.收银员请顾客付款 7.顾客支付，系统处理支付 8.系统记录完整的销售信息，并将销售和付款信息发送到外部的记账系统（进行记账）和库存系统 9.系统打印收据 10.顾客带着商品和收据离开 可选事件路径描述的情况，可以作为营业的一个正常部分出现，它们并没有指出产生了误解，或者发生了错误 因为一个错误和用户的疏忽而不可能完成基本事件路径，这些情况将由例外事件路径描述 不同类型的事件路径之间区分是非正式的，它可以使用例的总体描述组织得更容易理解 不值得花过多时间去决定一个特定的情况是可选的还是例外的，更重要的是一定要确认给出了必须行为的详细描述 扩展（替代/可选流程） 扩展场景是从主要成功场景中分支出来的，因此应该遵从主要成功场景的标记方式 寻找扩展路径的方法P73 方法一：沿着基本路径一条一条地找，并且考虑： 在这个点上还可以执行别的活动吗？ 在这个点上有没有什么可能出错的？ 有什么随时可能发生的行为吗？ 寻找扩展路径的方法P73 如何描述扩展？ 描述指导原则：以系统或参与者能够监测到的某事物作为条件 扩展处理也可以包含一系列步骤： 角色与头衔？ 说法一：参与者用角色命名