软考高级《系统架构设计师》知识点（十三）

系统架构设计

软件架构的概念

一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件，构件的外部可见属性以及它们之间的相互关系。

体系结构并非可运行软件。确切地说，它是一种表达，使软件工程师能够：

分析设计在满足所规定的需求方面的有效性：
在设计变更相对容易的阶段，考虑体系结构可能的选择方案；
降低与软件构造相关联的风险。

软件构件简单到可以是程序模块或者面向对象的类，也可以扩充到包含数据库和能够完成客户与服务器网络配置的"中间件"。

软件体系结构的设计两个层次：数据设计和体系结构设计。数据设计体现传统系统中体系结构的数据构件和面向对象系统中类的定义(封装了属性和操作),体系结构设计则主要关注软件构件的结构、属性和交互作用。

软件架构设计与生命周期

需求分析阶段。需求分析和SA设计面临的是不同的对象：一个是问题空间；另一个是解空间。从软件需求模型向SA模型的转换主要关注两个问题：如何根据需求模型构建SA模型。如何保证模型转换的可追踪性。
设计阶段。是SA研究关注的最早和最多的阶段，这一阶段的SA研究主要包括：SA模型的描述、SA模型的设计与分析方法，以及对SA设计经验的总结与复用等。有关SA模型描述的研究分为3个层次：SA的基本概念(构件和连接子)、体系结构描述语言ADL、SA模型的多视图表示。
实现阶段。最初SA研究往往只关注较高层次的系统设计、描述和验证。为了有效实现SA设计向实现的转换，实现阶段的体系结构研究表现在以下几个方面。

研究基于SA的开发过程支持，如项目组织结构、配置管理等。
寻求从SA向实现过渡的途径，如将程序设计语言元素引入SA阶段、模型映射、构件组装、复用中间件平台等。
研究基于SA的测试技术。

构件组装阶段。在SA设计模型的指导下，可复用构件的组装可以在较高层次上实现系统，并能够提高系统实现的效率。在构件组装的过程中，SA设计模型起到了系统蓝图的作用。研究内容包括如下两个方面。

如何支持可复用构件的互联，即对SA设计模型中规约的连接子的实现提供支持。
在组装过程中，如何检测并消除体系结构失配问题。
在构件组装阶段的失配问题主要包括：由构件引起的失配、由连接子引起的失配、由于系统成分对全局体系结构的假设存在冲突引起的失配等。

部署阶段。SA对软件部署作用如下。

提供高层的体系结构视图来描述部署阶段的软硬件模型。
基于SA模型可以分析部署方案的质量属性，从而选择合理的部署方案。

后开发阶段。是指软件部署安装之后的阶段。这一阶段的SA研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。

动态软件体系结构。现实中的软件具有动态性，体系结构会在运行时发生改变。
运行时变化包括两类：软件内部执行所导致的体系结构改变；软件系统外部的请求对软件进行的重配置。
包括两个部分的研究：体系结构设计阶段的支持、运行时刻基础设施的支持。
体系结构恢复与重建。对于现有系统在开发时候没有考虑SA的情况，从这些系统中恢复或重购体系结构。从已有的系统中获取体系结构的重建方法分为4类：手工体系结构重建、工具支持的手工重建、通过查询语言来自动建立聚集、使用其他技术(如数据挖掘等)。

架构设计概述:从需求分析到软件设计之间的过渡过程称为软件架构。只要软件架构设计好了，整个软件就不会出现坍塌性的错误，即不会崩溃。

架构设计就是需求分配，将满足需求的职责分配到组件上。

软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用 (连接件)、指导构件集成的模式以及这些模式的约束组成。

软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。

解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。

软件架构设计包括提出架构模型，产生架构设计和进行设计评审等活动，是一个迭代的过程。架构设计主要关注软件组件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。

架构设计作用:软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。

软件架构是项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性。

软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。

软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。

