【无标题】

第一章 软件体系结构概论

软件体系结构产生背景

1.随着软件的规模越来越大，越来复杂，整个系统的结构和规格说明就显得越来越重要

2.对于大规模的复杂系统来说，总体的结构设计和规格说明比算法和数据结构重要

3.软件都是有体系结构的，不存在没有体系结构的软件。

软件重用的定义

也称为软件复用，就是利用已开发的且对应用有贡献的软件元素来构建新软件系统。

软件重用类型

依据重用的对象分: 1.产品重用 2.过程重用

依据重用方法分:1.组合式重用 2.*生成式重用*

软件重用所应用的领域分:1.横向重用2.纵向重用

按技术形式分:1.知识重用 2.方法和标准重用 3.软件成分重用

软件成分重用

1.源代码的重用

2.目标代码级重用

3.设计和分析结果

4.类的重用

5.构件重用

软件体系结构主流的核心模型

体系结构的核心模型组成：构件、连接件、配置、端口和角色。

构件、连接件和配置是最基本的元素。

软件构件的定义

软件构件是将大而复杂的应用软件分解为一系列可先行实现,易于开发,理解重用和调整的软件单元

基于构件的软件开发思想

将用户需求分解为一系列的子功能构件在开发过程中不必重新设计这些基本的功能模块,只需从现有的构件库中寻找合适的构件来组装应用.

第二章 软件体系结构建模

什么是ADL? 广泛使用的ADL有哪些?

体系结构描述语言(ADL)

ACME、Unicon、Wright、Darwin、Aesop、SADL、MetaH、Rapide和C2

描述体结构的两种方法:

实践派:使用通用的建模符号。将软件体系结构设计与描述同传统的系统建模视为一体

实践派风格包括：图形表示方法、模块内连接语言、基于构件的系统描述语言和UML描述方法。

学院派:使用了体系结构描述语言(ADL)。

学院派风格:则侧重于软件体系结构形式化理论的研究。倡导使用体系结构描述语言来刻画软件的框架结构

ACME的基本特征

1.提供了基本的体系结构元素来描述系统的体系结构，并提供了相应的扩展机制。 ​ 2.提供了灵活的注解机制来描述系统的非结构性信息。 ​ 3.提供了可对软件体系结构风格进行重用的模板机制。 ​ 4.提供了一种开放的语义框架，可以对体系结构描述进行形式化推理。

UML与ADL之间的关系

1.体系结构描述语言ADL是一种描述体系结构模型的形式化工具。ADL用于软件系统体系结构建模，它提供了具体的语法与刻画体系结构的概念框架，使得系统开发者能够很好地描述他们设计的体系结构，以便与他人交流。 ​ 2.通过软件体系结构描述语言ADL，可以为各个角色提供一种形式化定义软件体系结构的方法，从而避免了自然语言与框图描述可能引起的理解上的不一致性，即所谓的二义性。 ​ 3.可以认为，ADL是研究软件体系结构规范的出发点，是软件体系结构的核心，是分析和验证软件体系结构的前提和基础。

Kruchten提出了“4+1”视图模型

从5个不同的视角来描述软件体系结构，这5个视角包括：逻辑视图、过程视图、开发视图、物理视图和场景视图。每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统框架结构的全部内容

视图模型

逻辑视图，也称概念视图。主要支持系统功能需求的抽象描述

开发视图，也称模块视图。主要侧重于描述系统的组织，根据系统模块的组织方式，可以有不同的形式

过程视图。主要侧重于描述系统的动态属性，即系统运行时的特性

物理视图。主要描述如何把软件映射到硬件上

场景视图。场景是用户需求和系统功能实例的抽象

基于体系结构的软件开发过程

通过对特定领域应用软件进行分析，提炼其中的稳定需求和易变需求，建立可重用的领域模型。根据用户需求和领域模型，产生应用系统的需求规格说明； ​ 在领域模型的基础上，提炼面向特定领域的软件体系结构。 在体系结构的框架指导下，把系统功能分解到相应的构件和连接件。 ​ 低层设计主要解决具体构件和连接件的设计问题，通过重用设计件库中存放的设计模式、对象和其他类型的可重用设计，或根据情况设计新的构件，并提炼入库。

第三章 软件体系结构风格

软件体系结构风格的定义

