面向对象分析
(第三部分：面向对象分析与设计方法，第6章)
李欣
Created: 2022-05-10 Tue 23:57
0.1. 互动课堂
0.2. 本次课的目标
第三部分：面向对象分析与设计方法
第6章：面向对象分析
- 面向对象分析概述
- 建立用例模型
- 建立对象模型
- 建立动态模型
1. 面向对象分析概述
1.1. 确定系统边界
现实世界中的事物 与 系统的关系 包括以下几种情况：
- 某些事物位于系统边界以内，可以作为系统内的 类对象 。
- 某些事物将是与系统进行交互的 参与者 ，
对于这样的事物是否将其作为系统内的类对象，通常是需要认真考虑的。
- 如果系统需要存储参与者的信息，则需要将其作为系统内的类对象；
- 如果不需要存储，则可以不作为系统内的类对象。
- 某些事物属于问题域，但与系统责任没有关系。这样的事物与系统无关，不需要考虑。
Figure 1: 系统的参与者与系统边界
1.2. 面向对象分析的3种模型
面向对象分析模型由3种独立的模型构成：
- 由 用例 和 场景 表示的 功能模型（用例模型） ；
- 由 类 和 对象 表示的 静态模型（对象模型） ；
- 由 状态图 、 顺序图 等表示的 动态模型（交互模型） 。
2. 建立用例模型
建立用例模型的目的是提取和分析足够的需求信息。 用例模型应能表述用户需要什么，而不涉及系统如何构造和实现的特定细节。
创建用例模型的过程如下：
- 确定业务参与者 ：标识目标系统将支持的不同类型的用户，可以是人、事件或其他系统。
- 确定业务需求用例 ：参与者需要系统提供的完整功能。
- 创建用例图 ：标识参与者与用例之间、用例与用例之间的关系。
【例6.1】选课系统的主要功能是给教师分配课程和学生注册课程。其需求描述如下：
- 在每个学期选课开始之前，系统管理员需要对系统中的教师信息、课程信息和学生信息进行维护， 学期结束后，将本学期成绩归档到学籍档案系统。
- 学生登录选课系统后会得到一份包含本学期将要开设的课程的目录。 每门课程包含的信息有开课系列、教师、上课时间、教室、容纳的学生数量和学生选择课程的先决条件， 这些信息可以帮助学生选择课程。
- 当学生选择了一门课程后，选课系统需访问学籍档案系统， 查询是否符合选课的先决条件（如是否已通过先修课程的学习），如果不符合，系统给出提示信息。
- 每个学期有一段时间让学生可以改变计划，学生可以在这段时间内访问系统以增选课程或退选课程。 教师可以访问系统，查看将要教授哪些课程和每门课程有哪些学生报名，课程考试结束后可以提交成绩， 系统可以生成带有成绩分布统计结果的成绩单。
2.1. 确定业务参与者
2.1.1. 可以从以下3个方面来识别参与者
- 人员或组织
- 外部系统
- 如果在正在开发的系统中使用一个 已有系统 ，则这个已有系统被看成是一个外部系统；
- 如果一个大系统在任务分解时被划分成几个 子系统 ，则每个子系统的开发者都把其他子系统看成是外部系统。
- 设备
2.1.2. 可以通过下面的资料来确定系统的参与者
- 标识系统范围和边界的环境图；
- 现有系统（如果有的话）的文档和用户手册；
- 项目会议和研讨会的记录；
- 现有的需求文档、工作手册等。
2.1.3. 通过提出以下问题明确系统的参与者
- 谁或者什么为系统提供输入？
- 谁或者什么接收系统的输出？
- 需要与其他系统连接的接口吗？
- 是否有在预定的时间自动触发的事件？
- 谁将维护系统中的信息？
Figure 2: 选课系统的环境图
2.2. 确定业务需求用例
可以从以下几个方面来获取用例。
- 从 参与者 的角度获取用例
- 从 系统功能 的角度获取用例
- 利用 场景 获取用例
Figure 3: 将场景抽象为用例
2.3. 创建用例图
用例图（Use Case Diagram） 是若干个 参与者 和 用例 以及它们间的 关系 构成的图形表示。
Figure 4: 选课系统的总体用例图
用例建模往往不是一次就能完成的，需要多次迭代、逐步完善。
3. 建立对象模型
3.1. 对象模型的5个层次
建立对象模型的5项主要活动：
- 划分主题
- 确定类与对象
- 确定结构
- 确定属性
- 确定服务
Figure 5: 对象模型的5个层次
3.2. 划分主题
对于选课系统，可以划分以下主题：
- 基础信息维护
- 学生选课
- 成绩管理
3.3. 确定类与对象
系统分析员的主要任务就是根据需求规格说明和用例模型确定问题的类与对象。
- 首先找出所有候选的类与对象，
- 然后从候选的类与对象中筛选掉不正确的或不必要的。
3.3.1. 找出候选的类与对象
类与对象是对问题域中有意义的事物的抽象， 它们既可能是可见的物理实体，也可能是抽象的概念。
可以将客观事物分为以下5类：
- 可感知的物理实体，如教学楼、教室等。
- 人或组织的角色，如教师、计算机等。
- 应该记忆的事件，如演出、交通事故等。
- 两个或多个对象的相互作用，通常带有交易或接触的性质，如购买、教学等。
- 需要说明的概念，如保险法、政策等。
3.3.2. 筛选出正确的类与对象
筛选时主要依据下列标准来删除不正确或不必要的类或对象：
- 冗余 ：如果两个类表达了同样的信息，则应该保留在此问题域中最富于描述力的名称。
- 无关 ：仅需要把与本问题密切相关的类与对象纳入系统中。
- 笼统 ：在需求陈述中常常使用一些笼统的、泛指的名词， 如果有更明确具体的名词对应它们所暗示的事物，就要将这些笼统的类去掉。
- 属性 ：类应具有多个有意义的属性。仅有一个属性的类可表示为其他类的属性。
- 操作 ：在需求陈述中有时可能使用一些既可作为名词、又可作为动词的词， 应该慎重考虑它们在本问题中的含义，以便正确地决定把它们作为类还是作为类中定义的操作。
- 实现 ：在分析阶段不应该过早地考虑怎样实现目标系统，因此， 应该去掉仅和实现有关的候选的类与对象。
3.3.3. 区分实体类、边界类和控制类
在类分析时首先从问题域的实体类入手， 如果在建立对象模型时区分实体类、边界类和控制类，将有助于理解系统。
- 实体类 表示系统将跟踪的持久信息；
- 边界类 表示参与者与系统之间的交互；
- 控制类 负责用例的实现。
Figure 6: 分析对象模型中的对象
3.4. 确定结构
3.4.1. 确定泛化（继承）关系
- 学习 当前领域的分类学知识
- 按常识 考虑 事物的分类
- 考察 类的属性与操作
- 自上而下 地从一般类发现特殊类
- 自下而上 地从特殊类抽取出一般类
Figure 7: 自上而下地从一般类发现特殊类
Figure 8: 自下而上地从特殊类抽取出一般类
3.4.2. 确定关联关系
类之间最普遍存在的关系不是泛化（继承）关系，而是关联关系。 关联关系表示的是两个或多个类的实例之间的连接关系。
以下策略用于指导确定关联关系：
- 识别各类对象之间的静态联系
- 识别关联的属性与操作
- 分析关联的多重性
- 进一步分析关联的性质
3.5. 确定属性
以下策略用于指导确定属性：
- 每个对象至少需包含一个属性
- 属性取值必须适合对象的所有实例
- 出现在泛化关系中的对象所继承的属性必须与泛化关系一致
- 系统的所有存储数据必须定义为属性
- 对象的导出属性应当略去
- 在分析阶段，如果某属性描述了对象的外部不可见状态， 应将该属性从分析模型中删去
3.6. 确定服务
对象收到消息后所能执行的操作称为它可提供的服务。 在确定每个对象中必须封装的服务时要注意以下两种服务：
- 简单的服务
- 建立和初始化一个新对象
- 建立或切断对象之间的关联
- 存取对象的属性值
- 释放或删除一个对象
- 复杂的服务
- 计算服务 ：利用对象的属性值计算，以实现某种功能
- 监控服务 ：处理对外部系统的输入/输出、外部设备的控制和数据的存取
3.7. 建立类图
- 创建类
- 将类组织到包中
- 建立和编辑类的主视图和分视图
Figure 9: 具有5个包的主视图
Figure 10: 类的分视图
3.7.1. 关联关系
Figure 11: 增加类之间的关联关系
Figure 12: 增加关联数量
3.7.2. 聚合关系
Figure 13: 增加了聚合关系的类图
3.7.3. 与关联类建立关系
Figure 14: 增加了关联类的类图
3.7.4. 泛化关系（继承关系）
Figure 15: 增加了泛化关系的类图
4. 建立动态模型
4.1. 顺序图
Figure 16: Register for a course用例的顺序图
4.2. 通信图
Figure 17: 通信图
4.3. 状态图
Figure 18: CourseTask类对象的状态图
5. 课后作业
- （习题6.1） 比较面向对象的分析方法和面向数据流的分析方法，阐述它们各自的特点。
- （习题6.2） 面向对象分析需要建立的三个模型是什么？
- （习题6.4） 用例模型中的外部参与者指的是什么？如何确定外部参与者？
- （习题6.7） 解释关联类的作用。在什么时候需要使用关联类？