构件是一个独立可交付的功能单元，外界通过接口访问其提供的服务。

构件由一组通常需要同时部署的原子构件组成。一个原子构件是一个模块和一组资源。原子构件是部署、版本控制和替换的基本单位。原子构件通常成组地部署，但是它也能够被单独部署。

构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。相反，大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。

一个模块是不带单独资源的原子构件(在这个严格定义下，Java包不是模块------在Java中部署的原子单元是类文件。一个单独的包被编译成多个单独的类文件------每个公共类都有一个)。

模块是一组类和可能的非面向对象的结构体，比如过程或者函数。

构件的特性是：(1)独立部署单元；(2)作为第三方的组装单元；(3)没有(外部的)可见状态。一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。

对象的特性是：(1)一个实例单元，具有唯一的标志。(2)可能具有状态，此状态外部可见。(3)封装了自己的状态和行为。

接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化为参数化操作的集合，而是关注输入输出的消息的标准化，它强调当机器在网络中互连时，标准的消息模式、格式、协议的重要性。

面向构件的编程(COP)：关注于如何支持建立面向构件的解决方案。"面向构件的编程需要下列基本的支持：

多态性(可替代性);
模块封装性(高层次信息的隐藏);
后期的绑定和装载(部署独立性);
安全性(类型和模块安全性)。"

基于架构的软件开发方法

ABSD方法是架构驱动，强调由业务、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。进一步来说，用例描述的是功能需求，质量属性场景描述的是质量需求(或侧重于非功能需求)。

使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成，就开始了软件设计。ABSD方法有三个基础。第一个基础是功能的分解，使用已有的基于模块的内聚和耦合技术；第二个基础是通过选择架构风格来实现质量和业务需求；第三个基础是软件模板的使用，软件模板利用了一些软件系统的结构。

ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，有助于降低架构设计的随意性。

架构设计是在需求分析之后，概要设计之前，是为了解决需求分析和软件设计之间的鸿沟问题。

基于架构的软件开发过程可分为下列六步：

架构需求：重在掌握标识构件的三步
架构设计：将需求阶段的标识构件映射成构件，进行分析
架构(体系结构)文档化：主要产出两种文档，即架构(体系结构)规格说明，测试架构(体系结构)需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败。
架构复审：由外部人员(独立于开发组织之外的人，如用户代表和领域专家等)参加的复审，复审架构是否满足需求，质量问题，构件划分合理性等。若复审不过，则返回架构设计阶段进行重新设计、文档化，再复审。
架构实现：用实体来显示出架构。实现构件，构件组装成系统
架构演化：对架构进行改变，按需求增删构件，使架构可复用

软件架构风格

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。

架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。

架构设计的一个核心问题是能否达到架构级的软件复用。

架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。

数据流风格：面向数据流，按照一定的顺序从前向后执行程序，代表的风格有批处理序列、管道-过滤器。

调用/返回风格：构件之间存在互相调用的关系，一般是显式的调用，代表的风格有主程序/子程序、面向对象、层次结构(C/S架构风格本质属于层次风格)。

独立构件风格：构件之间是互相独立的，不存在显式的调用关系，而是通过某个事件触发、异步的方式来执行，代表的风格有进程通信、事件驱动系统(隐式调用)。

虚拟机风格：自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配，代表的风格有解释器、基于规则的系统。

仓库风格：以数据位中心，所有的操作都是围绕建立的数据中心进行的，代表的风格有数据库系统、超文本系统、黑板系统。

数据流风格,批处理序列：构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式传递。

数据流风格,管道-过滤器：每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理，产生输出数据流。前一个构件的输出作为后一个构件的输入，前后数据流关联。过滤器就是构件，连接件就是管道。

主程序/子程序：单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。过程调用作为交互机制，充当连接件的角色。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。

面向对象：构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来，对象的行为体现在其接受和请求的动作。连接件即使对象间交互的方式，对象是通过函数和过程的调用来交互的。