能够用来具体描述软件系统控制结构和整体组织的一种体系结构，能够表示系统的框架结构，用于从较高的层次上来描述各部分之间的关系和接口。

体系结构风格的分类：

数据流风格：批处理序列、管道/过滤器； ​ 仓库风格：数据库系统、超文本系统、黑板系统； ​ 独立构件风格：进程通迅、事件系统； ​ 调用/返回风格：主程序/子程序、面向对象风格、层次结构（面向对象的变种），C/S,B/S； ​ 虚拟机构格：解释器、基于规则的系统。

管道/过滤器 优点 1.使得软构件具有良好的隐蔽性和高内聚、低耦合的特点； 2.允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成； 3.支持软件重用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来 4.系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉允许对一些如吞吐量、死锁等属性的分析； 5.支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。 缺点 1.通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换； 2.不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重； 3.因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

数据抽象和面向对象组织 优点 1因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其它的对象； 2设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。 缺点 3为了使一个对象和另一个对象通过过程调用等进行交互,必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象; 4必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。例如，如果A使用了对象B,C也使用了对象B,那么,C对B的使用所造成的对A的影响可能是料想不到的。 基于事件的系统（隐式调用风格） 这种风格的主要特点是事件的触发者并不知道哪些构件会被哪些事件影响。

这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。

优点 1为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。 2为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其它构件的接口。 缺点 1构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被调用的顺序。 2数据交换的问题。有时数据可被一个事件传递，但另一些情况下基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下全局性能和资源管理便成了问题。 3既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。 分层系统 什么是层？层是一个具有相同属性的集合；

分层是理解问题的一种方法论，可以把复杂软件从大问题分为小问题，从视图的角度看可以降低问题复杂度。

优点 1支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解 2支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层； 3支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法 缺点 1并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来； 2很难找到一个合适的、正确的层次抽象方法。 仓库系统及知识库 在仓库（repository)风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行，仓库与外构件间的相互作用在系统中会有大的变化。

控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程执行的选择，则仓库是一传统型数据库；另外，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统。

黑板系统的传统应用是信号处理领域，如语音和模式识别，另一应用是松藕合代理数据共享存取。

黑板系统主要由三部分组成：

知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通信，它们之间的交互只通过黑板来完成。 黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题。 控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。 C2风格 C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：

1系统中的构件和连接件都有一个顶部和一个底部。 ​ 2构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的。 ​ 3一个连接件可以和任意数目的其他构件和连接件连接。 ​ 4当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。 特点 ​ 1系统中的构件可实现应用需求,并能将任意复杂度的功能封装在一起; ​ 2所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的; ​ 3构件相对独立,构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行,或某些构件共享特定控制线程之类的相关性假设。 二层C/S - 客户/服务器风格 ​ C/S软件体系结构是基于资源不对等，且为实现共享而提出来的，是20世纪90年代成熟起来的技术，C/S体系结构定义了工作站如何与服务器相连，以实现数据和应用分布到多个处理机上。

C/S体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。

前台主要是数据的显示和分析，完成与用户的交互，后台主要是数据的管理。

第四章 特定领域软件体系结构

DSSA 代表的是什么?

1DSSA就是在一个特定应用领域中为一组应用提供组织结构参考的标准软件框架

2DSSA是软件构件的集合，以标准结构组合而成，对于一种特殊类型的任务具有通用性，可以有效地、成功地用于新应用系统的构建

3DSSA是问题元素和解元素的样本，同时给出了问题元素和解元素之间的映射关系

DSSA具有的特征

是对整个领域适度的抽象； ​ 具有严格定义的问题域或解决方案域； ​ 具备该领域固有的、典型的在开发过程中可重用元素； ​ 具有普遍性，即可用于领域中某个特定应用的开发。

DSSA的定义及组成

1.一般而言，DSSA由可重用构件、参考需求工程、参考体系结构3个主要信息元素以及框架/环境支持工具、抽取和评估工具组成。 ​ 2.其中，领域模型是DSSA的关键部分，它描述了领域内系统需求上的共性。领域模型所描述的需求称为参考需求或领域需求，它是通过考察领域中已有系统的参考需求获得的。参考体系结构则是一个统一的、相关的、多级的软件体系结果规范。

DSSA包含两个过程，即领域工程和应用工程。

