OO方法简介

课程资源：https://www.icourse163.org/learn/PKU-1003177002

面向对象的分析（OOA）

OOA概述

1. OOA的基本任务

   • 运用面向对象方法，
   • 对问题域（被开发系统的应用领域）和系统责任（所开发系统应用具备的职能）进行分析和理解，
   • 对其中的事物和它们之间的关系产生正确的认识，
   • 找出描述问题域和系统责任所需的类和对象
   • 定义这些类和对象的属性和操作，以及它们之间所形成的各种关系
   • 最终目的是产生一个符合用户需求，并能够直接反映问题域和系统责任的OOA模型及其规约。

2. OOA模型

   1. 需求模型：用况图 – OOA的基础
   2. 基本模型：类图
      1. 对象层 – 给出所有与问题域和系统责任有关的对象，用类表示
      2. 特征层 – 定义每个类的属性和操作
      3. 关系层 – 描述对象之间的关系
   3. 辅助模型 – 帮助理解类图
      1. 包图
      2. 顺序图
      3. 状态图等
   4. 模型规约 – 对模型中的所有元素进行详细说明和解释

   

3. OOA过程

   1. 定义use case（需求模型）：用use case对用户需求进行规范化描述
   2. 建立类图（基本模型）
      • 发现对象、定义对象类
      • 识别对象的内部特征（定义属性和操作）
      • 识别对象的外部特征（建立对象之间的关系）
   3. 划分包，建立包图（辅助模型，可选）
   4. 建立交互图（辅助模型，可选）
      • 对照use case，描述一组对象进行协作时的交互情况和消息的时序关系
   5. 建立模型规约
      • 对模型中的成分进行规范的定义和文字说明
      • 可以集中进行，也可以分散在各个活动中
   • 原型开发：结合其他活动反复进行

   

识别类

1. 研究问题域和用户需求

   1. 研究问题域和用户责任
      1. 阅读：阅读一切与用户需求有关的书面材料
      2. 交流：与用户交流，澄清疑点，纠正用户不切实的要求或不确切的表达
      3. 调查：到现场调查（只限于澄清需求）
      4. 记录、整理：产生一份符合工程规范、确切表达系统责任的需求文档
   2. 研究问题域
      • 亲临现场调查，掌握第一手资料
      • 听取问题域专家的见解
      • 阅读问题域有关的材料
      • 借鉴相同或类似问题域已有的系统开发经验及文档
   3. 确定系统边界
      • 划出被开发的系统和该系统打交道的人或物之间的明确界限，并确定它们之间的接口。
      • 在系统边界之内，是系统本身所包含的对象。在系统边界之外，是系统外部的活动者。
      • 主要是人、设备和外系统三种外部活动者。

2. 策略与启发

   1. 考虑问题域
      • 可以启发【分析员】发现对象的因素包括：人员、组织、物品、设备、抽象事物、事件、文件及结构。
      1. 人员
         1. 需要由系统保存和管理其信息的人员，如：户籍管理系统中的每个居民
         2. 应该在系统中完成某些功能，提供服务的人员，如户籍管理员
         • 符合上述情况之一者，应考虑用相应的人员对象来描述。
      2. 组织
         • 在系统中发挥一定作用的组织结构。如工作班组等。
      3. 物品
         • 需要由系统管理的各种物品。如经营的商品等。
      4. 设备
         • 在系统中动态地运行、由系统进行监控或供系统使用的各种设备、仪表、机器及运输工具等。
      5. 抽象事物
         • 指没有具体的物理形态，却对用户的业务具有实际意义的逻辑上的事物。
      6. 事件
         • 指那些需要由系统长期记忆的事件。
      7. 文件
         • 泛指在人类日常的管理和业务活动中使用的各种各样的表格、档案、证件和票据等文件。
      8. 结构
         • 通过考虑结构可以得到一种启发 —— 从已经发现的对象联想到其他更多的对象
   2. 考虑系统边界
      • 考虑系统边界，可以启发【分析员】发现一些与系统边界以外的参与者进行交互，并且处理系统对外接口的对象
      1. 人员
         • 作为系统以外的参与者与系统进行直接交互的各类人员，如系统的操作员、直接使用系统的用户等。
      2. 设备
         • 设备:作为系统以外的参与者与系统相连并交换信息的设备。
      3. 外系统
         • 外系统:与系统相连并交换信息的其他系统。
   3. 考虑系统责任
      • 检查每一项功能需求是否有相应的对象提供，发现新的对象。