层次结构：构件组成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的两层(通常只能影响上层)

层次结构优点：

支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。
不同的层次处于不同的抽象级别，越靠近底层，抽象级别越高；越靠近顶层，抽象级别越低。
由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持。

缺点：

并不是每个系统都可以很容易的划分为分层的模式。
很难找到一个合适的、正确的层次抽象方法。

进程通信：构件是独立的进程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程(方法)调用等。

事件驱动系统(隐式调用):构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便；缺点是构件放弃了对系统计算的控制。

解释器：通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，缺点是执行效率低。

基于规则的系统：包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。

仓库风格:数据共享风格，以数据为中心。

数据库系统：构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。

黑板系统：包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应式通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中(信号处理、问题规划和编译器优化等)。

超文本系统：构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。是一种非线性的网状信息组织方法，它以节点为基本单位，链作为节点之间的联想式关联。通常应用在互联网领域。

现代编译器的集成开发环境一般采用数据仓储(即以数据为中心的架构风格)架构风格进行开发，其中心数据就是程序的语法树。

闭环控制架构(过程控制):当软件被用来操作一个物理系统时，软件与硬件之间可以粗略的表示为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态，适合于嵌入式系统，涉及连续的动作与状态。

C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。

C2风格中的系统组织规则如下：

系统中的构件和连接件都有一个顶部和一个底部；
构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
一个连接件可以和任意数目的其它构件和连接件连接；
当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

两层C/S架构，客户端和服务器都有处理功能，相比较于传统的集中式软件架构，还是有不少优点的，但是现在已经不常用，原因有：开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一、软件移植困难、软件维护和升级困难、新技术不能轻易应用、安全性问题、服务器端压力大难以复用。

三层C/S架构，将处理功能独立出来，表示层和数据层都变得简单。表示层在客户机上，功能层在应用服务器上，数据层在数据库服务器上。即将两层C/S架构中的数据从服务器中独立出来了。

三层C/S架构其优点下面四点：

各层在逻辑上保持相对独立，整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性；
允许灵活有效的选用相应的平台和硬件系统，具有良好的可升级性和开放性；
各层可以并行开发，各层也可以选择各自最适合的开发语言；
功能层有效的隔离表示层与数据层，为严格的安全管理奠定了坚实的基础，整个系统的管理层次也更加合理和可控制。

三层C/S架构设计的关键在于各层之间的通信效率，要慎重考虑三层间的通信方法、通信频度和数据量，否则即使分配给各层的硬件能力很强，性能也不高。

三层B/S架构：是三层C/S架构的变种，将客户端变为用户客户端上的浏览器，将应用服务器变为网上的WEB服务器，又称为0客户端架构，虽然不用开发客户端，但有很多缺点，主要是数据处理能力差：

B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；
安全性难以控制；
在数据查询等响应速度上，要远远低于C/S架构；
数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用。

混合架构风格,内外有别模型：企业内部使用C/S,外部人员访问使用B/S。

混合架构风格,查改有别模型：采用B/S查询，采用C/S修改。

混合架构风格,混合架构实现困难，且成本高。

富互联网应用RIA，弥补三层B/S架构存在的问题，RIA是一种用户接口，比用HTML实现的接口更加健壮，且有可视化内容，本质还是网站模式，其优点如下：

RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性；
RIA简化并改进了B/S架构的用户交互；
数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。

富互联网应用RIA本质还是0客户端，借助于高速网速实现必要插件在本地的快速缓存，增强页面对动态页面的支持能力，典型的如小程序。

MVC用户操作->View(负责接收用户的输入操作)->Controller(业务逻辑处理)->Model(数据持久化)->View(将结果反馈给View)。

MVP是把MVC中的Controller换成了Presenter(呈现),目的就是为了完全切断View跟Model之间的联系，由Presenter充当桥梁，做到View-Model之间通信的完全隔离。