领域工程是为一组相近或相似的应用建立基本能力与必备基础的过程，它覆盖了建立可重用软件元素的所有活动。 ​ 应用工程是通过重用软件资源，以领域通用体系结构为框架，开发出满足用户需求的一系列应用软件的过程。

两个工程之间的关系

一方面，通过应用工程得到的现有系统(包括需求规约、设计、实现等)是领域工程的主要信息来源.领域工程的产品-领域模型、DSSA、可重用构件等，又对本领域中新系统的应用工程提供了支持。

另一方面，领域工程和应用工程需要解决一些相似的问题.领域工程的步骤、行为、产品等很多方面都可以和应用工程进行类比

领域工程的三个阶段及每个阶段的目标

领域分析是领域工程的第一个阶段，这个阶段的主要目标是产生领域模型

领域设计是领域工程的第二个阶段，此阶段的主要目标是针对领域分析阶段获得的对目标领域的问题域系统责任的认识，开发出相应的设计模型。

领域实现的主要目标是根据领域模型、DSSA来开发和组织可重用软件元素

第五章 Web Service 与SOA

Web Service定义

W3C将Web Services定义为：Web Services是为实现跨网络操作而设计的软件系统，提供了相关的操作接口，其他应用可以使用SOAP消息，以预先指定的方式来与Web Services进行交互。soap(简单对象访问协议)

Web Services建立在许多成熟的技术之上，以XML为基础，使用Web Services描述语言（WSDL）来表示服务，在注册中心上，通过统一描述、查找和集成协议（UDDI)对服务进行发布和查询。各个应用通过通用的Web协议和数据格式，例如HTTP、XML和简单对象访问协议（SOAP）来访问服务。

Web Service的目标

Web Services的目标是消除语言差异、平台差异、协议差异和数据结构差异，成为不同构件模型和异构系统之间的集成技术。

Web Service的优点

(1)良好的封装性、开放性、维护性和伸缩性。 ​ (2)高度的集成性、跨平台和语言独立性。 ​ (3)自描述和发现性以及协议通用性。 ​ (4)协约的规范性。 ​ (5)松散的耦合性。

Web Service体系结构模型(三种角色,三个操作);

Web Services体系结构模型描述了三种角色，包括服务提供者、服务注册中心和服务请求者，定义了三种操作，即查找服务、发布服务和绑定服务，同时给出了服务和服务描述两种操作对象.

1）发布服务：服务提供者定义了Web Service描述，在服务注册中心上发布这些服务描述信息。

2）查找服务：服务请求者使用查找服务操作从本地或服务注册中心搜索符合条件的Web Service描述，可以通过用户界面提交，也可以由其他Web Service发起。

3）绑定服务：一旦服务请求者发现合适的Web Service，将根据服务描述中的相关信息调用相关的服务。

web services 工作机制

Web Services主要采用可扩展标记语言XML、简单对象访问协议SOAP、Web Services描述语言WSDL、统一描述、查找和集成协议UDDI、Web Services流程语言WSFL以及业务流程执行语言BPEL等核心技术。

XML是Web Services进行数据交换时所采用的标准，同时也是Web Services技术的全部规范和技术基础。

SOA定义

(l)狭义上认为SOA主要是一种架构风格，是以基于服务、IT与业务对齐作为原则的IT架构方式。 ​ (2)广义上把SOA看作是包括了编程模型、运行环境和方法论等在内的一系列企业应用解决方案和企业环境，而不仅仅是一种架构风格。

SOA 优缺点

优点

(1)具有良好的平台无关性、可适应性和可扩展性。 ​ (2)技术与业务对齐，更好的集成效果、更好的定价和销售模式。 ​ (3)减少系统耦合，提高系统的复用粒度，降低开发成本。 ​ (4)使企业的信息化建设真正以业务为核心，业务人员根据需求编排服务，而不必考虑技术细节

缺点

(1)降低了系统的性能。 ​ (2)服务的划分和编排困难。 ​ (3)如果选择的接口标准有问题，会带来系统的额外开销，并因此而最终导致整个系统不稳定性的增加。 ​ (4)对IT硬件资源并没有重用。 ​ (5)目前主流实现方式接口很多，从而比较松散、脆弱。 ​ (6)目前主流实现方式只局限于不带界面的服务共享。从业务角度思考，能共享的应该不仅仅局限在服务层面。

web service 与 SOA 的关系

