一、软件架构
软件架构（Software Architecture, SA）并非可运行软件，确切地说，它是一种表达，使软件工程师能够：
1. 分析设计在满足所规定的需求方面的有效性；
2. 在设计变更相对容易的阶段，考虑体系结构可能的选择方案；
3. 降低与软件构造相关联的风险。
软件架构设计的生命周期包括：
1. 需求分析阶段。
2. 设计阶段。
3. 实现阶段。
4. 构件组装阶段。
5. 部署阶段。
6. 后开发阶段。
二、基于架构的软件开发方法
基于体系结构的软件设计（Architecture-Base Software Design, ABSD）方法是由构成体系结构的商业、质量和功能需求的组合驱动的。ABSD方法有三个基础：
1. 功能的分解。
使用已有的基于模块的内聚和耦合技术。
2. 通过选择体系结构风格来实现质量和商业需求。
3. 软件模板的使用。
1 基于体系结构的开发模型
传统的软件开发过程可以划分为：
1. 问题定义。
2. 需求分析。
3. 软件设计。
4. 软件实现。
5. 软件测试。
ABSD模型把整个基于体系结构的软件过程划分为以下六个子过程：
1. 需求。
2. 设计。
3. 文档化。
4. 复审。
5. 实现。
6. 演化。
1.1 体系结构需求
体系结构需求过程主要是获取用户需求，标识系统中所要用到的构件。
如果以前有类似的系统体系结构的需求，我们可以从需求库中取出，加以利用和修改，以节省需求获取的时间，减少重复劳动，提高开发效率。
1. 需求获取。
一般来自系统的质量目标、系统的商业目标、系统开发人员的商业目标。
2. 标识构件。
又可分为三步：生成类图、对类进行分组、把类打包成构件。
3. 架构需求评审。
所获取的需求是否真实地反映了用户的要求，类的分组是否合理，构件合并是否合理等。
1.2 体系结构设计
1. 提出软件体系结构模型。
在建立体系结构的初期，选择一个合适的体系结构风格是首要的。
2. 把已标识的构件映射到软件体系结构中。
产生一个中间结构。
3. 分析构件之间的相互作用。
4. 产生软件体系结构。
对中间结构进行精化。
5. 设计评审。
1.3 体系结构文档化
体系结构文档化过程的主要输出结果是两个文档：
1. 体系结构规格说明。
2. 测试体系结构需求的质量设计说明书。
1.4 体系结构复审
体系结构能否满足要求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等。
1.5 体系结构实现
所谓“实现”就是要用实体来显示出一个软件体系结构，即要符合体系结构所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。
体系结构的实现过程分为以下阶段：
1. 复审后的文档化的体系结构。
2. 分析与设计。
3. 构件实现。
4. 构件组装。
5. 系统测试。
1.6 体系结构的演化
体系结构演化是使用系统演化步骤去修改应用，以满足新的需求。主要包括以下六个步骤：
1. 需求变化归类。
2. 制订体系结构演化计划。
3. 修改、增加或删除构件。
4. 更新构件的相互作用。
5. 构件组装与测试。
6. 技术评审。
三、软件架构风格
1 数据流体系结构风格
1.1 批处理体系结构风格
在批处理风格的软件体系结构中，每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，并且数据必须是完整的，以整体的方式传递。
1. 基本构件：独立的应用程序。
2. 连接件：某种类型的媒介。
1.2 管道-过滤器体系结构风格
当数据源源不断地产生，系统就需要对这些数据进行若干处理（分析、计算、转换等）。现有的解决方案是把系统分解成几个序贯的处理步骤，这些处理步骤之间通过数据流连接，一个步骤的输出是另一个步骤的输入。每个处理步骤由一个过滤器（Filter）实现，处理步骤之间的数据传输由管道（Pipe）负责。
1. 基本构件：过滤器。
每个处理步骤都有一组输入和输出。过滤器从管道中读取输入的数据流，经过内部处理，然后产生输出数据流并写入管道中。
2. 连接件：数据流传输管道。
将一个过滤器的输出传到另一过滤器的输入。
2 调用/返回体系结构风格
利用调用-返回实际上是一种分而治之的策略，其主要思想是将一个复杂的大系统分解为若干子系统，以便降低复杂度，并且增加可修改性。程序从其执行起点开始执行该构件的代码，程序执行结束，将控制返回给程序调用构件。
2.1 主程序/子程序风格
主程序/子程序风格一般采用单线程控制，把问题划分为若干处理步骤。
1. 构件：主程序和子程序。
子程序通常可合成为模块。
2. 连接件：过程调用。
调用关系具有层次性，其语义逻辑表现为子程序的正确性取决于它调用的子程序的正确性。
2.2 面向对象体系结构风格
目前软件界已普遍转向使用面向对象系统。这种风格建立数据抽象和面向对象基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。
1. 构件：对象，或者说是抽象数据类型的实例。
2. 连接件：对象之间的交互。
2.3 层次型体系结构风格
层次系统组成一个层次结构，每一层为上层提供服务，并作为下层的客户。
在一些层次系统中，除了一些精心挑选的输出函数外，内部的层接口只对相邻的层可见。
1. 构件：在层上实现了虚拟机。
2. 连接件：由通过决定层间如何交互的协议来定义。
拓扑约束包括对相邻层间交互的约束。
2.4 客户端/服务器体系结构风格
C/S（客户端/服务器）软件体系结构是基于资源不对等，且为实现共享而提出的。
两层C/S体系结构有三个主要组成部分：
1. 数据库服务器。
负责数据管理。
2. 客户应用程序。
完成与用户的交互任务。
3. 网络。
三层C/S结构是在两层C/S结构的基础上增加了一个应用服务器。整个应用逻辑驻留在应用服务器上，只有表示层存在于客户机上。应用功能分为：
1. 表示层。
应用的用户接口部分，通常使用图形用户界面。
2. 功能层。
应用的主体，实现具体的业务处理逻辑。
3. 数据层。
数据库管理系统。
3 以数据为中心的体系结构风格
3.1 仓库体系结构风格
仓库是存储和维护数据的中心场所。
1. 构件：中央数据结构以及一组对中央数据结构进行操作的独立构件。
2. 连接件：仓库与独立构件之间的交互。
3.2 黑板体系结构风格
黑板系统是一种问题求解模型，是组织推理步骤、控制状态数据和问题求解之领域知识的概念框架。
4 虚拟机体系结构风格
虚拟机体系结构风格的基本思想是人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样来增加架构的灵活性。
4.1 解释器体系结构风格
一个解释器通常包括完成解释工作的解释引擎，一个包含将被注释代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行进度的数据结构。
具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。
解释器通常被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异。其缺点是执行效率较低。
4.2 规则系统体系结构风格
基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。
5 独立构件体系结构风格
独立构件风格主要强调系统中的每个构件都是相对独立的个体，它们之间不直接通信，以降低耦合度，提升灵活性。
5.1 进程通信体系结构风格
1. 构件：通常是命名过程。
2. 连接件：消息传递。
可以是点到点、异步或同步方式及远程过程调用等。
5.2 事件系统体系结构风格
事件系统风格基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。
系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。
基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这使得不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。
四、软件架构复用
1 软件产品线、核心资产库、软件复用
软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。
核心资产库包括软件架构及可剪裁的元素，更广泛地，它还包括设计方案及其文档、用户手册、项目管理的历史记录、软件测试计划和测试用例。
软件复用是指系统化的软件开发过程：开发一组基本的软件构造模块，以覆盖不同的需求/体系结构之间的相似性，从而提高系统开发的效率、质量和性能。软件架构复用的分类包括：
1. 机会复用。
指开发过程中，只要发现有可用的资产，就对其进行复用。
2. 系统复用。
指在开发之前，就要进行规划，以决定哪些需要复用。
2 软件架构复用的对象
以下通通能复用（程序人的事情能叫抄吗？）：
1. 需求。
2. 架构设计。
3. 元素。
4. 建模与分析。
5. 测试。
6. 项目规划。
7. 过程、方法和工具。
8. 人员。
9. 样本系统。
10. 缺陷消除。
3 软件架构复用的基本过程
1. 构造/获取可复用的软件资产。
2. 管理可复用资产。文章来源：https://www.toymoban.com/news/detail-518185.html
3. 使用可复用资产。文章来源地址https://www.toymoban.com/news/detail-518185.html
到了这里，关于系统架构设计师 7：系统架构设计的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
