Lecture4.pptVIP

系统分析与设计 第六章 用例和用例模型 目标： 确定和编写用例 使用摘要、非正式和详述等用例形式 将测试应用于适当的用例上 将用例分析与迭代开发联系起来 6.1 什么是用例 用例是文本形式的情节描述，用于描述某参与者使用系统以实现某些目标的情节。 例如下面的文本描述就是处理销售的摘要形式的用例： 处理销售的摘要形式 处理销售：顾客携带所购商品到达收银台。收银员使用POS系统记录每件商品。系统连续显示累计总额并逐行显示细目。输入顾客支付信息，系统对支付信息进行验证和记录。系统更新库存信息。顾客从系统得到购物小票，然后携商品离开。 6.2 为什么使用用例 用户的参与是软件成功的重要保证。用例是一种优秀的方法，使领域专家和用户能共同参与以提供正确的需求，用例强调了用户的目标和观点。 用例能够根据需要对复杂程度和形式化程度进行增减调节。 用例强调了功能性需求，即“FURPS+”中的“F”，也可用于其他需求，用例是发现和定义需求的核心机制。用例定义了系统行为的契约。 6.3 用例和用例模型(Use-Case Model). UP在需求科目中定义了用例模型。用例建模主要是编写文本的工作，用例模型是文本文挡，它是所有书面用例的集合，也是系统功能性和环境的模型。 用例模型还可以包含UML用例图，以显示用例和参与者的名称及其关系。 用例不是面向对象的，也不进行OO分析，但是用例是经典的OOA/OOD的关键需求输入。 6.4 参与者、场景和用例 1.参与者 参与者(actor)是某些具有行为的事物，可以是人、计算机系统或其它机构、相关的软件系统甚至是系统自身（当它调用其它系统的服务时）。有三种参与者： 1）主要参与者，用例的发起者，具有用户目标。 2）协助参与者，为系统提供服务的系统或机构。 3）幕后参与者，在用例行为中具有影响或利益关系，如销售系统中要考虑到政府税收机构。 2.场景 场景(scenario)是参与者和系统之间的一系列特定的活动和交互，场景也称为用例的实例(use case instance),一个场景是使用系统的一个特定情节或用例的一条执行路径。 因此，用例就是一组相关的成功和失败的场景集合。其中每一个场景都是系统执行的一系列活动，这些活动产生了对某个参与者可观察的返回值。 场景分为主成功场景和非主成功场景。 6.5 用例的三种常用形式 用例可用三种不同形式化程度或格式进行编写： 1.摘要形式：简洁的一段式概要。通常用于主成功场景。摘要形式用在早期需求分析中，为快速了解主题和范围，几分钟完成。 2.非正式形式：非正式的段落格式。用几个段落覆盖不同场景。非正式形式也是用在早期需求分析中，但主要用于交替场景，而非主场景。 3.详述形式：详细编写所有步骤及各种情况，同时具有补充部分，如前置条件和成功保证（后置条件）。详述形式在以摘要形式编写了大量用例后使用，在多次迭代中逐步完善。在第一次需求讨论会中，通常只详细编写其中少量（如10%）的具有重要架构意义和高价值的用例。 6.6 详述形式的用例的模板 用例的组成部分 注释 用例名称 以动词开始 范围 要设计的系统 级别 用户目标或子功能 主要参与者 调用系统使之交付服务 涉众及其关注点 关注该用例的人及其关 心的需求 前置条件 值得提醒的开始前必为 真的条件 成功保证 值的提醒的成功必须满 足的条件 主成功场景 典型的无条件的理想下 的成功场景 扩展 成功或失败的替代场景 特殊需求 相关的非功能性需求 技术或数据变元表 不同的I/O方法和数据格式 发生频率 会影响对实现的调查、测 试和时间安排 杂项 一些未决问题 6.7 详述