1 OO\OOA\OOD

OO方法（Object-Oriented Method）：面向对象方法，是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法。
OOA方法（Object-Oriented Analysis）： 在一个系统的开发过程中进行了系统业务调查以后，按照面向对象的思想来分析问题。
OOD方法（Object-Oriented Design）：一种解决软件问题的设计范式（paradigm），一种抽象的范式。

2 软件体系结构分析的方法

2.1 模式

从特定的问题解决方案中提取出共同点即为模式。每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。

2.2 软件模式

描述公共软件问题的成功的解决方案，反映了解决方案的公共抽象结构，在特定的上下文中，能够在分析、设计等应用构建过程中多次使用。

2.3 体系结构模式/风格

体系结构模式是具体的软件体系结构的模板，描述系统级的结构特性，并影响到子系统的结构。对体系结构模式的选择是开发软件系统时最根本的设计决策。

2.4 设计模式：Design Pattern

设计模式给出了进一步细化一个软件系统的子系统或者组件的方案，一般为中层或中低层模式，常与特定的编程语言与方法无关。许多设计模式提供了分解复杂系统与组件的结构，也有的描述了它们之间的协作关系。

3 软件体系结构风格的概念

3.1 定义

  • 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
  • 体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。

  • 体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。一种软件体系结构风格是对某个具体环境下问题的结构性解决方法。

    3.2 使用软件结构风格带来的好处

  • 促进设计重用

  • 带来巨大的代码重用
  • 采用例行的结构，将使系统组成更易于被他人理解
  • 使用标准化的风格有益于系统的互操作性
  • 采用了某种体系结构风格的设计，通常允许专门的、此风格特有的体系结构分析

4 经典软件体系结构风格

  • 数据流风格（Data Flow）：批处理序列；管道/过滤器。
  • 调用/返回风格（Call/Return）：主程序/子程序；面向对象风格；层次结构。
  • 独立构件风格（Independent Components）：进程通讯；事件系统。

  • 仓库风格（Data-centered）：数据库系统；超文本系统；黑板系统。

    4.1 管道和过滤器

  • 每个构件都有一组输入和输出。构件称作过滤器（filters）；构件间的连接可以看作输入、输出数据流之间的通路，所以称作管道（pipes）。

  • 处理单元：进行数据流到数据流之间的转换：输入是数据流，输出也是数据流。

    4.1.1 优点

  • 允许设计师将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成。

  • 使得构件具有良好的隐蔽性和高内聚、低耦合的特点。

  • 支持软件重用。

    4.1.2 缺点

  • 容易导致批处理风格的系统设计。

  • 不适合交互式的应用。

  • 数据不同管道上传输没有统一标准，每个过滤器都要做类似的数据打包和解包工作，增加了复杂性。

    4.2 面向对象系统

    4.2.1 优点

  • 利用封装、继承、聚合，提高生产力

  • 因为对象对其它对象隐藏了它的数据表示，所以可以改变一个对象的数据表示，而不影响其它的对象；

    4.2.2 缺点

  • 必须知道对象的标识才能调用，且一经改动，所有调用的地方都需要随之改动。

  • 必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。

    4.3 事件系统

  • 构件不直接调用一个过程，而是触发或广播一个或多个事件，系统中其它构件中的过程在一个或者多个事件中注册。

  • 当一个事件被触发，系统自动调用这个事件中注册的所有过程，这样，一个事件的触发就导致了另一个模块中过程的调用。

    4.3.1 优点

  • 构件之间松耦合

事件发布者不必知道哪些构件会被事件影响，事件的接收者也可以不关心事件是由谁发出的

  • 有助于软件复用

允许任何构件注册其相关事件

  • 演化、升级简单

可以在不影响其余构件的情况下替换某个构件，因而系统的演化、升级变得简单

4.3.2 缺点

  • 构件对系统进行的计算放弃了主动控制

一个构件不能假设其它构件将会对它的请求作出响应，也不能得知事件处理的先后顺序。

  • 数据交换问题

有时，数据可能被一个事件传递，但在另一些情况下，基于事件的系统必须依靠一个共享的仓库中进行交互。这样全局性能和资源管理器成为十分关键的因素。

  • 正确性推理存在问题

过程的语义必须依赖于被触发事件的上下文约束。

4.4 分层系统

  • 分层风格将任务分解为多个子项目组，其中某个子任务组处于某个特定的抽象层次上
  • 每一层只能与相邻层交互：为上层提供服务和调用下层提供的服务

  • 适当时候(必不得已的时候)，可以允许一定的越层操作

    4.4.1 优点

  • 支持抽象程度递增的系统设计

设计者可以把一个复杂系统按照递增的步骤进行分解

  • 支持功能扩充和修改

因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层。

  • 支持灵活的实现和重用

只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。

4.4.2 缺点

  • 并不是每个系统都可以很容易地划分为层次结构

甚至即使一个系统的逻辑结构是层次化的，设计者出于对于系统性能的考虑，往往把一些低级和高级的功能综合起来。

  • 效率的降低

由分层风格构成的系统，运行效率往往低于整体结构。在上层中的服务如果有很多依赖于最底层，则相关的数据必须通过中间层的若干次转化，才能传到。

  • 难于认可合适的、正确的层次抽象方法：
  1. 层次太少，分层不能完全发挥这种风格的可重用性、可更改性、可移植性上的潜力。
  2. 层次过多，则引入不必要的复杂性和层间隔离冗余以及层间传输的开销
  3. 目前，没有可行的广为人们认可的层次粒度的确定和层任务的分配方法。

    4.5 C2风格

  • 系统中的构件和连接件都有一个顶部和一个底部；
  • 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
  • 一个连接件可以和任意数目的其它构件和连接件连接；

  • 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

    4.5.1 优缺点

  • 构件是相互独立的，构件之间依赖性很少。

  • 基于消息的通信。构件之间所有的通信只能通过消息进行。
  • 多线程。这是异步处理的特性。
  • 系统中的构件可实现应用需求，并能将任意复杂的功能封装在一起。