MVVM：如果说MVP是对MVC的进一步改进，那么MVVM则是思想的完全变革。它是将"数据模型数据双向绑定"的思想作为核心，因此在View和Model之间没有联系，通过ViewModel进行交互，而且Model和ViewModel之间的交互是双向的，因此视图的数据的变化会同时修改数据源，而数据源数据的变化也会立即反应到View上。

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口、进行通信，不涉及底层编程接口和通信模型。

在SOA中，服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。

SOA并不仅仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同服务。多个服务通过企业服务总线提出服务请求，由应用管理来进行处理。

实施SOA的关键目标是实现企业IT资产重用的最大化，在实施SOA过程中要牢记以下特征：可从企业外部访问、随时可用(服务请求能被及时响应)、粗粒度接口(粗粒度提供一项特定的业务功能，而细粒度服务代表了技术构件方法)、服务分级、松散耦合(服务提供者和服务使用者分离)、可重用的服务及服务接口设计管理、标准化的接口(WSDL、SOAP、XML是核心)、支持各种消息模式、精确定义的服务接口。

从基于对象到基于构件再到基于服务，架构越来越松散耦合，粒度越来越粗，接口越来越标准。

基于服务的构件与传统构件的区别有四点：

服务构件粗粒度，传统构件细粒度居多；
服务构件的接口时标准的，主要是WSDL接口，而传统构件常以具体API形式出现；
服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言；
服务构件可以通过构件容器提供QoS的服务，而传统构件完全由程序代码直接控制。

发现服务

UDDI:用于Web服务注册和服务查找，描述了服务的概念，定义了编程的接口，供其他企业来调用。
DISCO:发现公开服务的功能及交互协议。

描述服务WSDL(WEB服务描述语言)协议：用于描述Web服务的接口和操作功能，描述网络服务。

消息格式层：SOAP为建立Web服务和服务请求之间的通信提供支持。

REST(RepresentationalStateTransfer,表述性状态转移)是一种只使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。

编码格式层，扩展标记语言(ExtensibleMarkupLanguage,XML)：用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。

WEBService：服务提供者、服务注册中心(中介，提供交易平台，可有可无)、服务请求者。服务提供者将服务描述发布到服务注册中心，供服务请求者查找，查找到后，服务请求者将绑定查找结果。

WEBService分为六层：底层传输层(负责底层消息的传输，采用HTTP、JMS、SMTP协议),服务通信协议层(描述并定义服务间通信的技术标准，采用SOAP和REST协议),服务描述层(采用WSDL协议),服务层(对企业应用系统进行包装，通过WSDL定义的标准进行调用),业务流程层(支持服务发现、服务调用和点到点的服务调用，采用WSDPEL标准),服务注册层(采用UDDI协议)。

服务注册：应用开发者(服务提供者)在注册表中公布服务的功能。

服务位置：服务使用者(服务应用开发者),帮助他们查询注册服务，寻找符合自身要求的服务。

服务绑定：服务使用者利用检索到的服务接口来编写代码，所编写的代码将与注册的服务绑定，调用注册的服务，以及与它们实现互动。

服务注册表本质与WEBService类似，只是使用一个注册表来代替服务注册中心。

企业服务总线ESB,客户端(服务请求者)、基础架构服务(中间件)、核心集成服务(提供服务)。本质也是通过网络，有下列六点功能：

提供位置透明性的消息路由和寻址服务；
提供服务注册和命名的管理功能；
支持多种的消息传递范型；
支持多种可以广泛使用的传输协议；
支持多种数据格式及其相互转换；
提供日志和监控功能。

软件架构复用

软件产品线:是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。

软件架构复用的类型包括机会复用和系统复用。机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。

可复用的资产包括：需求、架构设计、元素、建模与分析、测试、项目规划、过程方法和工具、人员、样本系统、缺陷消除。