1,SOA不是Web Services，Web服务是技术规范，而SOA是设计原则； ​ 2,SOA本质上是一种将软件组织在一起的抽象概念，依赖于XML和Web Services等更加具体的实现技术； ​ 3,Web Services是SOA的一个特定实现。 ​ 4,Web Services是实现SOA的最好方式，但SOA的实现并不仅仅局限于Web Services

第六章 软件产品线技术

软件产品线的三大基本活动

核心资产开发和利用核心资产的产品开发，以及产品线开发的管理

核心资产开发

核心资产开发活动的目标是建立产品的生成能力

产品开发

成熟的产品线组织优先考虑整个产品线而不是个别产品的健壮性，但最终产品开发才是产品线的最终目标。

管理

管理对于产品线的成功至关重要，开发活动必须指定资源、协调和监督。

第七章 软件演化(X)

软件体系结构的演化、动态性、扩展的区别

软件体系结构的动态性：指软件系统在运行时刻的体系结构变动。

体系结构扩展：体系结构的静态修改

软件体系结构演化：由于系统的需求、技术、环境、分布等因素的变化，最终导致软件体系结构的变动；

什么是动态软件体系结构体现在哪3个方面?

（1）交互动态性，如允许在复合构件的固定连接中改变数据；

（2）结构化动态性，如允许对系统添加或删除构件或连接件；

（3）体系结构动态性，允许构件的整个配置发生改变；

对基于构建的动态结构模型的了解

又被称为CBDSAM，支持运行系统的动态更新，分为应用层、中间层和体系结构层三层。其中应用层处于最底层，包括构件连接、构件接口和执行；中间层包括连接件配置、构件配置、构建描述和执行；体系结构层位于最顶层，控制和管理整个体系结构，包括体系结构配置、体系结构描述和执行。

动态更新和局部更新和全局更新

CBDSAM的动态更新包括检测更新范围、更新准备工作、执行更新和存储更新，分为局部更新和全局更新。

局部更新只作用于需要更新的构件内部，不影响系统的其他部分；判断属于局部更新后，在执行更新前，需要进行局部更新的构件会发送信号以隔离自身的通信，执行更新后将再将断开的连接重新存储起来。在整个过程中不会影响其他部分的运行。

全局更新作用于需要更新的构件，仅影响更新所涉及的部分，不影响系统的其他部分。在判断属于全局更新后，体系结构配置器会对更新所涉及的连接件和构件发送更新准备信息，整个更新工作只在这些部分进行，不会影响系统的其他部分运行。

第八章 软件体系结构评估

软件体系结构评估的定义和目的

软件体系结构评估，是对系统的某些值得关心的属性(性能、可修改性、可靠性等)进行评价和判断。 ​ 评估的目的是为了识别体系结构设计中的潜在风险

软件体系结构的主要评估方式

1.基于问卷调查或检查表的软件体系结构评估方式

问卷调查是一系列可以应用到各种体系结构评估的相关问题，其中有些问题可能涉及到体系结构的设计决策；有些问题涉及到体系结 构的文档，比如体系结构的形式化描述采用何种技术；有的问题针对体系结构描述本身的一些细节问题，比如系统的核心功能是否与用 户界面分开。

2.基于场景的软件体系结构评估方式

基于场景的方式由SEI首先提出并应用在SAAM(基于场景的体系结构分析方法)和ATAM(体系结构权衡分析法)中， ​ 目前，很多体系结构评估方法都采用场景作为基本技术。 ​ 这些体系结构评估方法分析软件体系结构对场景，也就是对系统的使用或修改活动的支持程度，从而判断该体系结构对这一场景所代 表的质量需求的满足程度。

3.基于度量和预测的软件体系结构评估方式

度量是指对软件制品的某一属性所赋予的数值，例如，代码行数、方法调用层数、组件个数等

SAAM和ATAM的不同之处

SAAM的评估过程

SAAM（软件系统架构分析方法），它也是一种基于场景的评估方法，最早用于分析体系结构的可修改性，后来也用于其他质量属性的评估，主要包括如下6个步骤：

\1. 形成场景

\2. 描述体系结构

\3. 对场景进行分类和确定优先级

\4. 对间接场景进行单个评估

\5. 评估场景的相互作用

\6. 形成总体评价

1.形成场景

