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