软件体系结构的概念

软件体系结构的定义 重点

软件体系结构的一种比较常见的定义即部件、连接件和配置的集合。其中

• 部件是软件体系结构的基本组成单位之一，承载了系统的主要功能，包括处理与数据；

• 连接件是软件体系结构的另一个基本组成单位，定义了部件之间的交互，是连接件的抽象表示；

• 配置是对形式的发展，定义了部件和连接件之间的关联方式，将它们组织成系统的总体结构。

这一模型就是对软件体系结构的抽象，而在这一抽象的基础上，将它们转换为模块、构件和进程等传统单位，这就是软件体系结构的实现。

概念、逻辑、物理

软件设计是自顶向下的，一般都会经历概念化、逻辑化和物理化的过程。这印证了软件设计中抽象的核心思想，每一个过程都和下一个过程形成接口与实现的关系。在这种视角下，软件体系结构的设计就更偏向概念化和逻辑化的设计。

采取这种抽象化设计的好处在于直观且便于验证正确性，软件设计的复杂度也会降低。

部件

部件可以分为原始和复合两种类型。原始类型的部件可以直接被实现为相应的软件实现机制，而复合类型的部件则由更细粒度的部件和连接件组成。

一般的部件包含以下的部分

连接件

与部件相同，连接件也可以分为原始和复合两种类型。一般的连接件包含以下的部分

原始连接件常用的实现机制如下

其中，连接件的软件实现机制分为显示和隐式两种。一般而言，隐式的实现不需要开发者专门进行开发，是开箱即用的；而显示的实现需要开发者额外进行设计。

连接件是一个与部件平等的单位，部件与连接件是比类、模块等软件单位更高层次的抽象。

配置

配置用来将部件和连接件组织整合起来，构成系统的整体结构。为了对软件体系结构进行更严格准确的表述，还可以使用 $\mathrm{ADL}$ 语言。

软件体系结构风格初步

在软件体系结构设计中，有以下几类常见的风格。

• 数据流式
  • 管道和过滤器
• 调用-返回式
  • 主程序 / 子程序式
  • 面向对象式
  • 分层式（康威定律）
• 独立部件式
  • 事件系统式
  • $\mathrm{MVC}$ 模式
• 虚拟机式
  • 解释器式
• 数据中心式
  • 数据库式
  • 超文本式

下面四个是比较典型的风格。

主程序 / 子程序式

主程序/子程序风格将系统组织成层次结构，主程序是系统的控制器，负责调度各子程序的执行。各子程序又是一个局部的控制器，负责调度其子子程序的执行。

类别	实现
部件	步骤、函数和模块
连接件	调用、跳转等

实现特点

• 每一个上层部件可以“使用”下层部件，但下层部件不能“使用”上层部件，即不允许逆方向调用。

• 系统应该是单线程执行。主程序部件拥有最初的执行控制权，并在“使用”中将控制权转移给下层子程序。

• 子程序只能够通过上层转移来获得控制权，可以在执行中将控制权转交给下层的孙子程序，并在自身执行完成之后必须将控制权还交给上层部件。

效果 重点

优点

• 流程清晰，易于理解。
• 强控制性。程序的正确性通过层层嵌套得以保证。

缺点

• 耦合性强。会导致系统难以修改和复用。
• 产生隐式数据交流，破坏它的“正确性”控制能力。

面向对象式

借鉴面向对象的思想来组织整个系统的高层结构。它将系统组织为多个独立的对象，每个对象封装其内部的数据，并基于其数据对外来提供服务。不同的对象之间通过协作的机制来完成系统的任务。

类别	实现
部件	对象、模组
连接件	方法调用

实现特点

• 依照对数据的使用情况，用信息内聚的标准，为系统建立对象部件。每个对象部件基于内部数据提供对外服务接口，并隐藏内部数据的表示。

• 基于方法调用机制建立连接件，将对象部件连接起来。 每个对象负责维护其自身数据的一致性与完整性，并以此为基础对外提供正确的服务。

• 每个对象都是一个自治单位，不同对象之间是平级的，没有主次、从属、层次、 分解等关系。（与面向对象分析方法不同）

效果 重点

优点

• 内部实现可修改性强。可以在不影响外界的情况下，变更其内部实现。
• 易开发、易理解、易复用的结构组织。

缺点

• 接口存在耦合性。接口只是通过简单的方法调用来连接，无法消除耦合性。
• 标识存在耦合性。一个对象要与其他对象交互，必须知道那个对象的标识。
• 存在副作用。若多个对象共同使用某对象，则它们对该对象的更改可能是潜在的（无法通知所有对象）。

分层式

根据不同的抽象层次，将系统组织为层次式结构。

类别	实现
部件	每个层次，通常是一组对象
连接件	在层间交互协议下的方法调用

实现特点

• 从最底层到最高层，部件的抽象层次逐渐提升。每个下层为邻接上层提供服务， 每个上层将邻接下层作为基础设施使用。也就是说，在程序调用机制中上层调用下层。

• 两个层次之间的连接要遵守特定的交互协议，该交互协议应该是成熟、稳定和标准化的。也就是说，只要遵守交互协议，不同部件实例之间是可以互相替换的。

• 禁止跨层和逆向连接。

效果 重点

优点

• 设计机制清晰，易于理解。
• 支持并行开发。
• 更好的可复用性与内部可修改性。

缺点

• 交互协议难以修改。
• 性能损失。
• 难以确定层次数量和粒度。

$\mathrm{MVC}$ 模式

即模型-视图-控制 $(\mathrm{Model}-\mathrm{View}-\mathrm{Controll})$ 风格。它将部件分为模型、视图和控制三种，其中：模型封装了系统的数据和状态信息，实现了业务逻辑，对外提供数据服务和执行控制逻辑；视图封装了用户交互，提供用户界面，接收用户行为；控制封装了系统的控制逻辑，根据用户行为调用需要执行的数据服务和业务逻辑。它们的具体关系如下

类别	实现
部件	模型、视图和控制
连接件	程序、方法调用

实现特点 重点

• 如果视图需要持续地显示某个数据的状态，那么它首先需要在模型中注册对该数据的兴趣。如果该数据状态发生了变更，模型会主动通知视图，然后再由视图查询数据的更新情况。

• 视图只能使用模型的数据查询服务，只有控制部件可以调用可能修改模型状态的程序。

• 用户行为虽然由视图发起，但是必须转交给控制部件处理。对接收到的用户行为， 控制部件可能会执行两种处理中的一种或两种：调用模型的服务，执行业务逻辑；提供下一个业务展现。

• 模型部件相对独立，既不依赖于视图，也不依赖于控制。

效果 重点

优点

• 易开发性。视图和控制的可修改性。

• $\mathrm{MVC}$ 中模型是相对独立的，所以对视图实现和控制实现的修改不会影响到模型实现。再考虑到业务逻辑通常比业务表现和控制逻辑更加稳定，所以 $\mathrm{MVC}$ 具有一定的可修改性优势。

• 适宜于网络系统开发。$\mathrm{MVC}$ 不仅允许视图和控制的可修改性，而且其对业务逻辑、表现和控制的分离使得一个模型可以同时建立并保持多个视图，这非常适用于网络系统开发。

缺点

• 复杂性。$\mathrm{MVC}$ 将用户任务分解成了表现、控制和模型三个部分，这增加了系统的复杂性，不利于理解任务实现。

• 模型修改困难。视图和控制都要依赖于模型，因此，模型难以修改。（只是相对而言，这并不与前者矛盾）