复用的基本过程主要包括3个阶段：首先构造/获取可复用的软件资产，其次管理这些资产(构件库),最后针对特定的需求，从这些资产中选择可复用的部分，以开发满足需求的应用系统。

特定领域软件架构DSSA

DSSA就是专用于一类特定类型的任务(领域)的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。

DSSA就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成。

垂直域：在一个特定领域中的通用的软件架构，是一个完整的架构。

水平域：在多个不同的特定领域之间的相同的部分的小工具(如购物和教育都有收费系统，收费系统即是水平域)。

DSSA的三个基本活动:

领域分析：这个阶段的主要目标是获得领域模型(领域需求)。识别信息源，即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。
领域设计：这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求DSSA。
领域实现：这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。
以上过程是一个反复的、逐渐求精的过程。在实施领域工程的每个阶段中，都可能返回到以前的步骤，对以前的步骤得到的结果进行修改和完善，再回到当前步骤，在新的基础上进行本阶段的活动。

参与DSSA的四种角色人员:

领域专家：包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品等等。
领域分析人员：由具有知识工程背景的有经验的系统分析员来担任。控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中。
领域设计人员：由有经验的软件设计人员来担任。根据领域模型和现有系统开发出DSSA,并对DSSA的准确性和一致性进行验证。
领域实现人员：由有经验的程序设计人员来担任。根据领域模型和DSSA,开发构件。

建立DSSA的过程:

定义领域范围：领域中的应用要满足用户一系列的需求。
定义领域特定的元素：建立领域的字典，归纳领域中的术语，识别出领域中相同和不相同的元素。
定义领域特定的设计和实现需求的约束：识别领域中的所有约束，这些约束对领域的设计和实现会造成什么后果。
定义领域模型和架构：产生一般的架构，并描述其构件说明。
产生、搜集可复用的产品单元、：为DSSA增加复用构件，使可用于新的系统。
以上过程是并发的、递归的、反复的、螺旋型的。该过程的目的是将用户的需求映射为基于实现限制集合的软件需求，这些需求定义了DSSA。

DSSA的三层次系统模型:

领域开发环境：领域架构师决定核心架构，产出参考结构、参考需求、架构、领域模型、开发工具。
领域特定的应用开发环境：应用工程师根据具体环境来将核心架构实例化。
应用执行环境：操作员实现实例化后的架构。

系统质量属性与架构评估

软件系统的质量就是"软件系统与明确地和隐含地定义的需求相一致的程度"。

可以将软件系统的质量属性分为开发期质量属性和运行期质量属性2个部分。

开发期质量属性主要指在软件开发阶段所关注的质量属性，主要包含6个方面。

易理解性：指设计被开发人员理解的难易程度。
可扩展性：软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性。
可重用性：指重用软件系统或某一部分的难易程度。
可测试性：对软件测试以证明其满足需求规范的难易程度。
可维护性：当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

运行期质量属性主要指在软件运行阶段所关注的质量属性，主要包含7个方面。

性能：性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。
安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
可靠性：软件系统在一定的时间内持续无故障运行的能力。
可用性：指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响。
鲁棒性：是指软件系统在非正常情况(如用户进行了非法操作、相关的软硬件系统发生了故障等)下仍能够正常运行的能力，也称健壮性或容错性。

面向架构评估的质量属性:

性能：指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。设计策略：优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。
可靠性：是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF。设计策略：心跳、Ping/Echo、冗余、选举。包括容错和健壮性。
可用性：是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。设计策略：心跳、Ping/Echo、冗余、选举。
安全性：是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性。设计策略：入侵检测、用户认证、用户授权、追踪审计。
可修改性：指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量。包括可维护性、可扩展性、结构重组、可移植性。设计策略：接口-实现分类、抽象、信息隐藏。
功能性：是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
可变性：指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。
互操作性：作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，也影响应用的软件体系结构。

质量属性场景是一种面向特定质量属性的需求。它由6部分组成：

