面向对象设计-第三节：系统分解和设计问题域子系统
Posted 快乐江湖
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了面向对象设计-第三节：系统分解和设计问题域子系统相关的知识，希望对你有一定的参考价值。
文章目录
一：系统分解
（1）分解思想
在设计比较复杂的应用系统时，先把系统分解成若干个较小部分，然后分别设计每个部分。这样做有利于降低设计的难度，有利于分工协作，也有利于维护人员对系统理解和维护
（2）子系统
A：定义
系统的主要组成部分称为子系统，通常根据所提供的功能来划分子系统
B：划分原则
- 根据所提供的功能来划分子系统，子系统数目应该与系统规模基本匹配
- 各个子系统之间应该具有尽可能简单、明确的接口
- 应该尽量减少子系统彼此间的依赖性
（3）分解面向对象设计模型
A：表示
典型的面向对象设计模型如下图所示
- 面向对象设计模型由主题、类与对象、结构、属性、服务5个层次组成。这5个层次一层比一层表示的细节更多，可以把这5个层次想象为整个模型的水平切片
- 面向对象设计模型在逻辑上都由4大部分组成，分别对应于组成目标系统的4个子系统,即问题域子系统、人机交互子系统、任务管理子系统和数据管理子系统
B：子系统间交互方式
①：客户-供应商关系（Client-supplier）
作为“客户”的子系统调用作为“供应商”的子系统，后者完成某些服务工作并返回结果。作为客户的子系统必须了解作为供应商的子系统的接口，后者却无须了解前者的接口
②：平等伙伴关系
每个子系统都可能调用其他子系统，每个子系统都必须了解其他子系统的接口。由于各个子系统需要相互了解对方的接口，子系统之间的交互复杂，且还可能存在通信环路
C：组织系统的方案
①：层次组织
软件系统组织成一个层次系统，每层是一个子系统。上层在下层的基础上建立，下层为实现上层功能而提供必要的服务。每一层内所包含的对象，彼此间相互独立，而处于不同层次上的对象，彼此间有关联。在上、下层之间存在客户-供应商关系。低层子系统提供服务，上层子系统使用下层提供的服务
- 封闭式：每层子系统仅仅使用其直接下层提供的服务。降低了各层次之间的相互依赖性，更容易理解和修改
- 开放式：子系统可以使用处于其下面的任何一层子系统所提供的服务。优点是减少了需要在每层重新定义的服务数目，使系统更高效更紧凑。但其不符合信息隐藏原则
②：块状组织
把软件系统垂直地分解成若千个相对独立的、弱耦合的子系统，一个子系统相当于一块,每块提供一种类型的服务
③：层次和块状的结合
当混合使用层次结构和块状结构时，同一层次可以由若干块组成，而同一块也可以分为若干层
④：设计系统的拓扑结构
典型的拓扑结构有管道形、树形、星形等。应采用与问题结构相适应的、尽可能简单的拓扑结构，以减少子系统之间的交互数量
二：设计问题域子系统
（1）概念
- 面向对象分析所得出的问题域精确模型，为设计问题域子系统建立了完整的框架
- 保持面向对象分析所建立的问题域结构
- 面向对象设计仅需从实现角度对问题域模型做一-些补充或修改
- 问题域子系统过分复杂庞大时，应该把它进一步分解成若干个更小的子系统
（2）对问题域模型进行的处理
A：调整需求
①：需要进行调整的情况
- 用户需求或外部环境发生了变化
- 分析员对问题域理解不透彻或不能完整、准确地反映用户的真实需求
②：方法
简单地修改面向对象分析结果，然后再把这些修改反映到问题域子系统中
B：重用已有的类
步骤为：
- 在已有类中找出与问题域内某个最相似的类作为被重用的类
- 从被重用的类派生出问题域类
- 简化对问题域类的定义(从被重用的类继承的属性和服务无须再定义)
- 修改与问题域类相关的关联，必要时改为与被重用的类相关的关联
C：把问题域类组合在一起
- 增添一个根类而把若干个问题域类组合在一起
- 引入根类或基类的办法，可以为一些具体类建立一个公共的协议
D：增添一般化类以建立协议
在设计过程中常常发现，一些具体类需要有一个公共的协议，可以引入附加类以便建立这个协议
E：调整继承层次
如果面向对象分析模型中包含了多重继承关系，然而所使用的程序设计语言却并不提供多重继承机制，则必须修改面向对象分析的结果。具体如下:
- 多重继承机制：避免出现服务及属性的命名冲突
- 单继承机制：使用多重继承机制时，必须把面向对象分析模型中的多重继承结构转换成单继承结构
以上是关于面向对象设计-第三节：系统分解和设计问题域子系统的主要内容，如果未能解决你的问题，请参考以下文章