面向对象与设计5用例建模分析.ppt

* 应避免的误解 应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型， 用例图只是在总体上大致描述了系统所能提供的各种服务，对于系统的功能有一个总体的认识。 除此之外，还需要描述每一个有例的详细信息，这些信息包含在用例规约中。 用例模型是由用例图和每一个用例的详细描述――用例规约所组成的 * 描述用例 对用例的功能描述，可采用自然语言，也可以采用用户定义的语言。 大多数用例是简单的；只是一个操作的逻辑序列，该序列具有一个来自外界的出发操作。 有一些用例要复杂一些，具有多个例外的情况（例如出错）或不同的交互路径（可进行分支）。 * 细化用例描述 为什么细化用例描述? 描述软件需求 为后续的开发准备一个系统功能描述 在事件流中描述更为详细的信息 参与者做了什么动作 系统是如何响应的 系统和参与者之间交换了哪些信息 描述用例场景 成功场景 失败场景 描述额外的用例信息 前置条件 后置条件 * 用例文本表示法 用例编写没有固定格式，根据个人需要编写，关键是详细编写主流程及备选流程 单栏分格 双栏格式（分离参与者与系统的处理步骤） 不需要描述界面信息 编写黑盒用例，不对系统内部工作、构件或设计进行描述 * Pos系统处理销售用例 用例命名，一般是动词+名词结构 各小节含义 范围 用例描述的是对一个系统的使用，为系统用例 说明所要设计的系统 级别 用例的级别，依据用例服务的对象分为用户目标级别和子功能级别 主要参与者 调用此用例提供的服务完成目标的主要参与者 * 涉众及其关注点 此用例参与的对象关注点所在，建议了系统必须要做的事情 前置条件和成功保证 前置条件：假设条件，满足假设后用例才可能执行，应编写引起分析员警惕，值得注意的前提条件。 后置条件（成功保证）：用例成功后必须满足的事情。保证满足所有涉众的需求 主流程 满足涉众关注点的典型成功路径。不包含任何条件和分支 * 备选流程 描述除其他场景和分支，包括成功和失败路径。 替代流是主流程的分支，需要对对应步骤进行标识 默认情况下，替代流程执行完后重新汇入主流程 执行其他用例 用例产生分支执行其他用例 特殊需求 与用例相关的非功能性需求、质量属性和约束 技术和数据变化可能 以后可能会发生的技术或数据上的变化可能 如：输入或输出技术的约束 * 描述用例的另一种框架 * 事件流 流：是指一系列的步骤 一个基本流 最顺利的场景 从开始到结束一切都顺利的场景 很多个备选流 除基本流之外的另外一些正常场景 偶尔发生的场景 异常或错误处理 * 描述用例框架 基本流 是什么事件启动了用例? 用例是如何结束的? 用例中最常用到的行为是什么? 备选流 在用例中有无可选执行的情况? 那些行为是偶尔才发生的? 是否有没有包含在基本流中的正常情况? 发生错误的情况下该如何处理? * 表示基本流和备选流 编写用例准则 以无用户界面约束的风格编写用例 摒除界面细节描述 编写简洁的用例 编写黑盒用例 不对系统内部工作、构件或设计进行描述 采用参与者和参与者目标的视点 强调提供可观察的用户价值并关注用户的典型目标 * 示例：Monopoly游戏 以软件模拟方式运行，展示游戏。 * * 示例：ATM自动取款机用例图 * 例：ATM验证客户身份 用例规约：验证客户身份 简要说明 该用例描述ATM机是如何验证客户身份的。 事件流 客户使用ATM机提供的各项服务之前，必须先通过该用例来进行用户身份验证。 基本流（主成功场景） 客户将信用卡插入系统 系统读取信用卡上的客户帐号信息，并向后台服务器系统确认该信用卡的有效性 系统提示客户输入信用卡密码 客户输入6位密码，系统向后台服务器检查用户密码是否正确 客户通过身份验证后，系统显示操作主菜单供客户选择查询、提款、转帐服务 客户选择他所需要的服务。 * 备选流 2a. 无效信用卡：在基本流步骤1中，客户插入的信用卡在后台服务器中没有对应的帐号 系统显示错误信息并退出信用卡，用例结束。 4a. 密码不正确：客户输入错误的信用卡密码 系统提示客户重新输入密码 客户重新输入密码后继续基本流中的下一个步骤；如客户输入密码错误超过３次，系统没收客户插入的信用卡，用例结束。 *a. 退出: 在基本流的任何一个步骤中，客户都可以选择“取消(Cancel)”退出，系统退出信用卡，用例结束。 * 用例场景 成功场景 通过客户身份验证：基本流 取消客户身分验证：基本流，退出 失败场景 无效信用卡：基本流，无效信用卡 重新输入客户密码：基本流，客户密码不正确 没收客户信用卡：基本流，客户密码不正确（密码输错3次以上） 特殊需求 验证信用卡和客户密码操作必须在５秒钟内完成。 前置条件 ATM机系统必须已经启动，并且跟后台服务器建立连接。 后置条件 无 扩展点 无 * 练习：描述