刺激源(Source):这是某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)。
刺激(Stimulus):该刺激是当刺激到达系统时需要考虑的条件。
环境(Environment):该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
制品(Artifact):某个制品被激励。这可能是整个系统，也可能是系统的一部分。
响应(Response):该响应是在激励到达后所采取的行动。
响应度量(Measurement):当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

系统架构评估是在对架构分析、评估、的基础上，对架构策略的选取进行决策。

软件架构评估在架构设计之后，系统设计之前，因此与设计、实现、测试都没有关系。评估的目的是为了评估所采用的架构是否能解决软件系统需求，但不是单纯的确定是否满足需求。

三种常用的评估方式:

基于调查问卷(检查表)的方式：类似于需求获取中的问卷调查方式，只不过是架构方面的问卷，要求评估人员对领域熟悉。
基于度量的方式：制定一些定量来度量架构，如代码行数等。要制定质量属性和度量结果之间的映射，要求评估人员对架构熟悉。涉及3个基本活动，首先需要建立质量属性和度量之间的映射原则，然后从软件架构文档中获取度量信息，最后根据映射原则分析推导出系统的质量属性。
基于场景的方式：主要方法。首先要确定应用领域的功能和软件架构的结构之间的映射，然后要设计用于体现待评估质量属性的场景(即4+1视图中的场景),最后分析软件架构对场景的支持程度。要求评估人员即对领域熟悉，也对架构熟悉。
场景最不通用，度量要求对构架精确了解，调查问卷实施阶段最早，度量最客观。其中，基于场景的方式是主流。

架构评估中的重要概念:

敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。

风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念，即可能引起风险的因素，可称为风险点。某个做法如果有隐患，有可能导致一些问题，则为风险点；而如果某件事是可行的可接受的，则为非风险点。

从三个方面对场景进行设计：刺激(事件);环境(事件发生的环境);响应(架构响应刺激的过程)。

SAAM：是一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法。

特定目标。SAAM的目标是对描述应用程序属性的文档，验证基本的架构假设和原则。
质量属性。这一方法的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。
架构描述。SAAM用于架构的最后版本，但早于详细设计。架构的描述形式应当被所有参与者理解。功能、结构和分配被定义为描述架构的3个主要方面。
方法活动。SAAM的主要输入是问题描述、需求声明和架构描述。下图描绘了SAAM分析活动的相关输入及评估过程。包括5个步骤，即场景开发、架构描述、单个场景评估、场景交互和总体评估。

架构权衡分析法ATAM：让架构师明确如何权衡多个质量目标，参与者有评估小组、项目决策者和其他项目相关人。

ATAM被分为四个主要的活动领域，分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中。整个评估过程强调以属性作为架构评估的核心概念。主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

ATAM方法采用效用树(Utilitytree)这一工具来对质量属性进行分类和优先级排序。效用树的结构包括：树根-质量属性-属性分类-质量属性场景(叶子节点)。需要注意的是，ATAM主要关注4类质量属性：性能、安全性、可修改性和可用性，这是因为这4个质量属性是利益相关者最为关心的。

成本效益分析法CBAM：用来对架构建立的成本来进行设计和建模，让决策者根据投资收益率来选择合适的架构，可以看做对ATAM的补充，在ATAM确定质量合理的基础上，再对效益进行分析。有下列步骤：

整理场景(确定场景，并确定优先级，选择三分之一优先级最高的场景进行分析);
对场景进行细化(对每个场景详细分析，确定最好、最坏的情况);
确定场景的优先级(项目干系人对场景投票，根据投票结果确定优先级);
分配效用(对场景响应级别确定效用表，建立策略、场景、响应级别的表格);
形成"策略-场景-响应级别的对应关系";
确定期望的质量属性响应级别的效用(根据效用表确定所对应的具体场景的效用表);
计算各架构策略的总收益；
根据受成本限制影响的投资报酬率选择架构策略(估算成本，用上一步的收益减去成本，得出收益，并选择收益最高的架构策略)。