3. 审查与筛选

   1. 舍弃无用对象
      1. 通过属性判断
         • 是否通过属性记录了一些对参与者或系统的其他对象有用的信息？
         • 即：这个对象所对应的事物，是否有些信息需要在系统中进行保存和处理
      2. 通过操作判断
         • 是否通过操作提供了某些有用的功能？
         • 即：这个对象所对应的事物，是否有某些行为需要在系统中模拟，并在系统中发挥一份作用。
      • 若二者都不是，则无用
   2. 对象的精简
      • 对只有一个属性的对象精简
        
      • 对只有一个操作的对象精简
        
   3. 与实现条件有关的对象
      • 如与图形用户（GUI）界面系统、数据管理系统、硬件及操作系统有关的对象 – 推迟到OOD考虑

4. 识别主动对象

   1. 考虑问题域和系统责任哪些对象需呈现主动行为？
   2. 从需求考虑系统的执行情况是否需要并发执行？控制线程的起点在哪个对象？
   • 上面的两点在分析阶段不能完全确定
   3. 考虑系统边界以外的参与者与系统哪些对象直接进行交互？
      • 如果一个交互是由系统以外的参与者发起的，则第一个处理该交互的对象是主动对象。

5. 对象分类，建立类图中的类

   1. 对象分类
      • 使用问题域和系统责任知识，对每组具有相同属性和操作的对象定义一个类。
   2. 异常情况的检查和调整
      1. 类的属性或操作不适合全部对象实例
         • 例：“汽车”类的“乘客限量”属性
         • 问题：分类不够详细 – 需要进一步划分特殊类
      2. 属性及操作相同的类
         • 经过抽象，差别很大的事物可能只保留相同的特征
         • 例：“吸尘器”和“电子琴”作为商品销售 – 考虑能否合并成一个类
      3. 属性及操作相似的类
         • 考虑能否提升出一个一般类或部分类
         • 如：轿车和货车，提取增加一般类“汽车”；机床和抽风机，提取部分类“电动机”
      4. 同一事务的重复描述
         • 如：职员和工作证 – 取消其中一个

识别属性和操作

识别属性

1. 策略与启发

   • 按常识这个对象应该有哪些属性?
     • 例如人的姓名、职业、地址等
   • 在当前的问题域中，对象应该有哪些属性?
     • 例如商品的条形码
   • 根据系统责任，这个对象应具有哪些属性?
     • 持卡人的使用地点
   • 建立这个对象是为了保存和管理哪些信息?
   • 对象为了实现操作的功能，需要增设哪些属性?
     • 例如传感器对象，为了实现其定时采集信号的功能，需要一个“时间”间隔属性，为了实现其报警功能，需要一个“临界值"属性。
   • 对象是否需要通过专设的属性描述其状态？
     • 例如设备对象，在关闭、待命、运行、故障等不同状态将呈现不同的行为,需要为其设置一个“状态”属性
   • 用什么属性表示聚合和关联?
     • 对于关联，应该在关联一端的类中定义一个属性，来指出另一端的哪个对象与本端的对象发生关联，其数据类型是指向另一端对象的指针或对象标识

2. 审查与筛选

   • 是否体现了以系统责任为目标的抽象?
     • 例:书的重量
   • 是否描述对象本身的特征？
     • 例:课程一电话号码
   • 是否破坏了对象特征的“原子性”
   • 是否可通过继承得到?
   • 可以从其它属性直接导出的属性

