第6章 面向对象分析.pptVIP

第6章 面向对象分析 面向对象分析概述 建立用例模型 建立对象模型 建立动态模型 6.1 面向对象分析概述 确定系统边界 6.1 面向对象分析概述 确定系统边界 6.1 面向对象分析概述 面向对象分析的3个模型 用例模型：用例和场景表示的功能模型； 对象模型：用类和对象表示的静态模型； 交互模型：由状态图和顺序图表示的动态模型。 6.2 建立用例模型 建立用例模型的过程 (1) 确定业务参与者──标识目标系统将支持的不同类型的用户，可以是人、事件或其他系统。 (2) 确定业务需求用例──参与者需要系统提供的完整功能。 (3) 创建用例图──标识参与者与用例之间、用例与用例之间的关系。 例:选课系统。给教师分配课程和学生注册课程。 在每个学期选课开始之前，系统管理员需要对系统中的教师信息、课程信息和学生信息进行维护。学期结束后，将本学期成绩归档到学籍档案系统。 学生登录系统后会得到一份本学期将要开设的课程目录。每门课程包含的信息有开课系别、教师、上课时间、教室、容纳的学生数量和学生选择课程的先决条件。 当学生选择了一门课程后，系统需访问学籍档案系统，查询是否符合选课的先决条件 。如果不符合，系统给出提示信息。 每个学期有一段时间让学生可以改变计划，学生可以在这段时间内访问联机系统以增选课程或退选课程。 教师可以访问在线系统，查看将要教授哪些课程和每门课程有哪些学生报名，课程考试结束后可以提交成绩，系统可以生成带有成绩分布统计结果的成绩单。 1. 确定业务参与者 通过关注系统的业务参与者，我们可以将重点放在如何使用系统，而不是如何构造系统上，并且有助于进一步明确系统的范围和边界。 当系统比较庞大和复杂时，要搞清楚系统的需求往往比较困难，通过明确参与者，可以针对参与者确定系统需求，有助于保证系统需求的完整性。 1. 确定业务参与者 可通过以下三个方面来识别参与者： 人员或组织 外部系统 设备 1. 确定业务参与者 可通过以下资料来确定系统的参与者： 标识系统范围和边界的环境图； 现有系统（如果有的话）的文档和用户手册； 项目会议和研讨会的记录； 现有的需求文档、工作手册等。 1. 确定业务参与者 还可以通过提出以下问题，明确系统的参与者： 谁或者什么为系统提供输入？ 谁或者什么接收系统的输出？ 需要与其他系统连接的接口吗？ 是否存在在预定的时间自动触发的事件？ 谁将维护系统中的信息？ 1. 确定业务参与者 从选课系统的需求描述中，可以确定4类参与者： 学生（Student） 教师（Teacher） 系统管理员（Administrator） 学籍档案系统（Archive System） 选课系统的环境图 2. 确定业务需求用例（参与者角度） 以下问题可以帮助我们更好地标识系统的用例： 每个参与者的特定任务是什么？ 在交互过程中参与者是怎样使用系统的服务来完成它们的任务以达目标的？ 是否每个参与者都要从系统中创建、存储、改变、移动或读取信息？ 是否任何参与者需要通知系统有关突发性的、外部的改变？ 哪些用例支持或维护系统？ 哪些事件引起了参与者与系统的交互？ 2. 确定业务需求用例（系统功能角度） 我们可以通过其中用例中的线索来发现其他用例，可以通过下面的方法获取： 以穷举的方式考虑每一个参与者与系统的交互情况，看看每个参与者要求系统提供什么功能，以及参与者的每一项输入信息将要求系统做出什么反应，进行处理。 看看目前的用例是否覆盖了所有的功能需求。 一个用例描述个功能，但这个功能不能过大，如果过大则需要对其进行分解。 一个用例应该完成一个完整的任务，通常应该在一个相对短的时间内完成。如果一个用例的各部分被分配在不同的时间段，尤其是被不同的参与者执行，最好还是讲各部分抽取出来作为单独的用例对待，这样有利于功能的复用。 2. 确定业务需求用例（参与者角度） 利用场景获取用例： 如果用例的描述遇到困难，可使用“角色扮演”技术。该技术要求建模人员深入到现场去观察业务人员的工作，深入理解并记录具体的工作流程，形成用来说明完成特定功能的动作序列的场景（scenario）。场景应该仅关注具体的业务活动，要尽量详细。要确定谁是扮演者，具体做了什么事情，做这些事情的目的是什么。在描述场景时，还要指出其前驱和后继场景，并要考虑可能发生的错误以及对错误的处理措施。要考虑可能发生的错误以及对错误的处理措施。通过需求工程师的角色扮演活动，找出各具体 的场景；然后将本质上相同的场景抽象为一个用例，如图6-3所示。 2. 确定业务需求用例 环境图是分析参与者和发现潜在用例的极好来源，它不仅可以用在结构化分析方法中，也可以用于面向对象的分析方法中。 通过环境图，可以确定系统的主要输入输出，通过提交和接收输入输出的各方确定潜在的用例。 选课系统