第七章使用用例建模系统需求课件.pptVIP

第七章 使用用例建模系统需求 Standish Group报告的项目成功率 7.1 用例建模概述 以用户为中心的开发是一个系统开发过程，该过程基于对关联人员的需求，以及对开发该系统原因的充分理解之上。 用例建模是使用用例的方法来描述系统的功能需求的过程 7.2 用例建模的系统概念 用例图是描述系统与外部其他系统以及用户之间交互的图形。换句话说，用例图描述了谁将使用系统，用户希望以什么方式与系统交互。 用例描述是业务时间以及用户如何同系统交互以完成任务的文字描述。 7.2.1 用例 用例是一个行为上相关的步骤序列，既可以是自动的也可以是手工的，其目的是完成一个单一的业务任务。 7.2.2 参与者 参与者代表了需要同系统交互以交换信息的任何事物。 参与者代表了同系统交互的用户所扮演的角色，而不代表一个人或者工作职位。 四类主要的参与者： 主要业务参与者 主要系统参与者 外部服务参与者 外部接收参与者 7.2.3 关系 7.2.3.1 关联关系 关联关系是一个参与者与一个用例发生交互的关系。 7.2.3.2 扩展关系 扩展用例是一个由从某个更复杂的用例中提取出来的步骤构成的用例，以便简化原始用例并扩展其功能。 7.2.3.3 使用（或包含）关系 抽象用例通过组合几个用例中公共的步骤来降低用例之间的冗余。 7.2.3.4 依赖关系 依赖是用例之间的一种关系，表示一个用例需要等到另一个用例执行之后才能执行。 7.2.3.5 继承关系 继承是参与者之间的一种关系，创建继承关系的目的是当一个抽象参与者继承多个实际参与者的角色时简化绘图。 7.3 需求用例建模过程 7.3.1 第1步：确定业务参与者 7.3.2 第2步：确定业务需求用例 7.3.3 第3步：构造用例模型图 7.3.4 第4步：记录业务需求用例描述 7.3.1 第1步：确定业务参与者 谁或者什么为系统提供输入 谁或者什么接收系统的输出 需要与其他系统连接的接口吗 是否存在在预定的时间自动触发的事件 谁将维护系统中的信息 7.3.2 第2步：确定业务需求用例 业务需求用例是在需求分析过程中为了捕捉用户与系统之间交互而建立的用例，并没有技术和实现细节，也称为基本用例。 寻找用例时，询问以下问题： 参与者的主要任务是什么 参与者需要系统什么信息 参与者为系统提供什么信息 系统需要通知参与者发生的变化和事件吗 参与者需要通知系统发生的变化和事件吗 7.3.2 第2步：确定业务需求用例 上下文图是分析参与者和发现潜在用例的极好来源。 触发组织内的业务事件的主要输入被认为是用例，提供这些输入的外部各方被认为是参与者。 用例使用输入的名称前加一个行动动词命名。 7.3.3 第3步：构造用例模型图 用例模型图描述系统范围和边界。 用例被组合成业务子系统。子系统表示业务过程的逻辑功能区。 7.3.4 第4步：记录业务需求用例描述 用例描述：作者、日期、版本、用例名称、用例类型、用例ID、优先权、来源、主要业务参与者、其他参与者、有利益的关联人员、描述 记录用例的事件过程 用例的典型事件过程是从参与者发起用例直到业务事件结束的步骤描述。 用例描述包括： 前置条件 触发器 典型事件过程 替代过程 结论 后置条件 业务规则 实现约束和说明 假设 开放问题 7.4 用例和项目管理 7.4.1 分级和评估用例 用例分级和评估矩阵使用6个标准按1~5级评估用例。 对架构设计的重要影响 容易实现但包含重要功能 包含有风险、时间紧迫或者复杂的功能 需要大量的研究或者新的、有风险的技术 包含主要的业务功能 将增加或者减少费用 7.4.2 确定用例依赖关系 用例依赖关系图具有以下优点： 系统事件及其状态的图形化表述有利于对系统功能的理解 有助于确定遗漏的用例 通过描述哪个用例更关键并需要最高优先权，有助于推动项目管理 * * 7.1 用例建模概述