有效的软件体系结构及其明确的描述和设计，已成为软件工程领域中重要的主题。
*注：由于历史原因，研究者和工程人员对**Software Architecture（简称SA）*的翻译不尽相同，本文中软件"体系结构"和"架构"具有相同的含义。
7.1 软件架构概念
7.1.1 软件架构的定义
一个程序和计算机系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件，构件的外部可见属性以及它们之间的相互关系。
体系结构并非可运行软件，确切地说，它是一种表达，使软件工程师能够：
- 分析设计在满足所规定的需求方面的有效性；
- 在设计变更相对容易的阶段，考虑体系结构的可能的选择方案；
- 降低与软件构件相关联的风险。
在体系结构设计的环境中，软件构件简单到可以是程序模块或者面向对象的类，也可以扩充到包含数据库和能够完成客户与服务器网络配置的"中间件"。
软件体系结构的设计通常考虑到设计金字塔的两个层次：
- 数据设计：体现传统系统中体系结构的数据构件和面向对象系统中类的定义（封装了属性和操作）；
- 体系结构设计：主要关注软件构件的结构、属性和交互作用。
7.1.2 软件架构设计与生命周期
1、需求分析阶段
采用Use Case图描述需求的方法，经过词法分析和一些经验规则完成从Use Case图向SA模型（包括类图等）转换，可追溯性则可通过表格或者Use Case Map等来维护。
2、设计阶段
- 对构件和连接子的建模；
- 使用体系结构描述语言对构件、连接子及其配置进行描述；
- 使用多个视图从不同的视角描述特定系统的体系结构，并将其组织起来描述整体的SA模型。
3、实现阶段
- 在SA模型中引入实现阶段的概念，如引入程序设计语言元素等；
- 通过模型转换技术，将高层的SA模型逐步精化成能够支持实现的模型；
- 封装底层的实现细节，使之成为较大粒度的构件。
4、构件组装阶段
将SA设计模型作为系统蓝图，对SA设计模型中规约的连接子的实现提供支持；检测并消除体系结构失配问题。
5、部署阶段
- 提供高层的体系结构视图来描述部署阶段的软硬件模型；
- 基于SA模型分析部署方案的质量属性，并选择合理的部署方案；
6、后开发阶段
后开发阶段是指软件部署安装之后的阶段，主要围绕维护、演化、复用等方面来进行。
- 动态软件体系架构：在设计阶段捕获体系结构的动态变化，并进一步直到软件系统在运行时刻实施这些变化，从而实现系统的在线演化或自适应甚至自主计算；
- 体系结构恢复与重建：从已实现的系统中获取体系结构的过程。
7.1.3 软件架构的重要性
软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。
- 架构设计能够满足系统的品质
- 架构设计使受益人达成一致的目标
- 架构设计能够支持计划编制过程
- 架构设计对系统开发的执行性
- 架构设计能够有效地管理复杂性
- 架构设计为复用奠定了基础
- 架构设计能够降低维护费用
- 架构设计能够支持冲突分析
7.2 基于架构的软件开发方法
7.2.1 体系结构的设计方法概述
基于体系结构的软件设计（Architecture-Based Software Design，ABSD）方法是由体系结构驱动的，即指由构成体系结构的商业、质量和功能需求的组合驱动的。设计活动可以从项目总体功能框架明确就快速开始软件设计（需求抽取和分析还没有完成）。
ABSD方法有三个基础：功能分解、选择体系结构风格、软件模板的使用。
ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。
7.2.2 概念和术语
1、设计元素
系统、概念子系统、软件模板、概念构件
2、视角与视图
选择不同的视角（如展示功能组织的静态视角，展示并发行为的动态视角）和视图（如逻辑视图、进程视图、实现视图和配置视图）全方位的考虑体系结构的设计。
3、用例和质量场景
- 用例是系统的一个给予用户一个结果值的功能点，用例用来捕获功能需求；
- 人们通过定义特定场景来捕获质量需求，这些场景称为质量场景。
7.2.3 基于体系结构的开发模型
ABSD模型将整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化6个子过程。
7.2.4 体系结构需求
需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。体系结构需求受技术环境和体系结构设计师的经验影响。需求过程主要师获取用户需求，标识系统中所用到的构件。
1、需求获取
- 系统的质量目标
- 系统的商业目标
- 系统开发人员的商业目标
2、标识构件
生成类图、对类进行分组、把类打包成构件。
3、架构需求评审
组织一个由不同代表（如分析人员、客户、设计人员和测试人员）组成的小组，对体系结构需求及相关构件进行仔细地审查：
- 需求是否真实地反映了用户的要求；
- 类的分组是否合理；
- 构件合并是否合理。
7.2.5 体系结构设计
体系结构需求用来激发和调整设计决策，不同的视图被用来表达与质量目标有关的信息。体系结构设计是一个迭代过程。
7.2.6 体系结构文档化
体系结构文档化过程主要输出两个文档：体系结构规格说明和测试体系结构需求的质量设计说明书。
7.2.7 体系结构复审
体系结构设计、文档化和复审和一个迭代过程。
复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误，包括：
- 体系结构能否满足需求
- 质量需求是否在设计中得到体现
- 层次是否清晰
- 构件的划分是否合理
- 文档表达是否明确
- 构件的设计是否满足功能与性能的要求
- ...
7.2.8 体系结构实现
所谓"实现"就是要用实体来显示出一个软件体系结构，即要符合体系结构所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。
7.2.9 体系结构的演化
体系结构演化是使用系统演化步骤去修改应用，以满足新的需求。
7.3 软件架构风格
软件体系结构设计的一个核心目标是重复的体系结构模式，即达到体系结构级的软件重用。
基于这个目标，主要任务是研究和实践软件体系架构风格和类型问题。
7.3.1 软件架构风格概述
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
体系结构风格反映了领域中众多系统所共有的结构和语义特定，并知道如何将各个模块和子系统有效地组织成一个完整的系统。
7.3.2 数据流体系结构风格
1、批处理体系结构风格
每个处理步骤是一个单独的程序；每一步必须在前一步结束前才能开始；数据必须是完成的，以整体的方式传递。
2、管道-过滤器体系结构风格
基本构件是过滤器，连接件是数据流传输管道，将一个过滤器的输出传到另一个过滤器的输入。
7.3.3 调用/返回体系结构风格
1、主程序/子程序风格
一般采用单线程控制，将问题划分为若干处理步骤，构件即为主程序和子程序，子程序通常可合成模块。过程调用作为交互机制，充当连接器。
调用关系具体层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。
2、面向对象体系结构风格
建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。
3、层次体系结构风格
层次系统组成一个层次结构，每一层为上层提供服务，并作为下层的客户。
4、客户端/服务器体系架构风格
- 两层C/S体系结构：数据库服务器、客户端应用程序和网络（胖客户机，瘦服务器）
- 三层C/S体系结构：增加了应用服务器（瘦客户机）
7.3.4 以数据为中心的体系结构风格
1、仓库体系结构风格
构件：存储和维护数据的中心数据仓库和一组对中央数据进行操作的独立构件；
连接件：仓库和独立构件之间的交互。
2、黑板体系结构风格
适用于解决复杂的非结构化的问题，能在求解过程中综合运用多种不同的知识源，使得问题表达、组织和求解变得比较容易。黑板系统的传统应用是信号处理领域，比如语音识别和模式识别；另一应用是松耦合代理数据共享存取。
7.3.5 虚拟机体系结构风格
1、解释器体系结构风格
2、规则系统体系结构风格
7.3.6 独立构件体系结构风格
1、进程通信体系机构风格
构件：独立的进程；
连接件：消息传递。
风格特点：构件通常是命名进程，消息传递可以是点到点、异步或同步方式及远程过程调用。
2、事件系统体系结构风格
构件不直接调用一个过程，二十触发或广播一个或多个事件。
7.4 软件架构复用
7.4.1 软件架构复用的定义和分类
软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，以规定的方式用公共的核心资产集成开发出来的。
软件复用是指系统化的软件开发过程：开发一组基本的软件构造模块，以覆盖不同的需求/体系结构之间的相似性，从而提高系统开发的效率、质量和性能。软件复用是一种系统化的软件开发过程，通过识别、开发、分类、获取和修改软件实体，以便在不同的软件开发过程中重复使用它们。
软件架构复用包括：
- 机会复用：指开发过程中只要发现有可复用的资产，就对其进行复用；
- 系统复用：指在开发之前，就要进行规划，以决定哪些需要复用。
7.4.2 软件架构复用的原因
- 减少开发工作、开发时间，降低开发成本，提高生产力；
- 提高产品质量，使其具有更好的互操作性；
- 使产品维护变得更加简单。
7.4.3 软件架构复用的对象及形式
软件产品线的本质是在生产产品家族时，以一种规范的、策略性的方法复用资产。可复用的资产包括：
- 需求
- 架构设计
- 元素
- 建模与分析
- 测试
- 项目规划
- 过程、方法和工具
- 人员
- 样本系统
- 缺陷消除
7.4.4 软件架构复用的基本过程
复用的基本过程主要包括3个阶段：
- 首先构造/获取可复用的软件资产；
- 其次管理这些资产；
- 最后针对特定的需求，选择、定制、组装这些资产。
7.5 特定领域软件体系结构
特定领域软件体系结构的主要目的是在一组相关的应用中共享软件体系结构。
7.5.1 DSSA的定义
DSSA（Domain Specific Software Architecture）就是在一个特定应用中为一组应用提供组织结构参考的标准软件体系结构。
DSSA的必备特征有：
- 一个严格定义的问题域和问题解域；
- 具有普遍性，使其可以用于领域中某个特定应用的开发；
- 对整个领域的构件组织模型的恰当抽象；
- 具备该领域固定的、典型的在开发过程中可重用元素。
一般的DSSA的定义并没有对领域的确定和划分给出明确的说明，从功能覆盖范围的角度有两种理解DSSA中领域的含义的方式： - 垂直域：定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可以作为系统的可行解决方案的一个通用软件体系结构；
- 水平域：定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统族的特定部分功能。
7.5.2 DSSA的基本活动
- 领域分析：获取领域模型
- 领域设计：获取DSSA
- 领域实现：依据领域模型和DSSA开发和组织可重用信息
注：以上过程是一个反复的、逐渐求精的过程。
7.5.3 参与DSSA的人员
- 领域专家
- 领域分析人员
- 领域设计人员
- 领域实现人员
7.5.4 DSSA的建立过程
- 定义领域范围
- 定义领域特定的元素
- 定义领域特定的设计和实现需求约束
- 定义领域模型和体系结构
- 产生、搜集可重用的产品单元
DSSA的建立过程是并发的、递归的和反复进行的，该过程的目的是将用户的需求映射为基于实现限制集合的软件需求，这些需求定义了DSSA。
