第四章 用例.pptVIP

用例图概述 用户模型视图也称为用例图，它从用户的角度来描述系统功能，并指出各功能的操作者。用例图是捕获用户需求的强有力工具，它描述了系统应该实现什么样的功能 用例图是外部参与者所能观察到的系统功能的模型图，它将系统、子系统和类的行为可视化 用例图是获取需求的直接方法 用例图还是软件测试人员进行测试的指导 棋牌馆管理系统用例图 场景 用例是对场景的抽象，是对一组场景共同行为的抽象 关于场景 在系统中，按照某个顺序执行了一系列相关的动作后，即可实现某种功能，把完成这一功能操作的集合称为场景。 场景就是用户使用系统的一个实际的、特定的场面 一个场景就是描述软件使用者与系统之间的一系列交互活动，系统具体执行的行为路径，即一次完成的事件流。 小刘ATM机取款3000元的场景 小刘将银行卡插入柜员机 柜员机要求客户输入卡密码 小刘输入卡密码，并确认密码 柜员机屏幕提示，请客户选择服务类型 小刘选择取款服务 柜员机提示：请客户输入取款数目 小刘输入3000，并确认 柜员机出钱口输出30张100元面值的人民币 小刘取回30张100元面值的人民币 柜员机提示服务类型：确认、继续或退卡 小刘选择服务类型退卡，结束服务 关于用例 用例是对场景的抽象，体现在两方面： 1）用例是对一组场景的抽象 2）用例的取名是对场景（事件）的概括 用例图 用例图是描述用例、参与者及其关系的图。与UML的其他图一样，用例图可以包括注释、约束。 用例图由三部分构成： 参与者、一组（个）用例、关系 参与者 定义 是直接与系统（系统、子系统或类）相互作用的外部实体的抽象。它是用户所扮演的角色，是系统的用户 每个参与者定义了一个角色集合。通常，一个参与者可以代表一个人、一个计算机子系统、硬件设备或者时间等角色。 典型的参与者如销售部经理、销售员和结帐系统。 图形表示 用小人图符表示 怎样识别参与者 在定义用例之前要先确定系统的参与者，下面的问题有助于我们找出系统的参与者： 谁向系统提供信息？ 谁从系统获取信息？ 谁操作系统？ 谁维护系统？ 系统使用哪些外部资源？ 系统是否和已经存在的系统交互？ 由于系统对时间进行相应，“时间”是否也是一个参与者？ 用例 定义 对一组动作序列的描述，系统通过执行这一组动作序列为参与者产生一个可观察的结果 描述参与者使用系统，以达到某个目标时所涉及到的一系列场景的集合。 用例特征 说明了一个参与者与系统执行的一个相关的事务序列 提供了一种获取系统需求的方法 提供了一种与最终的用户和领域专家进行沟通的方法 提供了一种测试系统的方法 图形表示--用椭圆形表示，用例的名字显示在图标的下面 怎样获取用例？ 在确定了参与者之后，就要确定参与者要做什么，下面的问题可以帮助我们识别用例： 特定参与者希望系统提供什么功能？ 系统是否要存储和检索信息（涉及创建、存储、修改、删除等）？ 需要将外界的哪些信息提供给系统？ 需要将系统的哪个事件告诉参与者？ 如何维护系统？ 关系 关系反应了参与者和用例之间、用例和用例之间以及参与者和参与者之间的相互作用。 在一个用例图中，可能会出现关联关系、依赖关系、泛化关系以及这三种关系的扩展形式：扩展关系、包含关系和精化关系。 用况规约 所谓规约，就是业务规则的规格说明。针对每一个用况，都应该有一个用况规约文档与之相对应，以描述该用况的细节内容。每一个用况的用况规约，都应该包含以下内容 (1) 用况名称(Use Case Name).用况的名称一般由“动词+名词”构成，简单说明“做什么”。 (2) 简要说明(Brief Description).简要介绍该用况的作用和目的。 (3) 前置条件(Previous Condition).系统在执行该用况前必须处在的状态。 (4) 事件流(Flow of Event) 描述该用况所有可能的场景，它包括基本流和备选流。 用况规约 基本流：描述该用况在正常情况下的场景。 备选流：描述用况执行过程中一场情况或突发情况。 (5) 用况场景(Use Case Scenario).包括成功场景和失败场景，场景主要由基本流和备选流组合而成。 (6) 特殊需求(Special Requirement).描述与该用况相关的非功能性需求(性能、可靠性、可用性和可扩展性等)以及涉及约束(所使用的操作系统、开发工具等)。 (7) 后置条件(Post Condition).系统在执行完该用况之后应该处在的状态 。 “修改密码”用况规约 用况名称：修改密码 参与者：多个求职者 简要说明：求职者为了密码安全且方便使用，修改了密码 前置条件：1求职者已经登录网上求职招聘系统 2求职者输入旧密码 求职者输入新密码 基本事件流：1求职者鼠标单击“修改密码”按钮 2系统出现一个对话框，显示“密码修改成功” 3求职