软考系统架构设计师（6）-系统架构设计基础知识
软件架构概念
重点名词：Software Architecture，SA，软件架构或软件体系结构
体系结构设计包括数据库设计和软件结构设计，后者主要关注软件构件的结构、属性、交互作用，并通过多种视图全面描述
1.软件架构设计与生命周期
需求分析阶段
需求分析和架构设计面临两个不同的对象：一个是问题空间，一个是解空间。从软件需求模型向架构设计模型的转换主要关注两个问题：
- 如何根据需求模型构件架构设计模型
- 如何保证模型转换的可追踪性
设计阶段
主要研究：SA模型的描述、SA模型的设计与分析方法、SA设计经验的总结与复用
SA模型的描述主要研究：
- SA的基本概念：SA模型由哪些元素组成，这些元素之间按照哪种原则进行组织；构件之间的互连机制独立出来，与构件同等级别的实体称为连接子，现阶段SA描述方法是构件和连接子的建模
- 体系结构描述语言（ADL）：支持构件、连接子及其配置的描述语言就是体系结构描述语言
- SA模型的多视图表示：从不同的视角描述特定系统的体系结构，得到多个视图，将这些视图组织起来以描述整体的SA模型
典型的4+1模型（逻辑视图、进程视图、开发视图、物理视图、统一场景）
实现阶段
实现阶段的研究以下几个方面：
- 研究基于SA的开发过程支持
- 寻求从SA向实现过渡的途径
- 研究基于SA的测试技术
缩小软件架构设计与底层实现概念差距的手段：模型转换技术、封装底层的实现细节、在SA模型中引入实现阶段的概念
构件组装阶段
主要研究内容：
- 如何支持可复用构件的互联，即对SA设计模型中规约的连接子的实现提供支持
- 在组装过程中，如何检测并消除体系结构适配问题
构件组装阶段的适配问题
- 由构件引起的失配，包括由于系统对构件基础设施、构件控制模型、构件数据模型的假设存在冲突引起的失配
- 由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配
- 由于系统成分对全局体系结构的假设存在冲突引起的失配等
部署阶段
软件体系结构对软件部署的作用
- 提供高层的体系结构视图来描述部署阶段的软硬件模型
- 基于SA模型可以分析部署方案的质量属性，从而选择合理的部署方案
后开发阶段
主要围绕维护、演化、复用等方面进行，研究方向由动态软件体系结构、体系结构恢复与重建
-
动态软件体系结构
SA在运行发生变化包括：
- 软件内部执行所导致的体系结构变化
- 软件系统外部的请求对软件进行的重配置
对动态软件体系结构的研究
-
体系结构恢复与重建
现有的体系结构重建方法
- 手工体系结构重建
- 工具支持的手工重建
- 通过查询语言来自动建立聚集
- 使用其他技术
2.软件架构的重要性
- 架构设计能够满足系统的品质
- 架构设计使受益人达成一致的目标
- 架构设计能够支持计划编制过程
- 架构设计对系统开发的指导性
- 架构设计能够有效地管理复杂性
- 架构设计为复用奠定了基础
- 架构设计能够降低维护费用
- 架构设计能够支持冲突分析
基于架构的软件开发方法
基于体系结构的软件设计方法（Architecture-Based Software Design，ABSD）
1.体系结构的设计方法概述
ABSD方法是由体系结构驱动的，即指由构成体系结构的商业、质量和功能需求的组合驱动的
在ABSD中，采用视角与视图来描述软件架构，采用用例来描述功能需求，采用质量场景来描述质量需求
ABSD方法有3个基础：
- 功能的分解，在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术
- 通过选择体系结构风格来实现质量和商业需求
- 软件模板的使用，软件模板利用了一些软件系统的结构
2.基于体系结构的开发模型
ABSD模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化6个子过程
体系结构需求
主要过程
- 需求获取：体系结构需求一般来自3个方面，分别是系统质量目标、系统的商业目标、系统开发人员的商业目标
- 标识构件：该过程为系统生成初始逻辑结构，分3步实现
- 架构需求评审
体系结构设计
主要过程
- 提出软件体系结构模型：在建立体系结构的初期，选择一个合适的体系结构风格是首要的
- 把已标识的构件映射到软件体系结构中
- 分析构件之间的相互作用
- 产生软件体系结构
- 设计评审
体系结构文档化
体系结构文档化过程主要输出结果两个文档
《体系结构规格说明书》
《测试体系结构需求的质量设计说明书》
文档要从使用者的角度进行编写，必须分发给所有与系统有关的开发人员，且必须保证开发者手上的文档是最新的
体系结构复审
要安排一次由外部人员（用户代表和领域专家）参加的复审，复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误
体系结构实现
体系结构的试下过程是以复审后的文档化体系结构说明书为基础的，具体分为：
- 分析与设计
- 构件实现
- 构件组装
- 系统测试
体系结构演化
体系结构演化使用系统演化步骤去修改应用，以满足新的需求，步骤分为
- 需求变化归类
- 体系结构演化计划
- 构件变动
- 更新构件的相互作用
- 构件组装与测试
- 技术评审
- 演化后的体系结构
软件架构风格
软件体系结构风格：描述某一特定应用领域中系统组织方式的惯用模式
体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束，词汇表包含一些构件和连接件类型，约束支持系统是如何将这些构件和连接件组合起来的。
数据流体系结构风格
分批处理风格和管道过滤器
- 批处理风格：在批处理风格的软件体系结构中，每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，并且数据必须是完整的，以整体的方式传递。它的基本构件是独立的应用程序，连接件是某种类型的媒介。
- 管道-过滤器体系结构风格：把系统分为几个序贯地处理步骤，每个步骤之间通过数据流连接，一个步骤的输入是另一个步骤的输入，每个处理步骤都有输入和输出；基本构件是过滤器，连接件是数据流传输管道
调用/返回体系结构风格
调用/返回风格是指系统采用了调用与返回机制，利用调用-返回实际上是一种分而治之的策略；主要思想是将一个复杂的大系统分解成若干子系统，以降低复杂度，增加可修改性。
- 主程序/子程序风格：采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序，过程调用作为交互机制，作为连接件。
- 面向对象体系结构风格：这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和相应操作封装在一个抽象数据类型或对象中，构件是对象，连接件是过程调用
- 层次型体系结构风格：层次系统组成一个层次结构，每一层为上层提供服务，作为下层的客户，内部的层接口只对相邻的层可见。
- 客户端/服务器体系结构风格：两层C/S体系主要由3部分组成：数据库服务器、客户应用程序和网络。服务器（后台）负责数据管理，客户机（前台）完成与用户的交互任务，称为“胖客户端，瘦服务器”。三层C/S结构则增加一个应用服务器，整个应用逻辑驻留在应用服务器上，只有表示层存在客户机上，称为“瘦客户机”。三层C/S结构应用功能分
- 表示层：应用的用户接口部分，通常使用图形用户界面
- 功能层：应用的主题，实现具体的业务处理逻辑
- 数据层：数据库管理系统
以数据为中心的体系结构风格
- 仓库体系结构风格：仓库是存储和维护数据的中心仓所，有两种不同的构件：中央数据结构说明当前数据的状态以及一组对中央数据进行操作的独立构件，连接件为仓库与独立构件之间的交互
- 黑板体系结构风格：一种问题求解模型，是组织推理步骤、控制状态数据和问题求解之领域知识的概念框架，可通过选取各种黑板、知识源和控制模块的构件来设计，应用于信号处理领域，如语音识别和模式识别。
虚拟机体系结构风格
基本思想是人为构建一个运行环境，可以解析与运行自定义的一些语言，增加架构的灵活性
- 解释器体系结构风格：一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构以及一个记录源代码被解释执行进度的数据结构；通常用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异；缺点是执行效率低，典型例子是专家系统
- 规则系统体系结构风格：包括知识库、规则解释器、规则/数据选择器及工作内存
独立构建体系结构风格：强调系统中的每个构架都是相对独立的个体，它们之间不能直接通信，以降低耦合度，提升灵活性，主要包括进程通信和事件系统风格
- 进程通信体系结构风格：构件是独立的过程，连接件是消息传递；特点是构件通常是命名过程，消息传递的方式可以是点到点、异步或同步方式及远程过程调用等
- 事件系统体系结构风格：构件不直接调用一个过程，而是触发或广播一个或多个事件，系统自动调用在事件中注册的所有过程。
软件架构复用
定义：开发一组基本的软件构造模块，以覆盖不同的需求/体系结构之间的相似性，从而提高系统开发的效率、质量、性能；是以一种系统化的软件开发过程，通过识别、开发、分类、获取和修改软件实体，以便在不同的软件开发过程中重复使用它们。
类型：
- 机会复用：在开发过程中，只要发现有可复用的资产就对其进行复用
- 系统复用：在开发之前，要进行规划以决定需要复用哪些资产
软件架构复用的原因：减少开发工作，减少开发时间、降低开发成本、提高生产力，提高产品质量使其具有更好的互操作性，使产品维护变得更加简单。
复用的对象及形式
需求、架构设计、元素、建模与分析、测试、项目规划、过程、方法和工具、人员、样本系统、缺陷消除
软件架构复用的基本过程
主要包括3个阶段：
构造/获取可复用的软件资产→管理资产→复用资产
特定领域软件体系结构（Domain Specific Software Architecture，DSSA）
定义：在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构
特征：
- 一个严格定义的问题域和问题解域
- 具有普遍性，使其可以用于领域中某个特定应用的开发
- 对整个领域的构件组织模型的恰当抽象
- 具备该领域固定的、典型的在开发过程中可重用元素
两种理解DSSA中利于的含义的方式
- 垂直域：一个特定的系统族，包含整个系统族内多个系统，在该领域中可作为系统的可行解决方案的通用软件体系结构
- 水平域：在多个系统和多个系统族中功能区域的共有部分
DSSA的基本活动
领域分析：主要目标使获得领域模型，通过分析领域中系统的共性需求，建立领域模型
领域设计：设计DSSA，且DSSA需要具备领域需求变化的适应型
领域实现：获取可重用信息
参与DSSA的人员
领域专家、领域分析人员、领域设计人员、领域实现人员
DSSA建立过程
- 定义领域范围
- 定义领域特定的元素
- 定义领域特定的设计和实现需求约束
- 定义领域模型和体系结构
- 产生、搜集可重用的产品单元
