chapter06用例图(二).pptVIP

Review 用例图定义 由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态模型图称为用例图。 参与者 用例 关系 Review 参与者（Actor） Review 用例（Use case） 关系 包含关系误用 某些步骤在多个用例重复出现，且单独形成价值 扩展关系误用 用例图关系实例 用例之间的关系：包含关系 包含关系用构造型《include》表示 是指基用例（base use case）在它内部说明的某一个位置上显式地合并了另一个用例的行为 用例之间的关系：扩展关系 包含关系用构造型《extend》表示 表示基用例在由扩展用例间接说明的一个位置上，隐式地合并了另一个用例的行为 用例之间的关系：泛化关系 用例间的泛化表示子用例继承了父用例的行为和含义 子用例还可以增加或覆盖父用例的行为；子用例可以出现在父用例出现的任何位置 读图小结 这张用例图首先定义了三个基用例：预订座位、安排座位和处理结账 客户通过Internet启动“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息”（被包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“处理等候队列”。 总台服务员在客户到棋牌馆时，启动“安排座位”用例，在执行过程中，将启动被包含用例“检查座位信息”。 当客户要离开棋牌馆时，总台服务员将启动“处理结账”用例，并且定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理银行卡结账”，而后一个用例将通过与外部系统“银联POS系统”交互来完成。 用例关系的准则 不要过度使用用例关系，更不要将用例关系用到编程中。用例的目标是阐明需求。实现需求可以有许多种方式，不应该在完全理解问题之前局限于一种方法。下面是其他的一些准则： 用例泛化。如果一个用例有几种变体，那么就用抽象用例来对公共的行为建模，然后再特化每种变体。 用例包含。如果一个用例包含有一段定义良好且有可能在其他场合也用的行为片段，那么就为该行为片段定义一个用例，并把该用例包含在原始用例当中。在大多数情形下，应该把被包含用例看成是一项有意义的活动，而不要看成是一种目的。 用例扩展。如果用可选择性来定义一项有意义的用例，那么要把基行为建模成用例，并用扩展关系来增加特性。这样会允许在没有扩展的情况下测试和调试系统，可以在后面加入扩展。系统有可能会被部署到不同的配置环境中，可以使用扩展关系，有些配置会有附加的特性，而有些可能没有。 包含关系和与扩展关系。包含关系和扩展关系都可以把行为分解成较小的片段。但是包含关系意味着被包含行为是配置系统中的一个必要的部分（即使该行为不是每次都会执行），而扩展关系则暗示着没有增加行为的系统也会是有意义的（即使不是特意那样配置的） 用例粒度 用例的粒度指的是用例所包含的系统服务或功能单元的多少。 用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。 用例粒度 用例粒度 如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。 如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析 用例粒度 用例粒度 用例规约 用例描述：事件流 用例描述的是一个系统做什么（what）的信息，并不说明怎么做（how）。 基本事件流 基本事件流是对用例中常规、预期路径的描述（有时被称为Happy day场景），这是大多数用户在大部分时间中所采取的路径。 通常体系了系统的核心价值。 扩展事件流 系统还需要进行意外处理 非功能需求(URPS) 可用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 设计约束 用Oracle数据库平台，用PB开发… 软件必须符合ISO×××标准 …… 本质上不是需求，只是从商业、行政、技术上的约束 前置、后置条件 前置条件约束在用例开始前系统的状态 把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件 说明在用例触发之前什么必须为真 后置条件约束用例执行后系统的状态 用例执行后什么必须为真 对于有多个事件流的用例，则应该有多个后置条件 事件流编写要点 使用简单的语法：主语明确，语义易于理解 明确写出“谁控制球”：通常就是指出参与者； 从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是跳开来； 显示过程向前推移：也就是每一步都有前进的感觉（例如：用户按下tab键就不够）； 显示执行者的意图而非动作（光有动作，让人不容易直接从事件流中理会用例