02需求分析与用例建模-新.ppt

02 需求分析与用例建模 9.3 面向对象的需求分析 9.3 面向对象的需求分析 9.3.3 业务需求建模 构造业务需求模型的目的：提取和分析足够的信息需求，准备一个模型，该模型表述了用户需要什么，而不涉及系统将如何构造和实现的特定细节。 业务需求分析首先要从分析和认识现行组织系统入手。 9.3 面向对象的需求分析 9.3 面向对象的需求分析 1.确定业务参与者： 业务参与者又称业务角色，是指在业务中扮演某种角色的事物，可以是人、部门或独立的软件系统。 由于Actor实际上是一个类, 因此它们之间可以存在一定的关系,如：执行者之间可以有继承关系。 9.3 面向对象的需求分析 ⒉ 确定业务需求用例 业务需求用例： 反映了用户与系统的交互过程，是实际业务的一部分，并没有技术细节和实现细节。 用例命名：动词+名词，如录入教职工信息。 在业务需求分析阶段，出于时间和经费的考虑，只粗略地确定和记录最关键、最复杂和最重要的用例，称为基本用例。 9.3 面向对象的需求分析 寻找业务需求用例的方法： 检查参与者以及他们如何使用系统。 可以通过下列问题来寻找业务用例： 参与者的主要任务是什么？ 参与者需要系统什么信息？ 参与者为系统提供什么信息？ 参与者是否需要系统的反馈信息？如果需要的话，需要什么样的反馈信息？ 9.3 面向对象的需求分析 9.3 面向对象的需求分析 9.3 面向对象的需求分析 ⒊ 创建用例模型 用例模型：描述系统范围和边界，参与者和用例之间的关系。 用例模型图中不支持双向箭头，只绘出触发用例的参与者，即发起参与者，而接受参与者通常略去。 9.3 面向对象的需求分析 9.3 面向对象的需求分析 ⒋ 描述业务需求用例 9.3 面向对象的需求分析 9.3.4 系统需求建模 系统需求建模：将业务需求转化成系统需求。 业务需求主要是从用户的角度去分析系统的业务流程； 系统需求则是从开发者的角度去分析业务流程，并得出新系统要实现的功能。 系统用例模型比业务用例模型更详细、更具说明性。 9.3 面向对象的需求分析 9.3.4.1 系统参与者与系统用例 ⒈ 系统参与者： 也称角色，是与所建系统交互的人或物。 它与业务需求建模中的参与者有所不同，前者是从业务层分析与系统相关的事物，这里的角色主要是和系统直接交互的参与者。 9.3 面向对象的需求分析 ⒉ 系统用例： 业务需求用例：面向业务，反映了系统期望行为的高层视图。其中没有技术细节，并可以包含手工活动和将被自动化的活动。 系统用例：为了反映用户界面约束之类的实现细节，从业务用例中导出应用性的用例，称为系统用例。 可以从一个业务用例中导出一个或多个系统用例。 开发人员使用这种用例说明详细的需求，辅助评价和规划，交流编程需求，形成用户文档的基础。 9.3 面向对象的需求分析 9.3.4.2 确定用例间的关系：包含、泛化和扩展 基本用例：通常称为业务用例或抽象用例，而在以后各阶段的用例，是为了满足系统的要求而演变来的。这些用例和基本用例之间存在如下关系： ⒈ 包含关系 基本用例的行为包含了另一个用例的行为（公共行为）。箭头从基本用例指向公共用例。 往往是一个用例功能过多需分解成小用例，构成包含依赖。 9.3 面向对象的需求分析 ⒉ 泛化关系 代表一般与特殊的关系（继承）。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。 9.3 面向对象的需求分析 ⒊ 扩展关系 基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。 4．使用关联 几种关系的比较 扩展关系：一个基本用例执行时, 可以执行或不执行扩展用例. 包含关系：执行基本用例时, 一定会执行包含用例. 用例要采用多种控制方式对异常或任选动作进行处理时，采用扩展关联。 两个以上用例重复处理同样的动作，可以采用使用关联或包含关联。 一个用例偶尔使用另一个用例的功能描述时，采用继承关联。 9.3 面向对象的需求分析 9.3.4.3 构造系统用例模型 业务需求用例模型转换成系统用例模型步骤： ⒈ 确定、定义并记录新的参与者。 ⒉ 确定、定义并记录新的用例。 ⒊ 确定任何复用的可能性。 ⒋ 细化用例模型图。 ⒌ 记录系统用例描述。 9.3 面向对象的需求分析 第1步：识别新的参与者 系统分析员与用户人员交谈继续了解系统功能需要什么。通过这些努力，有可能会发现需要被定义和记录的新的参与者。 9.3 面向对象的需求分析 第2步：识别新的用例 新的参与者产生了新的用例。 第3步：精简用例步骤 提取公共步骤形成独立的共享公共用例：包含用例、泛化用例、扩展用例。 9.3 面向对象的需求