【软件工程】第七章 面向对象分析

7.1 面向对象分析概述

7.1.1 OOA的基本任务

基本任务：

1. 对问题域（被开发系统的应用领域）和系统责任（所开发系统的职能）进行分析理解。
2. 正确认识其中事物的关系，找出并定义类和对象的属性和操作以及之间的关系。
3. 产生一个符合用户需求的OOA模型和规约（辅助说明）。

7.1.2 OOA模型

7.1.3 OOA过程

7.2 识别类

7.2.1 研究问题域和用户需求

研究用户需求：

1. 阅读：阅读一切与用户需求有关的书面材料
2. 交流：与用户交流，澄清疑点，纠正用户不切实的要求或不确切的表达
3. 调查：现场调查（只限于澄清需求）
4. 记录、整理：产生一份符合工程规范、确切表达系统责任的需求文档

研究问题域：

1. 亲临现场调查，掌握第一手资料
2. 听取问题域专家的见解
3. 阅读与问题域有关的材料
4. 借鉴相同或类似问题域已有的系统开发经验及文档

确定系统边界：

• 划出被开发的系统和该系统打交道的人或物之间的明确界限

7.2.2 策略与启发

考虑问题域中可以抽象为类的元素：

• 人员：需要由系统保存和管理其信息的人员（如学生信息）、提供某些服务的人员（如管理员）。
• 组织：在系统中发挥一定作用的组织结构（如工作班组）。
• 物品：需要由系统管理员管理的各种物品（如经营的商品）。
• 设备：在系统中动态地运行、由系统进行监控或供系统使用的各种设备、仪表、及其及运输工具。
• 抽象事物：没有具体的物理形态，却对用户的业务具有实际意义的逻辑上的事物。
• 事件：指需要系统长期记忆的事件。
• 文件：文件
• 结构：从已发现的对象联想到其他更多的对象

考虑系统边界：

• 人员：与系统交互的人员
• 设备：与系统进行交互的设备
• 外系统：与系统进行交互的其他系统

考虑系统责任：

• 检查每一项功能需求是否有响应的对象提供，发现新的对象。

7.2.3 审查与筛选

舍弃无用的对象：

1. 通过属性判断：是否通过属性记录了一些对参与者或对系统其它对象有用的信息？
2. 通过操作判断：是否通过操作提供了有用的功能？

对象的精简：
例1，一个班级只对应一个班主任且只有一个姓名，可以进行合并

例2，输出设备对应固定的格式转换，可以进行合并

推迟到OOD考虑的对象：

• 如GUI系统、数据管理系统、硬件、操作系统等

7.2.4 识别主动对象

哪些可以被认定为主动类：

1. 考虑问题域和系统责任：呈现主动行为的类。
2. 考虑是否需要并发：控制线程的起点的类。
3. 考虑系统边界外的参与者与系统中的哪些对象直接交互：第一个处理系统外参与者交互的类。

7.2.5 对象分类，建立类图中的类

对象分类：

• 使用问题域和系统责任知识，为每组具有相同属性和操作的对象定义一个类。

异常情况的检查和调整：

• 类的属性或操作不适合全部对象实例，应当进一步划分特殊类（如“汽车”类的“乘客限量”属性）。
• 属性及操作相同的类考虑能否合并为一个类（如“吸尘器”和“电子琴”作为商品销售）。
• 属性及操作相似的类考虑能否提升出一个一般类或部分类（如“轿车”和“货车”的一般类“汽车”，“机床”和“抽风机”的部分类“电动机”）。
• 同一事物的重复描述，取消其中一个（如“职员”和“工作证”）。

7.3 识别属性和操作

7.3.1 策略与启发

1. 按常识这个对象应该有哪些属性？（如人姓名、职业、地址等）
2. 在当前的问题域中，对象应该有哪些属性？（如商品条形码）
3. 根据系统责任，对象应具有的属性？（如持卡人的使用地点）
4. 建立这个对象是为了保存和管理哪些信息？
5. 对象为了实现操作的功能，需要增设哪些属性？（如传感器用以定时采集信号的的“时间”，用以报警的“临界值”）
6. 对象是否需要通过专设的属性描述其状态？（如设备对象的关闭、待命、运行、故障）
7. 用什么属性表示聚合和关联？（如关联一端的属性指向另一端的属性）

7.3.2 审查与筛选

1. 是否体现了以系统责任为目标的抽象？（例如在图书管理系统中，书的重量这一属性）
2. 是否描述对象本身的特征？（例如在课程管理系统中，在课程类中的教师的电话号码这一属性）
3. 是否破坏了对象特征的“原子性”。
4. 是否可通过继承得到？
5. 是否可以从其他属性直接导出？

7.3.3 推迟到OOD考虑的问题

1. 数据类型的规范化问题
2. 对象标识问题
3. 性能问题

7.3.4 识别操作

对象行为的不同类型：

1. 系统行为：创建、删除、复制、转存
2. 对象自身的行为：算法简单的操作，如读、写属性值等
3. 对象自身的行为：算法复杂的操作计算或监控

策略与启发：

1. 逐项审查需求中的每一项要求，找出提供的对象并设立操作
2. 考虑对象在问题域中对应的事物的有哪些行为
3. 考虑引起对象状态转换的操作
4. 模拟操作的执行，追踪操作的执行路线

7.4 识别对象间的关系

7.4.1 识别继承（泛化）

识别继承（泛化）关系的策略：

1. 学习当前领域的分类学知识：问题域现行的分类方法往往比较正确地反映事物的特征。
2. 按常识考虑事物的分类：按照自己的常识从不同角度考虑事物的分类，形成初步设想，而后发现确实需要的关系。
3. 使用继承的定义：①寻找类之间的集合关系（如“轿车”是“汽车”的子集）②看一个类是否具有另一个类的全部特征
4. 考察属性与操作的适用范围，抽取类中共同的属性与操作
5. 考虑领域范围内的复用

审查去调整：

1. 问题域是否需要这样的分类？
2. 系统责任是否需要这样的分类？
3. 是否符合分类学的常识？
4. 是否构成了继承关系？

继承关系的简化：

1. 从一般类划分出太多的特殊类，使系统中类的设置太多，增加了系统的复杂性。
2. 建立过深的继承层次，增加了系统的理解难度和处理开销。
3. 增加属性以简化继承关系（某些特殊类之间的差别可以由一般类的某个属性值来体现）。
4. 取消用户单一的一般类，减少继承层次，一般类要求有两个或两个以上的特殊类。
5. 调整对象层和特征层，随着继承的逐步建立需要对类图的对象层和特征层进行增删改查合并分离。

7.4.2 识别关联

识别关联的策略：

1. 认识对象间的静态联系：考虑问题域和系统责任，哪些类的对象实例之间的关系需要在系统中表达。
2. 认识关联的属性与操作：分析关联是否应该带有某些属性和操作。
3. 划分关联的多重性：从连接线的每一端看本端的一个对象与另一端的几个对象发生连接，将结果标注在连接线的另一端。
4. 进一步分析关联的性质：使用关联角色和限定符。

7.4.3 识别聚合

识别聚合的策略：

1. 物理上的整体事物和他的组成部分
2. 组织结构和他的下级组织及部门
3. 团体（组织）与成员
4. 一种事物在空间上包含其他事物。
5. 抽象事物的整体与部分。
6. 具体事物和他的某个抽象方面。
7. 材料上的组成关系。

7.4.4 识别依赖

• 依赖是一种使用关系，用于描述一个事物使用另一个事物的信息和服务（如类Windows使用类Event）。
• 如果被使用的类发生变化，那么另一个类的操作也会受到影响。

（完）