体系结构知识点复习

https://www.cnblogs.com/qixin/p/3163536.html

第一章

P3 软件危机(为什么要出现软件体系结构)

软件危机的表现

1. 随着软件产业的发展，软件成本日益增长
2. 开发进度难以控制。用户需求变化等情况令软件开发过程很难保证按预定的计划实现。
3. 软件质量差。开发带有主观性和随意性，产品不尽如人意。
4. 软件维护困难。

软件危机的成因

1. 用户需求不明确。

在软件开发过程中，用户需求不明确。问题主要体现在四个方面:

(1)在软件开发出来之前,用户自己也不清楚软件的具体需求。

(2)用户对软件需求的描述不精确,可能有遗漏、有二义性甚至有错误。

(3)在软件开发过程中用户还提出修改软件功能(function)、界面(interface).支撑环境(environment)等方面的要求。

(4)软件开发人员对用户需求的理解与用户本来的愿望有差异。

2. 缺乏正确的理论指导。缺乏有力的方法学和工具方面的支持。由于软件不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程,其产品极大程度地依赖于开发人员高度的智力投人。由于过分依靠程序设计人员在软件开发过程中的技巧和创造性，加剧了软件产品的个性化，也是导致软件危机的一个重要原因。
3. 软件规模越来越大。随着软件应用范围的增广，软件规模愈来愈大。大型软件项目需要组织一定的人力共同完成，而多数管理人员缺乏开发大型软件系统的经验，且多数软件开发人员又缺乏管理方面的经验。各类人员的信息交流不及时、不准确，有时还会产生误解。软件项目开发人员不能有效地、独立自主地处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误。
4. 软件复杂度越来越高。软件不仅仅是在规模上快速地发展扩大，而且其复杂性(complexity)也急刷增加。软件产品的特殊性和人类智力的局限性,导致人们无力处理“复杂问题”。所谓“复杂问题”的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前。

P20 解释什么是体系结构

软件体系结构的意义

1. 体系结构是风险承担者进行交流的手段。
2. 体系结构是早期设计决策的体现：

(1)软件体系结构明确了对系统实现的约束条件。
(2)软件体系结构决定了开发和维护组织的组织结构。
(3)软件体系结构制约着系统的质量属性。
(4)通过研究软件体系结构可能预测软件的质量。
(5)软件体系结构使推理和控制更改更简单。

3. 软件体系结构是可传递和可重用的模型。

第二章 体系结构的建模

P30 2.2 4+1模型

Kruchten 1995 4+1视图模型

逻辑视图、进程视图、物理视图、开发视图、场景视图

逻辑视图

在面向对象技术中，通过抽象、封装、和继承，可以用对象模型代表逻辑视图，用类图来描述逻辑视图。

逻辑视图中使用的符号集合：

在表示包含关系的图符中，带有实心圆的一端表示整体，相反的一端表示部分。在表示使用关系的图符中,带有空心圆的一端连接在请求服务的类，相反的一端连接在提供服务的类。在表示继承关系的图符中,箭头由子类指向基类。

逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要同题C持一个单一的、内聚的对象模型贯穿整个系统。例如，图2-3是某通信系统体系结构(AS中的主要类。

例子：

开发视图

开发视图(development view) 也称模块视图( module view), 主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织，这样，对于一一个软件系统，就可以由不同的人进行开发。开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。

开发视图通过系统输人输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发角度，也可以在确定每个元素之前，列出开发视图原则。

例子：

在开发视图设计中，最好采用4~6层子系统的层次结构风格，每个子系统仅仅能与同层或更低层的子系统通信。层次越低，通用性越强。

进程视图

进程视图(process view)侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程(thread)中被执行的。

进程视图可以描述成多层抽象，每个级别分别关注不同的方面。在最高层抽象中，进程结构可以看做是构成一个执行单元的一组任务。它可看成一系列独立的，通过逻辑网络相互通信的程序。它们是分布的,通过总线或局域网、广域网等硬件资源连接起来。通过进程视图可以从进程测量一个目标系统最终执行情况。

例子：

物理视图

物理视图(physical view)主要考慰如何把软件映射到硬件上，它通常要考虑系统性能。规模、可靠性等。解决系统拓扑结构、系统安装、通信等问题。当软件运行于不同的结点上时，各视图中的构件都直接或间接地对应于系统的不同结点上。因此,从软件到结点的映射要有较高的灵活性，当环境改变时,对系统其他视图的影响最小。

大型系统的物理视图可能会变得混乱，因此可以与进程视图的映射一起以多种形式出现，也可单独出现。图是物理视图的标记元素集合。

例子：

场景

场景(scenarios)可以看作是那些重要系统活动的抽象,它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。在开发体系结构时，它可以帮助设计者找到体系结构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图,或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。例如，图2-13是一一个小型ACS系统的场景片段。

P37 2.3 体系结构的核心模型：构建 连接件 配置 哪些角色

综合软件体系结构的概念,体系结构的核心模型由5种元素组成:构件、连接件、配置(configuration) 、端口(port)和角色(role)。其中构件、连接件和配置是最基本的元素。

1. 构件是具有某种功能的可重用的软件模板单元，表示系统中主要的计算元素和数据存储。构件有两种:复合构件和原子构件，复合构件由其他复合构件和原子构件通过连接而成;原子构件是不可再分的构件,底层由实现该构件的类组成，这种构件的划分提供了体系结构的分层表示能力，有助于简化体系结构的设计。

2. 连接件表示构件之间的交互，简单的连接件如:管道(pipe)、过程调用( procedurecall)、事件广播(event broadcast)等,更为复杂的交互如:客户-服务器(client-server)通信协议，数据库和应用之间的SQL连接等。

3. 配置表示构件和连接件的拓扑逻辑和约束。

另外，构件作为一个封装的实体，只能通过其接口与外部环境交互，构件的接口由一组端口组成，每个端口表示构件和外部环境的交互点。通过不同的端口类型，一个构件可以提供多重接口。一个端口可以非常简单，如过程调用，也可以表示更为复杂的界面(包含一些约束)，如必须以某种顺序调用的一.组过程调用。

连接件作为建模软件体系结构的主要实体，同样也有接口，连接件的接口由一组角色组成，连接件的每一个角色定义了该连接件表示的交互的参与者，二元连接件有两个角色，如; RPC的角色为caller 和callee,pipe的角色是reading和writing,消息传递连接件的角色是sender和receiver,有的连接件有多于两个的角色，如事件广播有一个事件发布者角色和任意多个事件接收者角色。

基于以上所述，我们可将软件体系结构的核心模型表示为图2-14所示。

第三章

P57 3.4 3层C/S 结构风格 分析题

2层C/S的弊端

1. 单一服务器且以局域网为中心，难以扩展至大型企业广域网或Internet。

2. 软硬件组合及集成能力有限。

3. 客户机负荷太重，难以管理，系统性能容易变坏。

4. 数据安全性不好。

3层C/S

相比2层增加了一个应用服务器，应用逻辑在服务器上客户端仅有表示层

1. 表示层

   表示层是应用的用户接口部分，担负着用户与应用间的对话功能，它用于检在用户从键盘等输人的数据，显示应用输出的数据。为使用户能直观地进行操作，一般要使用图形用户界面(graphic user interface GUI)。在变更用户界面时，只需改写显示控制和数据检查程序，而不能响其他两层。检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。

2. 功能层

   功能层相当于应用的本体，它是将具体的业务处理逻辑编入程序中。例如，在制作订购合同时要计算合同金额,按照定好的格式配置数据、打印订购合同，而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简洁。例如,用户检索数据时，要设法将有关检索要求的信息-次性地传送给功能层，而由功能层处理过的检索结果数据也一次性地传送给表示层。

   通常，在功能层中包含有确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能。功能层的程序多半是用可视化编程工具开发的，也有使用COBOL和C。

3. 数据层

   数据层就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。现在的主流是关系型数据库管理系统(RDBMS),因此，一般从功能层传送到数据层的要求大都使用SQL语言。

3层的特点

三层C/S的解决方案是:对这三层进行明确分割，并在逻辑上使其独立。原来的数据层作为数据库管理系统已经独立出来,所以，关键是要将表示层和功能层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。

一般情况是只将表示层配置在客户机中，如图3-10(1)或3- 10(2)所示。如果像图3-10(3)所示的那样连功能层也放在客户机中，与二层C/S体系结构相比，其程序的可维护性要好得多，但是其他问题并未得到解决。客户机的负荷太重,其业务处理所需的数据要从服务器传给客户机，所以系统的性能容易降低。

如果将功能层和数据层分别放在不同的服务器中，如图3-10(2)所示，则服务器和服务器之间也要进行数据传送。但是，由于在这种形态中三层是分别放在各自不同的硬件系统上的，所以灵活性很高，能够适应客户机数目的增加和处理负荷的变动。例如，在追加新业务处理时，可以相应增加装载功能层的服务器。因此，系统规模越大这种形态的优点就越显著。在三层C/S体系结构中中间件是最重要的构件。所谓中间件是一个用API定义的软件层，是具有强大通信能力和良好可扩展性的分布式软件管理框架。它的功能是在客户机和服务器或者服务器和服务器之间传送数据,实现客户机群和服务器群之间的通信。其工作流程是:

在客户机里的应用程序需要驻留网络上某个服务器的数据或服务时，搜索此数据的C/S应用程序需访向中间件系统。该系统将查找数据源或服务,并在发送应用程序请求后重新打包响应,将其传送回应用程序。

OOA面向对象的分析

1. 对象-类层：待开发系统的基本构造快
2. 属性层：对象所存储的数据称为对象的属性
3. 服务层：对象的服务加上对象实例之间的消息通信共同组成了OOA模型的服务层
4. 结构层：负责捕捉特定应用域的结构关系
5. 主题层：用于将对象归类到各个主题中，以简化OOA模型

OOD面向对象的设计

1. 问题论域部分
2. 人机交互部分
3. 任务管理部分
4. 数据管理部分

单机配置方案 单服务器配置方案 业务服务器配置方案 事务服务器配置方案

3层C/S结构的优点

①允许合理地划分三层结构的功能，使之在理相上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性。

②允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。清晰、合理地分测三层结构并使其独立，可以使系统构成的变更非常简单，因此，被分成三层的应用基本上不需要修正。

③三层C/S结构中，应用的各层可以并行开发，各层也可以选择各自最适合的开发语言。使之能并行地而且是高效地进行开发,达到较高的性能价格比；对每一层的处理逻辑的开发和维护也会更容易些。

④允许充分利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础;整个系统的管理层次也更加合理和可控制。

需要注意的问题

值得注意的是:三层C/S结构各层间的通信效率若不高，即使分配给各层的硬件能力很强,其作为整体来说也达不到所要求的性能。此外，设计时必须慎重考虑三层间的通信方法、通信频度及数据量。这和提高各层的独立性一样是三层C/S结构的关键问题。

P73 3.8 基于层次消息总线的体系结构风格 分析题

构件模型

构件接口

基于层次消息总线的体系结构风格（HMB）：

消息总线是连接件，构件之间通过消息总线进行通信。构件向消息总线登记感兴趣的消息（消息响应登记表）。消息总线根据接收到的消息类型和响应表，传递信息给相关构件并返回处理结果。

消息总线包括

1. 消息登记：构件向总线登记当前响应消息类型的集合，而不关心消息的发送者
2. 消息分派和传递：总线负责消息在构件之间传递，接收发送构件的消息，根据响应表分配到相关构件
3. 消息过滤：转换和阻塞两种方式。转换是换名机制（消息名可能不唯一）

HMB体系风格结构支持运行时的系统演化：

在动态删除和删除构件；
动态改变构件所响应的消息；
消息过滤

P79 3.9 异构结构风格 c/s b/s混合 分析题

为什么要使用异构结构

(1)从最根本上来说,不同的结构有不同的处理能力的强项和弱点，一个系统的体系结构应该根据实际需要进行选择，以解决实际问题。

(2)关于软件包、框架、通信以及其他一些体系结构上的问题，目前存在多种标准。即使在某段时间内某一种标准占统治地位,但变动最终是绝对的。

(3)实际工作中,我们总会遇到一些遗留下来的代码，它们仍有效用，但是却与新系统有某种程度上的不协调。然而在许多场合,将技术与经济综合进行考虑时，总是决定不再重写它们。

(4)即使在某一单位中，规定了共享共同的软件包或相互关系的一些标准，仍会存在解释或表示习惯上的不同。在UNIX中就可以发现这类问题:即使规定用单一的标准(ASCII)来保证过滤器之间的通信，但因为不同人对关于在ASCII流中信息如何表示的不同的假设,不同的过滤器之间仍可能不协调。

内外有别模型

企业内部采用C/S，内部用户通过局域网直接访问数据库服务器。外部用户通过Internet访问web服务器，间接访问数据库服务器，采用B/S

优点：外部用户不直接访问数据库，相对安全，内部用户交互性强，查询响应速度快。

缺点：外部用户修改和维护数据速度慢而繁琐，动态交互性不强。

查改有别模型

维护和修改操作使用C/S,查询和浏览使用B/S

体现了B/S C/S的共同优点，但数据不安全

第四章

P102 4.3 体系结构描述语言

P109 4.4.3 c2

C2构件有top和bottom两个端口，每个端口只能和一个C2连接件连接，C2连接件可以连接任意个C2构件。

请求消息只能通过top端口向上层传送，通知消息只能通过bottom端口向下层传送。

• P110 图4-2例题

P123 UML

P125 4.5.2 用例图，类图，对象图，顺序图，协作图，状态图，活动图，构件图，部署图

第五章

P153 5.2 软件体系结构动态模型

5.2.1 基于构件的动态系统结构模型

支持运行系统的动态更新，分为应用层、中间层和体系结构层

应用层处于最底层，包括构件连接，构件接口和执行

中间层包括连接件配置，构件配置，构件描述及执行

体系结构位于最上层，控制和管理整个体系结构，包括体系结构配置、体系结构描述和执行

每一层都有一个执行部分，主要是对相应层的操作进行执行

在更新执行之前需要确保：

1. 所涉及的构件停止发送新的请求
2. 在更新开始之前，连接件的请求队列中的请求全部已被执行

局部更新

1. （更新发起者）向构件A请求更新
2. 构件A告诉连接件，隔离自己的通信，准备更新
3. 执行更新
4. 重新连接至连接件
5. 返回更新结果

第六章

P171 6.1 什么是web服务

逻辑分层 每个层的功能 如何交互

通常,一个web服务可以分为五个逻辑层,分别为

数据层data layer
数据访问层data access layer
业务层business layer
业务面business facade
监听者listener

离客户端最近的是监听者,离客户端最远的是数据层。其中业务层又可分为两个子层,分别是业务逻辑(businesslogic)和业务面(businessfacade)。Web服务需要的任何物理数据都保存在数据层中。在数据层上的是数据访问层,数据访问层为业务层提供数据服务。数据访问层把业务逻辑从底层数据存储的改变中分离出来，这样就能保护数据的完整性。业务面提供一一个简单接口，直接映射到Web服务提供的过程。

业务面模块用来提供一一个到底层业务对象的可靠的接口，把客户端从底层业务逻辑的变化中分离出来。业务逻辑层提供业务面使用的服务。所有的业务逻辑都可以通过业务面在一个直接与数据访问层交互的简单Web服务中实现。Web 服务客户应用程序与Web服务监听者交互，监听者负责接收带有请求服务的输人消息，解析这些消息,并把这些请求发送给业务面的相应方法。

P173 6.2 web服务体系结构模型

web服务模型

一个完整的Web服务包括三种逻辑构件:服务提供者、服务代理和服务请求，如图6-1示各个构件分别对应不同的角色，服务提者提供服务，并进行注册以使服务可用;服务代理起中介作用，它是服务的注册场所，充当服务提供者和服务请求者之间的媒介;服务请求者可在应用程序中通过向服务代理请求服务,调用所需服务。

开发生命周期

Web服务开发生命周期包括设计和部署以及在运行时对服务代理、服务提供者和服务请求者每一一个角色的要求。每个角色对生命周期的每一元素都有特定要求。Web服务开发生命周期可分为构建、部署、运行和管理四个阶段，下面分别介绍。

(1)构建。构建阶段包括开发和测试Web服务的实现,定义服务接口描述和定义服务实现描述。可以通过创建新的Web服务，把现有的应用程序变成Web服务以及由其他Web服务和应用程序组成新的Web服务等方式来提供Web服务的实现。

(2)部署。部署阶段包括向服务请求者或服务注册中心发布服务接口和服务实现的定义，以及把Web服务的可执行文件部署到执行环境(典型情况下,是Web应用程序服务器)中。

(3)运行。在运行阶段，可以调用Web服务。这时，Web服务已完全部署,可操作,并且服务提供者可以通过网络访问服务。由此，服务请求者就可以进行查找和绑定操作。

(4)管理。管理阶段包括持续的管理和经营Web服务应用程序。在此阶段必须解决安全性、可用性、性能、服务质量和业务流程问题。

P174 web服务栈

1. 发现服务层
2. 描述服务层
3. 消息格式层
4. 编码格式层
5. 传输协议层

(1)发现服务层

发现服务层主要用来帮助客户端应用程序解析远程服务的位置，通过UDDI来实现，它是Web服务的信息注册规范。UDDI 规范描述了Web服务的概念，同时也定义了一种编程接口。

(2)描述服务层

描述服务层为客户端应用程序提供正确地与远程服务交互的描述信息，主要通过WSDL来实现。WSDL为服务提供者提供以XML格式描述Web服务请求的标准格式。

(3)消息格式层

消息格式层主要用来保证客户端应用程序和服务器端在格式设置上保持一一致,一般通过SOAP协议来实现。SOAP定义了服务请求者和服务提供者之间的消息传输规范。SOAP用XML来格式化消息,用HTTP来承载消息。

(4)编码格式层

编码格式层主要为客户端和服务器之间提供一个标准的、独立于平台的数据交换编码格式，一般通过XML来实现。XML是一种元语言，可以用来定义和描述结构化数据。

(5)传输协议层

传输协议层主要为客户端和服务器之间提供交互的网络通信协议，一般通过超文本协议(hypertext transfer protocol,HTTP)和简单邮件传输协议(simple mail transportprotocol,SMTP)来实现。