面向对象分析与设计方法
面向对象分析
软件工程 第三部分 第6章，主讲人：李欣
Created: 2023-04-21 Fri 01:41
0.1. 互动课堂
0.2. 签到
0.3. 本次课的目标
- 第三部分：面向对象分析与设计方法
- 第6章：面向对象分析
- 面向对象分析概述
- 建立用例模型
- 建立对象模型
- 建立动态模型
- 第6章：面向对象分析
1. 面向对象分析概述
1.1. 确定系统边界
- 现实世界中的 事物 与 系统 的关系
- 某些事物位于系统边界以内，可以作为系统内的 类对象 。
- 某些事物将是与系统进行交互的 参与者 ，
对于这样的事物是否将其作为系统内的类对象，通常是需要认真考虑的。
- 如果系统 需要存储 参与者的信息，则需要将其作为系统内的类对象；
- 如果 不需要存储 ，则可以不作为系统内的类对象。
- 某些事物属于问题域，但与系统责任没有关系。这样的事物与系统无关，不需要考虑。
Figure 1: 系统的参与者与系统边界
1.2. 面向对象分析的3种模型
面向对象分析模型由3种独立的模型构成：
- 由 用例 和 场景 表示的 功能模型（用例模型） ；
- 由 类 和 对象 表示的 静态模型（对象模型） ；
- 由 状态图 、 顺序图 等表示的 动态模型（交互模型） 。
2. 建立用例模型
建立用例模型的目的是提取和分析足够的需求信息。 用例模型应能表述用户需要什么，而不涉及系统如何构造和实现的特定细节。
- 创建用例模型的过程
- 确定业务参与者 ：标识目标系统将支持的不同类型的用户，可以是人、事件或其他系统。
- 确定业务需求用例 ：参与者需要系统提供的完整功能。
- 创建用例图 ：标识参与者与用例之间、用例与用例之间的关系。
2.1. 确定业务参与者
- 识别参与者时应考虑的3个方面
- （直接使用系统的） 人员或组织
- 启动、维护和关闭系统；
- 从系统获取信息；
- 向系统提供信息。
- 外部系统
- 如果在正在开发的系统中使用一个 已有系统 ，则这个已有系统被看成是一个外部系统；
- 如果一个大系统在任务分解时被划分成几个 子系统 ，则每个子系统的开发者都把其他子系统看成是外部系统。
- （与系统交互的） 设备
- 与系统相连并向系统提供外界信息；
- 从系统获取信息；
- （直接使用系统的） 人员或组织
- 确定系统参与者时应依据的资料
- 标识系统范围和边界的 环境图 ；
- 现有系统（如果有的话）的 文档 和 用户手册 ；
- 项目会议和研讨会的 记录 ；
- 现有的 需求文档 、 工作手册 等。
- 明确系统参与者时应提出的问题
- 谁或者什么为系统提供 输入 ？
- 谁或者什么接收系统的 输出 ？
- 需要与其他系统连接的 接口 吗？
- 是否有在预定的时间自动触发的 事件 ？
- 谁将维护系统中的 信息 ？
- 选课系统的需求描述
- 选课系统的主要功能是给教师分配课程和学生注册课程。
- 在每个学期选课开始之前，系统管理员需要对系统中的教师信息、课程信息和学生信息进行维护， 学期结束后，将本学期成绩归档到学籍档案系统。
- 学生登录选课系统后会得到一份包含本学期将要开设的课程的目录。 每门课程包含的信息有开课系列、教师、上课时间、教室、容纳的学生数量和学生选择课程的先决条件， 这些信息可以帮助学生选择课程。
- 当学生选择了一门课程后，选课系统需访问学籍档案系统， 查询是否符合选课的先决条件（如是否已通过先修课程的学习），如果不符合，系统给出提示信息。
- 每个学期有一段时间让学生可以改变计划，学生可以在这段时间内访问系统以增选课程或退选课程。 教师可以访问系统，查看将要教授哪些课程和每门课程有哪些学生报名，课程考试结束后可以提交成绩， 系统可以生成带有成绩分布统计结果的成绩单。
- 选课系统的4类参与者
- 学生（Student）
- 教师（Teacher）
- 系统管理员（Administrator）
- 学籍档案系统（Archive System）
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 解释关联类的作用。在什么时候需要使用关联类？