第8章面向对象分析.ppt

第8章 面向对象分析 面向对象分析概述 建立用例模型 建立对象模型 建立动态模型 建立数据模型 8.1 面向对象分析概述 面向对象分析的3个模型 用例模型：用例和场景表示的功能模型； 对象模型：用类和对象表示的静态模型； 交互模型：由状态图和顺序图表示的动态模型。 8.1 面向对象分析概述 对象模型的5个层次 Coad Yourdon提出，复杂问题(大型系统)的对象模型应该由下述5个层次组成：主题层(也称为范畴层)、类-对象层、结构层、属性层和服务层，如图所示。 8.2 建立用例模型 建立用例模型的过程 (1) 确定业务参与者──标识目标系统将支持的不同类型的用户，可以是人、事件或其他系统。 (2) 确定业务需求用例──参与者需要系统提供的完整功能。 (3) 创建用例图──标识参与者与用例之间、用例与用例之间的关系。 1. 确定业务参与者 通过关注系统的业务参与者，我们可以将重点放在如何使用系统，而不是如何构造系统上，并且有助于进一步明确系统的范围和边界。 当系统比较庞大和复杂时，要搞清楚系统的需求往往比较困难，通过明确参与者，可以针对参与者确定系统需求，有助于保证系统需求的完整性。 1. 确定业务参与者 可通过以下资料来确定系统的参与者： 标识系统范围和边界的环境图； 现有系统（如果有的话）的文档和用户手册； 项目会议和研讨会的记录； 现有的需求文档、工作手册等。 1. 确定业务参与者 还可以通过提出以下问题，明确系统的参与者： 谁或者什么为系统提供输入？ 谁或者什么接收系统的输出？ 需要与其他系统连接的接口吗？ 是否存在在预定的时间自动触发的事件？ 谁将维护系统中的信息？ 1. 确定业务参与者 从选课系统的需求描述中，可以确定4类参与者： 学生（Student） 教师（Teacher） 系统管理员（Administrator） 学籍档案系统（Archive System） 2. 确定业务需求用例 以下问题可以帮助我们更好地标识系统的用例： 每个参与者的特定任务是什么？ 是否每个参与者都要从系统中创建、存储、改变、移动或读取信息？ 是否任何参与者需要通知系统有关突发性的、外部的改变？ 哪些用例支持或维护系统？ 目前的用例是否覆盖了所有功能需求？ 2. 确定业务需求用例 环境图是分析参与者和发现潜在用例的极好来源，它不仅可以用在结构化分析方法中，也可以用于面向对象的分析方法中。 通过环境图，可以确定系统的主要输入输出，通过提交和接收输入输出的各方确定潜在的用例。 选课系统的环境图 选课系统的业务列表 对用例的完整描述包括用例名称、执行者、前置条件、后置条件、一个主事件流、零到多个备选事件流。 主事件流表示正常情况下执行者与系统之间的信息交互及动作序列，备选事件流则表示特殊情况或异常情况下的信息交互及动作序列。 应给出每个用例的规格说明。 用例“选择课程”的规格说明 3. 创建用例图 用例图是若干个参与者和用例，以及它们间的关系构成的图形表示。 每个系统通常都有一个总体视图（Global View of Actors and Use Cases），如果总体视图过于复杂，则可以创建多个用例图，每个用例图关注系统的某一方面。 通常是围绕参与者创建用例图。 使用Rose创建用例模型 1. 在Rose中创建参与者（actors） 创建的角色应放在Use-Case Model包中的Actors包中比较好，如果模型结构中没有这样的包，可以先创建Actors包，之后按下面的步骤创建角色： (1) 在浏览器窗口中的Actors包上单击鼠标右键，显示弹出菜单； (2) 选择New:Actor菜单选项，系统创建名为New Class的参与者； (3) 选中新创建的参与者，更名为设计的名字。 使用Rose创建用例模型 1. 在Rose中创建参与者（actors） 使用Rose创建用例模型 2. 给参与者添加文档 在Rose中我们对模型元素都可以（在多数情况下是必须的）添加文档以描述更多的信息。 应该给模型中的每个actor添加摘要描述，摘要描述表示actor和系统交互的规则。 课程注册系统中actor的摘要描述如下： Student——在学校注册上课的人； Teacher——学校授权上课的人； Administrator——系统认同的维护人员； Archive System——管理学生学籍档案的外部系统。 使用Rose创建用例模型 3. 在Rose中创建用例（Use Case） 应该将用例放在Use cases包中，如果您的模型结构中没有这样的包，则应该先创建包。 也可以将每个用例放在单独的包中，因此可以先创建相应的包，再创建用例。 另外，在多个用例中使用的公共用例，如验证用户（