6.1 软件架构概念
6.1.1 软件架构定义
软件架构（软件体系结构）是指系统的一个或者多个结构。结构中包括软件的构件，构件的外部可见属性以及它们之间的相互关系。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用（连接件）、指导构件集成的模式以及这些模式的约束组成。
- 软件架构是从需求分析到软件设计之间的过渡过程，软件架构不仅指定了系统组织结构和拓扑结构，并显示了系统需求和构件之间的对应关系。
- 架构设计就是需求分配，将满足需求的职责分配到组件上。
- 研究软件架构的根本目的是为了解决好软件的复用、质量和维护问题。
- 软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动，是一个迭代过程。架构设计主要关注软件组件等结构、属性和交互作用，并通过多种视图全面描述特定系统等架构。
- 软件架构能够在设计变更相对容易的阶段，考虑系统结构等可选方案，便于技术人员和非技术人员就软件设计进行交互，能够展现软件的结构、属性和内部交互关系。
- 软件架构上系统干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性。
- 软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。
- 软件架构是可传递、可复用的模型，通过研究软件架构可以预测软件的质量。
6.1.2 软件架构设计生命周期
- 需求分析阶段
是SA研究的起步阶段。主要关注：
1）如何根据需求模型转换SA模型。
2）如何保证模型转换的可追溯性。
需求模型转换SA模型一般是通过词法分析和经验规则完成，可追溯性可通过表格和用例图Map维护。 - 设计阶段
是SA研究关注最早最多的阶段。主要研究：
1）SA模型的描述。
2）设计与分析方法。
3）设计经验的总结与复用。
SA模型描述的研究分为三个层次：SA的基本概念（构件和连接子）、架构描述语言ADL、SA模型的多视图表示。 - 实现阶段
主要研究：
1）研究基于SA的开发过程支持，如项目组织结构、配置管理等。
2）寻求从SA向实现过渡的途径。如将程序设计语言元素引入SA阶段、模型映射、构件组装、复用中间件平台等。
3）研究基于SA的测试技术。
SA模型向实现的主要方法：
1）SA模型中引入实现阶段的程序设计语言元素。
2）模型转换，将SA模型转换成可实现的模型。
3）封装，在SA指导下封装组件实现系统。 - 构件组装阶段
在构件组装过程中，SA设计模型起到了系统蓝图作用。主要研究：
1）如何支持可复用组件的互联，即对SA设计模式中规约的连接子的实现提供支持。
2）如何检测并消除体系结构失配的问题。
失配问题主要包括：由构件引起的失配、由连接子引起的失配、由于系统成分对全局体系结构的假设存在冲突引起失配等。 - 部署阶段
SA对部署对作用如下：
1）提供高层的体系结构视图来描述部署阶段的软硬件模型。
2）基于SA的模型可分析部署方案的质量属性，从而选择合理的部署方案。 - 后开发阶段
是指软件部署安装后的阶段，这一阶段SA研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括：
1）动态软件体系结构：架构会在运行时发生改变。
2）体系结构恢复与重建。
6.1.3 软件架构的重要性
软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。
1.架构设计能够满足系统的品质，通过架构设计文档化，可以尽早地评估项目的这些品质。
2.架构设计使受益人达成一致的目标
3.架构设计能够支持计划编制过程
4.架构设计对系统开发的指导性
5.架构设计能够有效地管理复杂性
6.架构设计为复用奠定了基础
7.架构设计能够降低维护费用
8.架构设计能够支持冲突分析
6.2 基于架构的软件开发方法
6.2.1 体系结构设计方法概述
基于体系结构的软件设计 (Architecture-Based Software Design,ABSD) 方法是由体系结构驱动的，即指由构成体系结构的商业、质量和功能需求的组合驱动的。使用ABSD 方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求抽取和分析还没有完成就开始了软件设计，而是应该与设计活动并行。
ABSD方法的3个基础：功能分解、通过选择体系结构风格来实现质量和商业需求、软件模板的使用。
ABSD 方法是一个自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。
6.2.2 概念与术语
- 设计元素
在最顶层：“系统” 被分解成 “概念子系统” + “软件模板”
在第二层：“概念子系统” 被分解成 “概念构件” + “附加软件模板”（详见书254页图7-1） - 视角与视图
从不同视角展示架构，如逻辑视图、实现视图、进程视图、配置视图 - 用例和质量场景
在使用用例捕获功能需求的同时，人们通过定义特定场景来捕获质量需求，并称这些场景为质量场景。
6.2.3 基于体系结构的开发模型
需求、设计、文档化、复审、实现、演化
6.2.4 体系结构需求
主要过程：需求获取 -》生成类图 -》对类图分组 -》把类打包成构件 -》需求评审
- 需求获取
体系结构需求一般来自3个方面：系统的质量目标、系统的商业目标和系统开发人员的商业目标。 - 标识构件
为系统生成初始逻辑结构、大致的构件。步骤：生成类图、对类图分组、把类打包成构件。 - 需求评审
需求获取一标识构件一需求评审之间进行迭代。
6.2.5 体系结构设计
主要过程：
1）提出软件系统模型
2）把在体系结构需求阶段已标识的构件映射到体系结构中
3）分析构件之间相互作用
4）产生体系结构
5）评审体系结构
6.2.6 体系结构文档化
主要输出结果是两个文档：
1）体系结构规格说明
2）（测试体系结构需求的）质量设计说明书
6.2.7 体系结构复审
体系结构设计、文档化和复审是一个迭代过程。
要安排一次由外部人员(用户代表和领域专家)参加的复审。
复审的目的：是标识潜在的风险，及早发现体系结构设计中的缺陷和错误，包括体系结构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等。
6.2.8 体系结构实现
实现过程：
复审文档化的体系结构后进行：分析与设计 -》构件实现 -》 构件组装 -》系统测试，完成后进入体系结构演化
6.2.9 体系结构演化
演化是指需求发生变化后做出相应修改，以满足新需求。主要过程：
需求变化归类 -》制定演化计划 -》构件变动 -》更新构件的相互作用 -》构件组装与测试 -》技术评审
构件（补充）
- 构件是一个可独立交付的功能单元，外界通过接口访问其提供的服务。
- 构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模块和一组资源。原子构件是部署、版本控制、替换掉基本单位。
- 构件和原子构件的区别：原子构件永远不会单独部署。
- 一个模块是不带单独资源的原子构件。
- 一个单独的包编被译成多个单独的类文件，
- 模块是一组类和可能的非面向对象的结构体，比如过程或函数。
- 构件的特性：
1）独立部署单元。
2）作为第三方组装单元。
3）没有（外部）可见状态。
一个构件可以包含多个类元素，一个类元素只能属于一个构件。 - 对象的特征：
1）一个实例的单元，具有唯一的标志。
2）可能具有状态，该状态外部可见。
3）封装了自己的状态和行为。 - 构件的接口
接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化为参数化操作集合，而是关注输入输出的消息的标准化。 - 面向构件的编程COP
关注如何支持建立面向构件的解决方案。需要下列基本支持：
1）多态性（可替换性）
2）模块封装性（高层次信息的隐藏）
3）后期的绑定和装载（部署独立性）
4）安全性（类型和模块安全性） - 构件技术就是利用某种编程手段，将一些人们关心的，但又不便让最终用户去直接操作的细节进行类封装。
- 构件标准的三大流派：
1）EJB ：由Sun公司制定，有三种类型分别是：会话Bean（Session Bean），实体Bean（Entity Bean）、和消息驱动Bean（Message-Driven Bean），EJB实现应用中关键的业务逻辑，创建基于构件的企业级应用程序。
2）COM、DCOM、COM+：由微软制定。DCOM上COM扩展，具有位置独立性和语言无关性。
3）CORBA标准：主要分三个层次：对象请求代理、公共服务对象和公共设施。最底层是对象请求代理，规定了分布对象的接口和语言映射，实现对象之间的通信和互操作，是分布对象中的软总线。
在ORB上定义了很多公共服务，最上层的公共设施则定义了组件框架，提供可直接为业务对象使用的服务。
6.3 软件架构风格
6.3.1 软件架构风格概述
- 软件体系结构风格是描述某一个特定应用领域中系统组成方式的惯用模式。
- 架构风格定义一个系统家族，即一个架构定义、一个词汇表和一组约束。词汇表包含一些构件和连接件类型，一组约束是指系统如何将这些构件和连接件组合起来。
- 架构风格反映了领域中众多系统共有结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整系统。
- 架构设计的一个核心问题是能否达到架构级的软件复用。
- 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
- 数据流风格
面向数据流，按照一定的顺序执行，代表风格有：- 批处理风格：按照步骤处理，每一步必须在前一步结束后才能开始。
- 管道过滤器风格：每个处理步骤由一个过滤器 (Filter) 实现，处理步骤之间的数据传输由管道 (Pipe) 负责。
- 调用/返回风格
构件之间存在相互调用关系，一般是显式调用，代表风格有：- 主程序/子程序风格：
- 面向对象的风格
- 层次型风格
- 客户端/服务器风格
- 独立构件风格
构件间是相互独立的，不存在显式调用关系，而是通过某个事件触发，异步方式执行，代表风格有：- 进程通信
- 事件驱动系统（隐式调用）
- 虚拟机风格
自定义一套规则攻使用者使用，使用者基于这个规则来开发构件，能够跨平台适配，代表风格有：- 解释器
- 基于规则的系统
- 数据中心风格
以数据为中心，所有操作都是围绕建立的数据中心进行的，代表风格有：- 仓库风格
- 黑板风格
6.3.2 数据流风格
- 批处理序列
构件为一系列固定顺序的计算单元，构件间只通过数据传递交互。每个处理步骤是一个独立程序。每一步必须在前一步结束后才能开始，数据必须是完整的，以整体方式传递。 - 管道过滤器风格
系统分解为几个序贯的处理步骤，这些步骤之间通过数据流连接，一个步骤的输出是另一个步骤的输入。每个处理步骤由一个过滤器 (Filter) 实现，处理步骤之间的数据传输由管道 (Pipe) 负责。每个处理步骤(过滤器)都有一组输入和输出，过滤器从管道中读取输入的数据流，经过内部处理，然后产生输出数据流并写入管道中。因此，管道-过滤器风格基本构件是过滤器，连接件是数据流传输管道，将一个过滤器的输出传到另一过滤器的输入。 - 主要区别：
- 批处理前后构件不一定有关联，管道是前一个输出作为后一个输入，前面执行到部分可以开始下一个的执行。
- 批处理的传递数据必须是完整，以整体方式传递，管道可以部分传传递（例如流媒体）。
6.3.3 调用/返回风格
调用/返回风格是指在系统中采用了调用与返回机制。利用调用-返回实际上是一种分而治之的策略，其主要思想是将一个复杂的大系统分解为若干子系统，以便降低复杂度，并且增加可修改性。程序从其执行起点开始执行该构件的代码，程序执行结束，将控制返回给程序调用构件。
- 主程序/子程序风格
主程序/子程序风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。 - 面向对象风格
构件是对象，对象交互的方式是连接件，对象是通过函数和过程调用来交互的。 - 层次型风格
构件组成一个层次结构，连接件通过决定层间如何交互的协议来定义。每一层为上层提供服务，并作为下层的客户，修改某一层，最多影响相邻两层。
层次结构的有点：
1）支持基于可增加抽象层的设计，允许将一个复杂的问题分解成一个增量步骤序列来实现。
2）不同的层次处于不同抽象级别，越靠近底层，抽象级别越高。
3）由于每一层只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，为软件复用提供了强大支持。
层次结构缺点：
1）不是每个系统都适合分层。
2）很难找到正确、合适的层次抽象方法。 - 客户机/服务器风格
两层 C/S 体系结构有3部分组成：数据库服务器、客户应用程序和网络，称为“胖客户机，瘦服务器”。三层C/S结构是增加了一个应用服务器，整个应用逻辑在应用服务器上，只有表示层存在于客户机上，称为“瘦客户机”。
三层结构优点：
1）各层逻辑上保持相对独立，逻辑结构清晰，提高了系统可维护性和可扩展性。
2）允许灵活有效的选用相应的平台和硬件系统，具有良好的可升级性和开放性。
3）各层可以并行开发，可以选择不同开发语言。
4）功能层有效的隔离表示层与数据层，为严格的安全管理奠定了基础，整个系统管理层次更加合理可控。
三层结构设计的关键在于各层之间的通信效率。
6.3.4 数据中心风格
- 仓库风格
仓 库 (Repository) 是存储和维护数据的中心场所。有两种不同的构件：中央数据结构说明当前数据的状态以及一组对中央数据进行操作的独立构件，仓库与独立构件间的相互作用在系统中会有大的变化。这种风格的连接件即为仓库与独立构件之间的交互。
数据库系统属于仓库风格 - 黑板风格
黑板体系结构风格适用于解决复杂的非结构化的问题，能在求解过程中综合运用多种不同知识源，使得问题的表达、组织和求解变得比较容易。黑板系统是一种问题求解模型，是组织推理步骤、控制状态数据和问题求解之领域知识的概念框架。
黑板系统包括黑板、知识源和控制模块的构件来设计，也可以利用预先定制的黑板体系结构的编程环境。黑板是一个全局数据库，知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应是通过黑板状态的变化来控制的。
黑板风格常应用于对于解决问题没有确定性的算法的软件中（信号处理、问题规划和编译器优化等）。 - 超文本系统
构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。通常应用于互联网领域。 - 现代编译器的集成开发环境IDE一般采用数据仓库架构风格。
6.3.5 虚拟机风格
自定义一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配，代表风格有：
- 解释器
一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。其缺点是执行效率较低。典型的例子是专家系统。 - 基于规则的系统
基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存，一般用于人工智能领域和DSS决策支持系统中。
6.3.6 独立构件风格
- 进程通信
构件是独立的进程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式、以及远程过程（方法）调用RPC等。 - 事件驱动系统（隐式调用）
构件不直接调用一个过程，而是触发或广播一个或多个事件，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。 - 优点：为软件复用提供了强大的支持，为构件的维护和演化带来了方便。
- 缺点：构件放弃了对系统计算的控制。
闭环控制风格（补充）
当软件用来操作一个物理系统时，软件与硬件之间可以粗略的表示为一个反馈循环。这个反馈循环接收一个输入，确定一系列输出，最终使环境达到一个新的状态，适合于嵌入式系统，涉及连续的动作与状态。例如：空调系统、汽车定速巡航。
C2体系风格（补充）
通过连接件绑定在一起的按照一组规则运作的并行构件网络。系统组织规则如下：
1）系统中的构件和连接件都有一个顶部和一个底部。
2）构件的顶部应连接到某连接件的底部，构件的底部应连接到某连接件的顶部，构件之间不允许直接连接。
3）一个连接件可以和任意数目的其他构件和连接件连接。
4）当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
架构补充
- 三层B/S架构：0客户端，客户端为浏览器，应用服务器为WEB服务器。
- 富互联网应用RIA：无须提前安装，访问时加载客户端，结合了C/S和B/S本质0客户端，例如小程序。
- MVC架构：模型、视图、控制器结构，缺点：Model直接与View关联，不安全。
- MVP架构：Controller换成Presenter（呈现），目前切断View跟Model之间联系。
- MVVM架构：Model、View、ViewModel
- SOA面向服务器架构
面向服务编程，粒度粗、松耦合。服务是业务的实现。SOA不仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同服务，多个服务可以通过企业服务总线ESB统一处理。- 实现SOA关键目标是实现企业IT资产重用的最大化。
- 实现SOA要点：可从企业外部访问、随时可用、粗粒度接口、服务分级、松散耦合、可重用的服务及接口设计管理、标准化接口、支持各种消息模式、精确定义业务接口。
- 从基于对象到基于构建再到基于服务，架构越来越松散耦合，粒度越来越粗，接口越来越标准。
- 基于服务的构件与传统构件的区别：
1）服务构件粒度粗，传统构件粒度细。
2）服务构件接口标准（主要是WSDL接口），传统构件常以API形式出现。
3）服务构件的实现与语言无关，传统构件一般是特点语言。
4）服务构件可以通过构件容器提供QoS的服务，传统构件完全由程序代码直接控制。 - SOA中关键技术
- 服务发现：提供服务提供者、服务使用者注册发现服务，使用协议：UDDI、DISCO
- 服务描述：服务的描述信息，协议：WSDL、XML Schema
- 消息格式层：
- 编码格式层：
- 传输协议层：
- UDDI：统一描述发现集成
- WSDL：Web服务描述语言
- SOAP：简单对象访问协议
- XML：可扩展标记语言
- SOA实现
- Web Service：
- 服务注册表：服务注册-服务位置-服务绑定
- ESB：企业服务总线，通过一根管道，用来连接各个服务节点。包括客户端（服务请求者）、基础架构服务（中间件）、核心集成服务（提供服务）。
- ESB特点
架构风格总结（总结不好，有时间再补充）
| 架构风格 | 特点 |
|---|---|
| 数据流—批处理风格 | 按照步骤处理，每一步必须在前一步结束后才能开始，数据必须是完整的，以整体方式传递。 |
| 数据流—管道过滤器风格 | 前一个输出作为后一个输入，上一步没有结束可以开始下一个的执行，数据可以部分传递。 |
| 调用返回—主程序子程序 | 构件之间存在相互调用关系，一般是显式调用 |
| 调用返回—面向对象 | 构件是对象，对象交互的方式是连接件，对象是通过函数和过程调用来交互的 |
| 调用返回—层次结构 | 分层，每一层为上层提供服务，并作为下层的客户，修改某一层，最多影响相邻两层。 |
| 数据中心—仓库风格 | 以数据为中心，仓库为中央数据库，以及一组对中央数据进行操作的独立构件组成 |
| 数据中心—黑板风格 | 黑板系统是一种问题求解模型，黑板是全局数据库，知识源是解决问题的知识， 控制模块用于控制，实现解决复杂的非结构化的问题，适用语音识别、推理 |
| 数据中心—超文本 | 网状连接，多用于互联网 |
| 虚拟机—解释器 | 可自定义一套规则，由解释引擎、一个包含将被解释的代码的存储区、记录状态进度的数据结构组成，可跨平台，效率低。典型专家系统 |
| 虚拟机—基于规则系统 | 人工智能，决策支持系统 |
| 独立构件—超文本 | |
| 独立构件—进程通信 | 显示调用 |
| 独立构件—事件驱动 | 隐式调用，例如编辑器中语法高亮显示 |
| 闭环控制风格 | 空调系统 |
| C2风格 | 并行构件网络 |
6.4 软件架构的复用技术
6.4.1 软件架构的复用的定义与分类
软件复用是指系统化的软件开发过程:开发一组基本的软件构造模块，以覆盖不同的需求/ 体系结构之间的相似性，从而提高系统开发的效率、质量和性能。
软件架构复用的类型包括机会复用和系统复用。
6.4.2 软件架构复用的原因
减少开发工作、减少开发时间、降低开发成本，提高生产力、提高产品质量，使其具有更好的互操作性、使维护变得更加简单。
6.4.3 软件架构复用的对象及形式
复用资产：需求、架构设计、元素、建模与设计、测试、项目规划、过程、方法和工具、人员、样本系统、缺陷消除。
复用形式：函数复用、库的复用、类、接口、包的复用。
6.4.4 软件架构复用的基本过程
- 构造/获取可复用的软件资产
- 其次管理这些资产
- 复用
其中建立构件库，是支持软件复用的必要设施。其中存在两个关键问题：一是构件分类，二是构件检索。
6.5 特殊领域软件架构
6.5.1 DSSA定义
DSSA(Domain Specific Software Architecture) 就是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构。
- DSSA的必备特征：
(1)一个严格定义的问题域和问题解域。
(2)具有普遍性，使其可以用于领域中某个特定应用的开发。
(3)对整个领域的构件组织模型的恰当抽象。
(4)具备该领域固定的、典型的在开发过程中可重用元素。 - DSSA中领域：
(1)垂直域:定义了一个特定的系统族，只能应用于一个成熟的、稳定的领域，但这个条件比较难以满足。
(2)水平域:定义了在多个系统和多个系统族中功能区城的共有部分。在子系统级上涵盖多个系统族的特定部分功能。
6.5.2 DSSA的基本活动
领域分析、领域设计、领域实现。
6.5.3 参与DSSA的人员
- 领域专家：
领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程 的依据，复审领域模型、 D S S A等领域工程产品等。 - 领域分析人员：
领域分析人员的主要任务包括控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中，根据现有系统、标准规范等验证领域模型的准确性和一致性，维护领域模型。 - 领域设计人员：
领域设计人员的主要任务包括控制整个 软件设计过程，根据领域模型和现有的系统开发出DSSA, 对DSSA的准确性和一致性进行验 证，建立领域模型和 D S S A 之间的联系。
领域实现人员：
领域实现人员的主要任务包括根据领域 模型和DSSA, 或者从头开发可重用构件，或者利用再工程的技术从现有系统中提取可重用构件，对可重用构件进行验证，建立 D S S A 与可重用构件间的联系。
6.5.4 DSSA的建立过程
DSSA的建立过程分为5个阶段，每个阶段可以进一步划分为一些步骤或子阶段。每个 阶段包括一组需要回答的问题，一组需要的输入，一组将产生的输出和验证标准。本过程是并发的 (Concurrent)、递归的 (Recursive)、 反复的 (Iterative)。 或者可以说，它是螺旋模型(Spiral)。
(1)定义领域范围。
(2)定义领域特定的元素。
(3)定义领域特定的设计和实现需求约束。
(4)定义领域模型和体系结构。
(5)产生、搜集可重用的产品单元。
1610
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
