面向对象分析和设计第六章.pptVIP

# 面向对象分析与设计 第六章 理解需求 对象是系统中用来描述客观事物的一个实体，它是构成系统的一个基本单位，有一组属性和对这组属性进行操作的服务。 类是具有相同属性和相同服务的一组对象的集合，它为属于该类的全部对象提供了统一的抽象描述，其中包括属性和服务两个主要部分。 6.1收集需求 需求阶段的目标又两个： 检查业务上下文： 首先需要弄清楚开发软件的原因——如果没有好的理由，就不应编写软件。在决定开发软件系统后，就需要理解业务，对业务的理解应与客户的理解相同。 描述系统需求：这不仅要决定系统的功能，还要找出所有的约束条件：性能、开发成本、资源等 6.1收集需求 研究问题域和用户需求 研究用户需求明确系统责任 系统的需求包括四个不同层次：业务需求、用户需求、功能需求和非功能性需求。 分析员开始一项分析工作首先要研究用户需求，要搞清楚到底要开发什么样的系统。包括：系统需要提供哪些功能，系统的边界在哪里，要达到何种性能指标以及可靠性、安全性要求。人机交互要求等 收集需求 研究问题域和用户需求包括以下活动： 阅读相关文档 与用户交流 进行实地调查 记录所得认识 整理相关资料 认真听取问题域专家的见解 借鉴他人经验 6.2确定系统边界 确定系统边界，就是明确系统是什么以及系统的环境是什么,划出被开发的系统和与该系统打交道的人或物之间的明确界限，并确定它们之间的接口。 认识系统边界的目的是为了明确系统的范围以及与外部世界的接口。 6.3用例描述 Ivar Jacobson发明了用例，以定义部分业务或系统的使用方式，它是描述系统功能需求的高效工具。 用例开始于一个参与者（actor），之后是业务或系统，最后返回到参与者。 用例不是业务建模的唯一方式，比较复杂的方法有业务过程建模和工作流分析，用例比较简单。 6.3用例描述 6.3用例描述 6.4根据需求寻找类 根据需求寻找类 商店 汽车 条形码 柜台终端 激光阅读器 助手 客户 会员（特殊客户） 预约 交付 收回 6.5 业务分析 1、标识业务参与者 参与者是在业务中扮演某个角色的人、部门、外部设备或独立的软件系统,标识参与者有助于标识业务的使用方式，这有助于表示用例的含义。 6.5 业务分析 2、编写项目术语表 本课程使用的术语 6.5 业务分析 3 标识业务用例 6.6用例模型 需求分析的第二步是给要开发的软件建模，以改进业务。 域模型 用例模型 业务过程模型 工作流分析 系统的用例模型比业务的用例模型更详细、更具说明性。 6.6用例模型 对于Ripple，系统用例模型包括 参与者列表（带有描述） 用例列表（带有描述） 用例图 用例细节表（包括所有相关的非功能需求） 用例调查 辅助需求 用例的优先级 改进的术语表 用户界面草图（可选，可放在具体的设计阶段考虑） 6.6用例模型 1、标识系统参与者 这个阶段标识的参与者应只包括直接与系统交互的人（和外部系统），而不包括更宽泛的业务环境中的参与者 6.6用例模型 A、参与者列表 6.6用例模型 2、标识系统用例 一旦有了参与者，就可以查找用例，每个用例都必须有简短说明。 思考 用例？？ 6.6用例模型 6.6用例模型 3、用例的关系 除了参与者之间的特殊化以及和用例之间的关系之外。用例之间还有三种关系： 特殊化（specialize） 包含 （include） 扩展 （extend） 这些关系可以组合相关的用例，分解大的用例，重用行为，指定可选行为。 6.6用例模型 特殊化：与参与者一样，用例也可以相互继承。为了避免重新定义步骤和添加额外的步骤，可以只特殊化抽象的用例。纯抽象用例根本没有步骤，其唯一的目的是组合其它用例。 包含：如果第一个用例有一些第二个用例提供的步骤，该用例就包含第二个用例。包含关系显示为箭头开放的虚线，从包含的用例指向被包含的用例，并标记include 扩展：第一个用例给第二个用例增加步骤，就称为扩展第二个用例，扩展关系可以增加可选的额外步骤.扩展关系显示为箭头开放的虚线，从扩展的用例指向被扩展用例，并标记extend 6.6用例模型 6.6用例模型 B、用例列表 6.6用例模型 C、用例图 6.6用例模型 4、系统用例的细节 6.6用例模型 D、用例的细节列表 6.6用例模型 5、前置条件与后置条件 前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件； 后置条件：用例一旦执行后系统所处的状态； 6.6用例模型 6、辅助需求 在大多数情况下，可以把非功能需求关联到特定的用例上。 不适合任何用例的非功能需求可以记录在辅助需求文档中。 6.6用例模型 7、用例的优先级 最好按照实现的优先级给系统需求分级，尤其在递增开发过程中，就更应分级。在用例建模过程中，显然应给用例分级，然后给每个用