指的是风险承担者们集中在一起，集体讨论，提出一个个系统需求场景。记录人员把这些场景记录在册，形成文档的过程。

2.描述体系结构

指的是体现结构设计师，对待评估的体系结构进行适当的描述，包括静态属性和动态特征，可以用自然语言也可以用形式化手段，以让参加评估的所有人员都能充分理解。

这一步骤和上一个形成场景的步骤可以合并在一起，重复进行多次。

3.对场景进行分类和确定优先级

系统可分为直接场景和间接场景，直接场景指的是本体系结构可以直接支持的场景，即不需要对体系结构做任何修改即可直接实现。

另外一种间接场景则是需要对现有体系结构做些更改才能支持的场景。

最后用投票的方法，确定间接场景的重要性优先级，以便大家将有限的时间花在最重要的事情上。

4.对间接场景进行单个评估

就是将选出来的重要场景与体系结构描述对应起来。体系结构设计师具体说明体系结构需要做哪些修改变更才能适用间接场景的要求，并估计这些变更的代价。

最后形成一份全部场景的总结性列表。

列表字段包括：场景编号、场景描述、直接/间接、需要做的更改、更改/新增构件数量、更改工作量估计

5.评估场景的相互作用

当两个或多个间接场景需要修改到同一个构建时，这时场景就在这个构件上出现了相互作用，需要特别评估。

出现这种情况，往往是设计方案中功能分配不合理，或者是设计文档未能充分说明体系结构。

6.形成总体评价

最后，评估人员对场景和场景间的相互作用做一个总体的权衡和评价。通过各个场景权重与分值得出一个总体的评价，从多个体系结构，或者一个体系结构的不同设计方案选择出一个最优的方案。

SAAM 评估步骤

ATAM的评估过程

ATAM 评估方法包括4个部分，分为9个步骤： 1.表述，分三个步骤： 分别为：ATAM方法表述、商业动机表述、软件体系结构表述； 目的：重点强调该架构是怎样适应商业动机的。 2.调查分析，包括三个步骤 分别为：确定软件架构的方法、生成质量效用树、分析软件架构方法。 目的：确定架构上有风险决策、无风险决策、敏感点、权衡点等。 3.测试，包括两个步骤 分别为：集体讨论并确定场景的优先级、分析软件体系结构方法。 4.形成报告

ATAM的分析评估过程

重用的六种质量属性

可⽤性（Availability），可⽤性是指系统正常⼯作的时间所占的⽐例。可⽤性会遇到系统错误，恶意攻击，⾼负载等问题的影响。 ​ 可修改性（Modifiability），可修改性主要包含两⽅⾯，第⼀是修改什么（什么可以修改），第⼆个是何时以及由谁进⾏修改。 ​ 性能（Performance），性能与时间有关。事件发⽣时，系统必须对其作出响应。时间到达响应有很多特性，但性能基本上于事件发⽣时，将要消耗系统多长时间做出响应有关系。

安全性（Security），安全性是衡量系统在向合法⽤户提供服务的同时，阻⽌⾮法授权使⽤的能⼒。 ​ 可测试性（Testability），通过测试揭⽰软件缺陷的容易程度。 ​ 易⽤性（Usability），易⽤性关注的是对⽤户来说完成某个期望任务的容易程度和系统所提供的⽤户⽀持的种类。

简单质量属性效用树的生成

第十章 云计算

云计算的概念

如果把云视为一个虚拟化的存储与计算资源池，那么云计算就是该资源池基于网络平台为用户提供的数据存储和网络计算服务(软件体系结构理论及应用)

云计算服务的分类

将基础设施作为服务(Infrastructure as a Service，IaaS) 将云计算软件开发平台作为服务(Platform as a Service，PaaS) 将软件作为服务(Software as a Service，SaaS) 除此之外，基于云的数据作为服务(Data as a Service，DaaS)，通信作为服务(Communication as a Service，CaaS)等形式的更多的XaaS也在根据用户的需要不断应运而生

云计算的体系结构

1.云计算直到目前也没有一个统一的体系结构 ​ 2.给出一个综合并改进的云计算体系结构的分层：物理资源层、虚拟化资源池层、服务管理中间件层和SOA构建层

云计算的核心技术

1分布式海量数据存储技术 ​ 2分布式海量数据编程模型 ​ 3分布式海量数据的锁服务 ​ 4分布式海量数据管理技术