其他评估方法:

SAEM方法
SAABNet方法
SACMM方法
SASAM方法
ALRRA方法
AHP(层次分析法)方法
COSMIC+UML方法

中间件技术

中间件是一种独立的系统软件或服务程序，可以帮助分布式应用软件在不同的技术之间共享资源。

中间件特点:

负责客户机与服务器之间的连接和通信，以及客户机与应用层之间的高效率通信机制
提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。
提供多层架构的应用开发和运行的平台，以及应用开发框架，支持模块化的应用开发。
屏蔽硬件、操作系统、网络和数据库的差异。
提供应用的负载均衡和高可用性、安全机制与管理功能，以及交易管理机制，保证交易的一致性。
提供一组通用的服务去执行不同的功能，避免重复的工作和使应用之间可以协作。

按照中间件在分布式系统中承担的职责不同，可以划分以下几类中间件产品:

通信处理(消息)中间件
事务处理(交易)中间件
数据存取管理中间件
Web服务器中间件
安全中间件
跨平台和架构的中间件
专用平台中间件
网络中间件

软件构件:构件又称为组件，是一个自包容、可复用的程序集。构件是一个程序集，或者说是一组程序的集合。构件的两个最重要的特性是自包容与可重用。

构件组装模型的一般开发过程：设计构件组装、建立构件库、构建应用软件、测试与发布。

商用构件标准规范-CORBA(公共对象请求代理体系结构)主要分为3个层次：对象请求代理、公共对象服务和公共设施。

最底层的对象请求代理(ORB)规定了分布对象的定义(接口)和语言映射，实现对象间的通信和互操作，是分布对象系统中的"软总线";
在ORB之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务(交易)服务、安全服务等各种各样的服务；
最上层的公共设施则定义了构件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。

COREACCM构件模型是OMG组织制定的一个用于开发和配置分布式应用的服务器端构件模型规范，它主要包括如下3项内容。

抽象构件模型：用以描述服务器端构件结构及构件间互操作的结构。
构件容器结构：用以提供通用的构件运行和管理环境，并支持对安全、事务、持久状态等系统服务的集成。
构件的配置和打包规范：CCM使用打包技术来管理构件的二进制、多语言版本的可执行代码和配置信息，井制定了构件包的具体内容和文档内容标准。

对象管理组织(OMG)基于CORBA基础设施定义了四种构件标准:

实体(Entity)构件需要长期持久化并主要用于事务性行为，由容器管理其持久化。
加工(Process)构件同样需要容器管理其持久化，但没有客户端可访问的主键。
会话(Session)构件不需要容器管理其持久化，其状态信息必须由构件自己管理。
服务(Service)构件是无状态的。

CORBA对象可看作是一个具有对象标识、对象接口及对象实现的抽象实体。之所以称为抽象的，是因为并没有硬性规定CORBA对象的实现机制一个CORBA对象的引用又称可互操作的对象引用(InteroperableObjectReference)。从客户程序的角度看，IOR中包含了对象的标识、接口类型及其他信息以查找对象实现。

对象标识(ObjectID)是一个用于在POA中标识一个CORBA对象的字符串。它既可由程序员指派，也可由对象适配器自动分配，这两种方式都要求对象标识在创建它的对象适配器中必须具有唯一性。

POA(便携式对象适配器)是对象实现与ORB其它组件之间的中介，支持由Objectld标识的对象的名称空间，它将客户请求传送到伺服对象，按需创建子POA,提供管理伺服对象的策略。

伺服对象(servant)是指具体程序设计语言的对象或实体，通常存在于一个服务程序进程之中。客户程序通过对象引用发出的请求经过ORB担当中介角色，转换为对特定的伺服对象的调用。在一个CORBA对象的生命期中，它可能与多个伺服对象相关联，因而对该对象的请求可能被发送到不同的伺服对象。