需求分析和用例模型课件.ppt

3.包含关系 3.包含关系 3.包含关系 3.包含关系 使用场合 如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系（如之前介绍的饮料自动售货机）。 一个用例的功能太多时，可以使用包含关系建立若干个更小的用例。（如学生管理系统） 意义 有助于将来实现系统时，确定哪些功能可以重用，在编写代码时就可以实现代码的重用，缩短开发周期。 注意：执行基用例时，每次都必须调用被包含用例。 包含关系误用 用例之间的各种关系 4.扩展关系 扩展关系是一个用例被定义为基础用例的增量扩展，通过扩展关系把新的行为插入到已有用例中。扩展关系中，扩展用例是基础用例的一个相对独立并且可选的用例。 在UML中，扩展关系用虚线箭头加extend表示，箭头指向基础用例，即被扩展的用例 4.扩展关系 4.扩展关系 课表查询系统 4.扩展关系 使用场合 对扩展用例的限制规则：将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中。 扩展关系误用 实例分析：棋牌馆管理系统 实例分析：网上书店 用例粒度 用例的粒度指的是用例所包含的系统服务或功能单元的多少。 用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。 用例粒度 比较下列两图用例的粒度 用例粒度 如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析 用例粒度 错误一：把步骤当用例 身份验证 用例粒度 错误二：把系统活动当用例 用例规约 用例图只是在总体上大致描述了系统所提供的各种服务，让用户对系统有一个总体的认识。但对于每一个用例还需要有详细的描述信息，以便让其他人对于整个系统有一个更加详细地了解，这些信息包含在用例规约之中。 用例模型指的也不仅仅是用例图，而是由用例图和用例的详细描述——用例规约所组成的。 用例图是骨架，而用例规约则是其内在的肉 用例规约 用例规约包含以下内容： 1 简要说明:对用例作用和目的的简要描述。 2 事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。 3 用例场景:同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景，也可以说用例场景就是用例的实例。 4 特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。 5 前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。 6 后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。 事件流 说明用例如何开始和结束。只说明属于该用例的事件，而不是发生在其他用例中或系统外部的事件。 避免不明确的术语，如“例如”、“等等”和“信息” 事件流 在事件流里要对事件流进行结构化说明 基本事件流 描述每个情节的行为者:目标语句对的顺序 假设之前的每一步都是成功的 备选事件流 异常情况 特殊需求 非功能需求(URPS) 可用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 设计约束 用Oracle数据库平台，用PB开发… 软件必须符合ISO×××标准 …… 本质上不是需求，只是从商业、行政、技术上的约束 用例规约实例 用例规约实例 用例规约实例 需求分析和用例模型 第3章 需求分析与用例模型 在软件工程中，需求分析指的是在建立系统时描写系统的目的、范围、定义和功能时要做的所有工作。 需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师要确定顾客的需求。 第3章 需求分析与用例模型 软件开发过程中常见的场景 第3章 需求分析与用例模型 什么是需求？ 第3章 需求分析与用例模型 在统一过程（UP）中，需求按照“FURPS”模型进行分类。 功能性（Functional）：特性、功能、安全性； 可用性（Usability）：人性化因素、帮助、文档； 可靠性（Reliability）：故障频率、可恢复性、可预测性； 性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率； 可支持性（Supportability）：适应性、可维护性、国际化、可配置性。 非功能性需