3. 与实现条件有关的问题都推迟到OOD考虑

   • 规范化问题(OOA中定义的对象属性可以是任何数据类型,数据类型的规范化工作在OOD中考虑)
   • 对象标识问题
   • 性能问题(如为了提高操作的执行速度,增加一些属性）

4. 属性的命名:原则与类的命名相同:

   1. 使用名词或带定语的名词;
   2. 使用规范的、问题域通用的词汇;
   3. 避免使用无意义的字符和数字。
   • 语言文字的选择要和类的命名要一致。
   • 定位原则：一个类的属性必须适合这个类和它的全部特殊类的所有对象，并在此前提下充分运用继承。

5. 属性的详细说明

   • 要在类规约中对属性进行详细说明，其中包括：属性的解释、数据类型和具体限制等。
   1. 属性的文字解释：例如“课程”对象的“学时”属性，其解释为“课堂讲授学时数，每学时为50分钟”
   2. 属性的数据类型：常用的数据类型;表示“整体-部分”结构或关联的属性类型可以是类或某一类对象的指

识别操作

1. 区分对象行为的类型

   • 为了明确OOA应该定义对象的哪些操作，首先区分对象行为的不同类型。
   1. 系统行为
      • 例：创建、删除、复制、转存
   2. 对象自身的行为 – 算法简单的操作
      • 例：读、写属性值
   3. 对象自身的行为 – 算法复杂的操作计算或监控
   • 仅用于操纵类属性的操作叫作类范围的操作，其余操作叫作实例范围的操作

2. 发现操作的策略与启发

   1. 考虑系统责任
      • 要逐项审查用户需求中提出的每一项功能要求，看它应由哪些对象来提供，从而在该对象中设立相应的操作。
   2. 考虑问题域
      • 对象在问题域对应的事物有哪些行为?
   3. 分析对象状态
      • 对象状态的转换，是由哪些操作引起的?
   4. 追踪操作的执行路线
      • 模拟操作的执行，并在整个系统中跟踪

3. 审查与调整

   • 审查是否是高内聚的
   • 调整
     1. 拆分：一个操作独立为多个对象的操作
     2. 合并：多个对象的操作合并为一个操作

4. 认识对象的主动行为

   1. 考虑问题域
      • 对象行为是被动引发的，还是主动呈现的？
   2. 与系统边界以外的活动者直接进行交互的对象操作
   3. 根据系统责任观察系统功能的构成层次，考虑完成最外层功能的对象操作。
   4. 操作执行路线逆向追踪，考察每个操作是被其它哪些对象的哪些操作请求的,直到发现某个操作不被其它成分所请求，则它应该是一个主动对象的主动操作。

   • OOA标注的主动对象和主动操作不一定是最终的定局，因为在OOD阶段可能增加一些新的主动对象，还可能为提高或降低系统的并发度而人为的增加或减少主动对象。

   • 什么是主动行为？

5. 操作的命名和定位

   1. 动词或动宾结构
   2. 定位：与实际事物一致
   3. 通用的操作放在一般类，特殊的操作放在特殊类

6. 操作的详细说明

   1. 操作的文字解释
   2. 操作名、输入输出参数、参数类型
   3. 消息发送
   4. 约束条件：操作执行的前置、后置条件以及执行时间的要求等事项说明。
   5. 操作流程

识别对象之间的关系

识别继承（泛化）

1. 识别继承（泛化）关系的策略
   1. 学习当前问题域的分类学知识
   2. 按常识考虑事物的分类
   3. 使用继承的定义
      1. 把每个类看作是一个对象集合，分析这些集合之间的包含关系
      2. 看一个类是不是另一个类的全部特征
   4. 考察属性与操作的使用范围
   5. 考虑领域范围内的复用
2. 审查与调整
3. 继承关系的简化
4. 调整对象层的特征层

识别关联

1. 识别关联的策略

   1. 认识对象之间的静态联系
   2. 认识对象的属性与操作
   3. 分析并表示关联的多重性
   4. 进一步分析关联的性质

2. 命名与定位命名

3. 调整对象层和特征层

识别聚合

1. 识别聚合的策略
   1. 物理上的整体事物和它的组成部分
   2. 组织机构和它的下级组织及部门
   3. 团体与成员
   4. 一种事物在空间上包容其他事物
   5. 抽象事物的整体与部分
   6. 具体事物和它的某个抽象方面
   7. 材料上的组成关系
2. 审查与筛选
3. 调整对象层和属性层

识别依赖

1. 在大多数情况里，使用依赖来描述一个类使用另一个的操作
2. 如果被使用的类发生变化，那么另一个类的操作也会受到影响

OOA案例

超级市场销售管理系统

面向对象的设计（OOD）

OOD概述

1. OOD的发展历史

   1. 早期OOD的特点
      1. 不是基于OOA的
         • 大多基于结构化分析结果（数据流图）
      2. 是OO编程方法的延伸
         • 多数方法与编程语言有关，特别受Ada影响很大
      3. 不是纯OO的
         • 对某些OO概念（如继承）缺少支持，掺杂一些非OO概念（如数据流、包、模块）
      4. 不是只针对软件生命周期的设计阶段
         • 早期OOD涉及少量分析问题（识别问题域的对象），但很不彻底
   2. 现今的OOD
      1. 背景：
         • 从结构化分析文档识别OOD的对象并非良策，识别对象的关键问题在于使用OO方法进行系统分析
         • OO方法从设计发展到分析，出现OOA方法
         • OOA和OOD构成完整的OO方法
         • OOD基于OOA，识别对象由OOA完成，OOD主要定义对象如何实现
      2. 特点
         1. 以面向对象的分析为基础，一般不依赖结构化分析
         2. 与相应的OOA方法共同构成一种OOA&D方法体系。OOA和OOD采用一致的概念与原则，但属于软件生命周期的不同阶段，有不同的目标及策略
         3. 较全面地体现面向对象方法的概念与原则
         4. 大多数方法独立于编程语言，通过面向对象的分析与设计所得到的系统模型可以由不同的编程语言实现
      3. 定义：OOD就是在OOA模型基础上运用面向对象方法进行系统设计，目标是产生一个符合具体实现条件的OOD模型。

2. OOD的根本任务

   1. 提高软件生产率
   2. 提高质量：好用、易用、可移植、易维护
   3. 加强可维护性：需求在不断变化

3. OOA与OOD的关系

   • 关于OOA与OOD的分工有两种不同的观点
   1. 第一种观点
      1. OOA：分析做什么
      2. OOD：设计怎么做
   2. 第二种观点
      1. OOA：分析问题域与系统责任
      2. OOD：设计与实现有关的因素
   • 从OOA到OOD不是转化，不是细化；是调整和增补
     1. 将OOA模型搬到OOD；进行必要的调整，OOA模型作为OOD模型的【问题域部分】
     2. 增补其他三个部分（人机交互部分、控制驱动部分、数据管理部分）

4. OOD方法中的概念和表示法

   • 基本按照Coad/Yourdon方法讲授
   • 概念：运用与OOA部分相同的概念 – 没有增加新概念
     • 对象、类、属性、操作、封装、继承、消息、关联、聚合、多态、主动对象等
   • 表示法：采用与OOA一直的表示法
   • OOD按照现实条件对OOA模型进行调整，并补充几个新的组成部分（也是由对象构成）
   • 基本思想：
     1. 尽可能隔离实现条件对系统的影响 – 提供独立的接口
     2. 对不可隔离的因素，按现实条件调整OOA模型
   • 与现实有关的因素：
     1. 图形用户界面系统
     2. 硬件、操作系统及网络
     3. 数据管理系统
     4. 其他 – 编程语言、可复用构件库
   • 从两个侧面描述OOD模型
     1. OOD模型包括几个主要部分 – 一个核心部分加几个外围部分
        1. 问题域部分（核心）
        2. 人机交互部分
        3. 控制驱动部分
        4. 数据管理部分
     2. OOD每个部分如何用OO概念表达 – 采用OOA概念及模型组织方式
        1. 需求模型：用况图
        2. 基本模型：类图
        3. 辅助模型
        4. 详细说明

5. OOD过程

   • 逐个设计OOD模型的四个部分
   1. 问题域部分的设计
   2. 人交互部分的设计
   3. 控制驱动部分的设计
   4. 数据接口部分的设计
   • 不强调次序、每个部分均采用与OOA一致的概念、表示法及活动，但具有自己独特的策略。

问题域部分的设计

1. 什么是问题域部分？

   • 问题域部分是OOD模型的四个组成部分之一，是由问题域有关的对象构成，并且在特定的实现条件下提供用户所需功能的组成部分。
   • 它是在OOA模型基础上按实现条件进行必要的修改、调整和细节补充而得到的。
   • 不是传统方法的“转换”，不存在鸿沟。主要不是细化，但OOA未完成的细节定义要在OOD完成。
   • 并非所有的实现因素都能通过一些在OOD中新定义的独立组成部分而实行有效的隔离。有些实现因素将不可避免地影响到OOA阶段识别的对象，影响到它们的内部特征和相互关系，因而要求在OOD阶段按照这些条件对它们做必要的修改、调整和细节上的补充。

2. 为什么需要问题域部分的设计？

   • 在OOA阶段只考虑问题域和系统责任，OOD则要考虑与具体实现有关的问题，需要对OOA结果的补充与调整。
   • 使反映问题域本质的总体框架和组织结构长期稳定，而细节可变。
   • 稳定部分（PDC）与可变部分（其他部分）分开，使系统从容地适应变化
   • 有利于同一个分析用于不同的设计与实现
   • 支持系统族和相似系统的分析设计及编程结果复用
   • 使一个成功的系统具有超出其生存期的可扩展性

3. 实现条件对问题域部分的影响
   现在分析和讨论各种实现条件将对OOD模型产生什么影响:

   1. 编程语言∶
      • 用于实现的编程语言对问题域部分的影响最大，其中包括两方面问题:
      1. 选定的编程语言可能不支持某些面向对象的概念与原则。此时要根据编程语言的实际表达能力对模型进行调整，以保证设计模型与源程序一致。
      2. OOA阶段可能将某些与编程语言有关的对象细节推迟到oOD阶段来定义。如对象的创建、删除、复制、转存、初始化等系统行为、属性的数据类型等。
      • 编程语言确定之后，这些问题都要给出完整的解决。
   2. 硬件、操作系统及网络设施
      • 选用的计算机、操作系统及网络设施对OOD的影响包括:对象在不同的站点上的分布、主动对象的设计、通信控制以及性能改进措施等。这些问题对问题域部分和控制驱动部分都将有影响。
   3. 复用支持
      • 如果存在已经进行设计和编码的可复用类构件，用以代替oOA模型中新定义的类无疑将提高设计与编码效率。但这需要对模型做适当的调整与修改。
   4. 数据管理系统
      • 选用的数据管理系统主要影响OOD模型的数据管理部分的设计，但也需要对问题域部分的某些类补充访问该数据管理部分所要求的属性与操作。
   5. 界面支持系统
      • 指支持用户界面开发的软件系统。主要影响人机交互部分的设计，对问题域部分影响很少，只是两部分之间需要互传消息而已。

4. 如何进行问题域部分的设计?

   1. 继续运用OOA的方法 – 概念、表示法及策略
   2. 使用OOA结果，并加以修改 – 需求的变化，新发现的错误
   3. 使用OOA结果，并进行补充与调整（本节的重点)
      1. 为复用设计与编程的类而增加结构
      2. 增加一般类以建立共同协议
      3. 按编程语言调整继承
      4. 提高性能
      5. 为实现对象永久存储所做的修改
      6. 为编程方便增加底层细节

人交互部分的设计

1. 什么是人机交互部分？
2. 为什么需要人机交互部分？
3. 人机交互部分的需求分析
4. 人机界面的设计准则
5. 人机界面的OO设计

控制驱动部分的设计

1. 什么是控制驱动部分？
2. 为什么需要控制驱动部分？
3. 如何设计控制驱动部分？
   1. 以节点为单位识别控制流
   2. 从用户需求触发识别控制流
   3. 从use case认识控制流
   4. 参照OO模型中的主动对象
   5. 为改善性能而增设控制流
   6. 实现并行计算的控制流
   7. 实现节点间通信的控制流
   8. 对其他控制流进行协调的控制流

数据接口部分的设计

1. 什么是数据管理部分？
2. 为什么需要数据管理部分？
3. 如何设计数据管理部分？
   文件系统、R-DBMS、OO-DBMS