个人总结，仅供参考，欢迎加好友一起讨论

文章目录

系分&架构 - 软件架构设计
考点摘要
概念
架构的 4 + 1 视图
软件架构风格
- 经典五大架构风格
- - 调用/返回风格
  - 独立构件风格
  - 虚拟机风格
  - 仓库风格
- 层次架构风格
- - 二层C/S架构
  - 三层C/S架构
  - B/S架构
  - 混合架构风格
- 闭环控制架构（过程控制）
- C2架构风格
- 富互联网RIA架构
- MVC架构风格
- MVP架构风格
- MVVM架构风格
软件架构风格 - 相关题目
基于/面向服务的（SOA）
- SOA特点
- SOA的实现方式 - Web Service
- SOA的实现方式 - 服务注册表
- SOA的实现方式 - 企业服务总线ESB
- SOA的关键技术
微服务
- 与单体架构的对比
- 特点与缺点
- 微服务与SOA的对比
模型驱动MDA
形式化语言ADL
特定领域软件架构DSSA
- 基本活动
- 领域分析机制
- 建立过程
- 三层次模型
基于架构的软件开发方法ABSD
- ABSD的开发模型（ABSDM）
- ABSD的开发过程
软件架构质量属性
- 性能
- 可用性
- 安全性
- 可修改性
- 易用性
- 可测试性
软件架构评估
- 评估方法
- 基于场景 - 软件架构分析法SAAM
- 基于场景 - 架构权衡分析法ATAM
- 质量属性效用树
软件产品线
- 过程模型 - 双生命周期模型
- 过程模型 - 三生命周期模型
- 过程模型 - SEI模型
- 建立方式
- 组织结构
构件
- 构件的复用
- 构件的组装
- 构件的标准
中间件
- 6个基本功能
- 类型和分类
- 应用服务器

系分&架构 - 软件架构设计

考点摘要

软件架构的概念（★★★）
软件架构风格（★★★★★）
架构描述语言ADL（★★★）
特定领域软件架构（★★★）
基于架构的软件开发（★★★★）
软件质量属性（★★★★★）
软件架构评估（★★★★★）
软件产品线（★★★）
构件与中间件技术（★★★★）
Web架构设计（★★★★）

概念

软件架构 = 软件体系结构

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

架构的本质

软件架构为软件系统提供了一个结构、行为和属性的高级抽象。
软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束。

架构的作用

软件架构是项目干系人进行交流的手段。
软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。
软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。

例题1：

例题1解析与答案：

答案：D

解析：软件架构与用户对系统的功能性需求没有直接的对应关系

架构的 4 + 1 视图

Kruchten在1995年提出了一个“4+1”的视图模型。“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件架构的全部内容。

逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统，且描述对象模型和对象之间的关系。
开发视图：也称为模块视图，主要侧重于软件模块的组织和管理。开发视图通过系统输入输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发角度，也可以在确定每个元素之前，列出开发视图原则。
进程视图：也称为过程视图。侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的主要抽象的进程结构。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。
物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。
场景：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。在开发架构时，它可以帮助设计者找到架构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。

逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。

例题2：

例题2解析与答案：

答案：A D C

解析：略

软件架构风格

架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统。
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。

经典五大架构风格

五大架构风格	子风格
数据流风格	批处理、管道-过滤器
调用/返回风格	主程序/子程序、面向对象、层次结构
独立构件风格	进程通信、事件驱动系统（隐式调用）
虚拟机风格	解释器、规则系统
仓库风格	数据库系统、黑板系统、超文本系统

### 数据流风格

批处理序列
批处理风格的每一步处理都是独立的，并且每一步是顺序执行的。数据必须是完整的，以整体的方式传递。
管道/过滤器
在管道/过滤器风格的软件架构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。

调用/返回风格

主程序/子程序
主程序/子程序风格是结构化开发时期的经典架构风格。这种风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。
面向对象风格
这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。
层次结构风格
层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见

独立构件风格

进程通信
构件是独立的过程，连接件是消息传递，构件通常是命名过程，消息传递的方式可以是点对点，异步或者同步的方式，以及远程过程方法调用等。
事件驱动的系统
构件不直接调用一个过程，而是触发或广播一个或多个事件。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用（implicit invocation）来实现的。基于事件的隐式调用风格的主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便，其缺点是构件放弃了对系统计算的控制。

虚拟机风格

解释器
解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。
基于规则的系统
基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。

仓库风格

数据库系统
数据库系统是仓库风格最常见的形式。在数据库系统中，构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。
黑板系统
黑板系统包括知识源、黑板和控制三个部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中，例如，信号处理、问题规划和编译器优化等。
超文本系统
超文本系统中出现的构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。

层次架构风格

二层C/S架构

客户机/服务器（Client/Server，C/S）架构是基于资源不对等，且为实现共享而提出来的，是20世纪90年代成熟起来的技术，C/S架构定义了工作站（客户应用程序）如何与服务器相连，以实现数据和应用分布到多台计算机上。服务器负责有效地管理系统的资源，其主要任务集中于对DBMS的管理和控制，以及数据的备份与恢复；客户应用程序的主要任务是提供用户与数据库交互的界面，向服务器提交用户请求并接收来自服务器的信息，对存在于客户端的数据执行应用逻辑要求。这是一种“胖客户机（fat client）、瘦服务器（thin server）”的架构，其处理流程如下图：

其主要特点：

开发成本较高
客户端程序设计复杂
信息内容和形式单一
用户界面风格不一
软件移植困难
软件维护和升级困难
新技术不能轻易应用

三层C/S架构

与二层C/S架构相比，在三层C/S架构中，增加了一个应用服务器。可以将整个应用逻辑驻留在应用服务器上，而只有表示层存在于客户机上。这种客户机称为瘦客户机（thin client）。三层C/S架构将应用系统分成表示层、功能层和数据层三个部分，如下图：

表示层

表示层是系统的用户接口部分，担负着用户与系统之间的对话功能。它用于检查用户从键盘等输入的数据，显示输出的数据。
功能层

功能层也称为业务逻辑层，是将具体的业务处理逻辑编入程序中。例如，在制作订购合同时要计算合同金额、按照预定的格式配置数据、打印订购合同，而处理所需的数据则要从表示层或数据层取得。
数据层

数据层相当于二层C/S架构中的服务器，负责对DBMS的管理和控制。

B/S架构

在B/S架构中，除了数据库服务器外，应用程序以网页形式存放于Web服务器上，用户运行某个应用程序时，只须在客户端的浏览器中键入相应的网址，调用Web服务器上的应用程序，并对数据库进行操作，完成相应的数据处理工作，最后将结果通过浏览器显示给用户。基于B/S架构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。

另外，B/S架构也有一些缺点存在：

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

混合架构风格

闭环控制架构（过程控制）

C2架构风格

富互联网RIA架构

为了弥补B/S架构存在的一些不足，提高用户体验，富互联网应用（Rich Internet Application，RIA）技术应运而生。

富互联网架构的特点：

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

MVC架构风格

MVC架构，既是架构模式也是设计模式。

MVC分为主动和被动两种MVC模型。主动MVC有对模型的观察机制，会把数据主动返回到View。主动MVC能推送数据给视图，但被动模型是没有的。主动MVC就是引入了观察者模式来实现了向视图的推送信息。如下：

Model(模型）是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
View(视图）是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
Controller(控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

MVP架构风格

MVP的所有的操作都要经过Presenter。MVC中的C主要做事件的分发，并不做事件业务的处理。而P层可以处理业务逻辑。MVP比MVC更加容易进行工程化测试。

MVC和MVP的一个最大的区别就是View和Model是否有交互。所以MVP在耦合程度上是更加有优势的。

MVP是MVC的变种。

MVP实现了V与M之间的解耦，（V不直接使用M，修改V不会影响M）。

MVP更好的支持单元测试（业务逻辑在P中，可以脱离V来测试这些逻辑，可以将一个P用于多个V，而不需要改变P的逻辑）。

MVP中V要处理界面事件，业务逻辑在P中，MVC中界面事件由C处理。

MVVM架构风格

软件架构风格 - 相关题目

题目，给大类选大类，给小类选小类

问：Java程序可以做到“一次编写，到处运行”，从架构风格上看符合（）风格的特点。

答：虚拟机风格

问：在网络通信中，进行包的解析，一般先进行包头的分离，然后进行报文解析及后续处理，根据这一特点选用（）风格最合适。

答：解析数据，分层逐次操作，数据流风格

问：某公司欲开发一个基于图形用户界面的集成调试器。该调试器的编辑器和变量监视器可以设置调试断点。当调试器在断点处暂停运行时，编辑程序可以自动卷屏到断点，变量监视器刷新变量数值。针对这样的功能描述，采用（）的架构风格最为合适。

答：集成调试器，调试器中有多个部件，强调可设置断点，断点处都触发操作，独立构件风格中的事件驱动。

问：某游戏公司欲开发一个大型多人即时战略游戏，游戏设计的目标之一是能够支持玩家自行创建战役地图，定义游戏对象的行为和之间的关系。针对该目标，公司应该采用（）架构风格最为合适。（四选一：管道-过滤器、隐式调用、主程序-子程序、解释器）

答：支持自行创建，自定义规则，虚拟机风格的解释器

问：某公司承接了一个开发家用空调自动调温器的任务，调温器测量外部空气温度，根据设定的期望温度控制空调的开关。根据该需求，公司应采用（）架构风格最为合适。（四选一：解释器、过程控制、分层、管道-过滤器）

答：过程控制/闭环控制架构风格

问：某公司欲开发一个语音识别系统，语音识别的主要过程包括分割原始语音信号、识别音素、产生候选词、判定语法片断、提供语义解释等。每个过程都需要进行基于先验知识的条件判断并进行相应的识别动作。针对该系统的特点，采用（）架构风格最为合适。（四选一：解释器、面向对象、黑板、隐式调用）

答：语音识别，仓库风格中的黑板系统

问：某公司欲开发一个漫步者机器人，用来完成火星探测任务。机器人的控制者首先定义探测任务和任务之间的时序依赖性，机器人接受任务后，需要根据自身状态和外界环境进行动态调整，最终自动完成任务。针对这些需求，该机器人应该采用（）架构风格最为合适。（四选一：解释器、主程序-子程序、隐式调用、管道-过滤器）

答：有自定义的情况，虚拟机风格的解释器，隐式调用其实就是事件驱动，对应的显示调用（调用/返回风格）

问：Windows操作系统在图形用户界面处理方面采用的核心架构风格是（）风格。

答：图形用户界面，独立构件风格中的事件驱动

典型例题：

解析：

第一空，字眼“程序源代码作为整体，依次在不同模块中进行传递”，符合“顺序批处理”的特点。

第二空，字眼“支持代码的增量修改与处理”，又有“IDE”集成开发环境，符合仓库风格，仓库风格是以数据为中心的，所以这里选择“数据共享”。

第三空，字眼“触发”，符合独立构件风格中的事件驱动，也就是“隐式调用”。

第四空，设计模式的考察，设计模式和架构设计是相辅相成的，字眼“适应性改造”，选择“适配”。

第五空，字眼“模拟新操作系统”，符合“虚拟机”特点。

基于/面向服务的（SOA）

在SOA模型中，所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务通过服务总线或流程管理器来连接。这种松散耦合的架构使得各服务在交互过程中无需考虑双方的内部实现细节，以及部署在什么平台上。

服务接口：共同的封装，共同的语言格式，共同的安全和容错处理，其标准高度的统一。统一标准下产生的构件是可以通用的。服务相关的协议都是基于XML发展而来的。遗留系统的集成，信息孤岛的联通这些问题都可以使用SOA来应用。比如可以把遗留系统作为一个个的服务挂接到总线，这样就可以重复利用起来了。松散耦合，粗粒度和标准化的接口都是服务的特点。

SOA特点

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

SOA的实现方式 - Web Service

在Web Service（Web服务）的解决方案中，一共有三种工作角色，其中服务提供者和服务请求者是必须的，服务注册中心是一个可选的角色。它们之间的交互和操作构成了SOA的一种实现架构，如下图：

服务提供者

服务提供者是服务的所有者，该角色负责定义并实现服务，使用WSDL对服务进行详细、准确、规范的描述，并将该描述发布到服务注册中心，供服务请求者查找并绑定使用。
服务请求者

服务请求者是服务的使用者，虽然服务面向的是程序，但程序的最终使用者仍然是用户。从架构的角度看，服务请求者是查找、绑定并调用服务，或与服务进行交互的应用程序。服务请求者角色可以由浏览器来担当，由人或程序（例如，另外一个服务）来控制。
服务注册中心

服务注册中心是连接服务提供者和服务请求者的纽带，服务提供者在此发布他们的服务描述，而服务请求者在服务注册中心查找他们需要的服务。不过，在某些情况下，服务注册中心是整个模型中的可选角色。例如，如果使用静态绑定的服务，服务提供者则可以把描述直接发送给服务请求者。

SOA的实现方式 - 服务注册表

服务注册表（service registry）虽然也具有运行时的功能，但主要在SOA设计时使用。它提供一个策略执行点（Policy Enforcement Point，PEP），在这个点上，服务可以在SOA中注册，从而可以被发现和使用。服务注册表可以包括有关服务和相关构件的配置、依从性和约束文件。从理论上来说，任何帮助服务注册、发现和查找服务合约、元数据和策略的信息库、数据库、目录或其他节点都可以被认为是一个注册表。大多数商用服务注册产品支持服务注册、服务位置和服务绑定功能。

SOA的实现方式 - 企业服务总线ESB

企业服务总线是一个具有标准接口、实现了互连、通信、服务路由，支持实现SOA(Service Oriented Architecture，面向服务架构)的企业级信息系统基础平台。它提供消息驱动、事件驱动和文本导向的处理模式，支持基于内容的服务路由。SOA架构将各应用服务器(包括异构的服务器)上的各种服务连接到服务总线上，支持分布式的存储及分布式的处理、异步处理。为信息系统的真正松耦合提供了架构保障。简化了企业整个信息系统的复杂性，提高了信息系统架构的灵活性，降低企业内部信息共享的成本。

SOA的关键技术

功能	技术协议
发现服务	UDDI、DISCO
描述服务	WSDL、XML Schema
消息格式层	SOAP、REST
编码格式层	XML（DOM、SAX）
传输协议层	HTTP、TCP/IP、SMTP等

UDDI（Universal Description Discovery and Integration，统一描述、发现和集成）提供了一种服务发布、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它。UDDI规范描述了服务的概念，同时也定义了一种编程接口。通过UDDI提供的标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。

WSDL（Web Service Description Language，Web服务描述语言）是对服务进行描述的语言，它有一套基于XML的语法定义。WSDL描述的重点是服务，它包含服务实现定义和服务接口定义。

SOAP（Simple Object Access Protocol，简单对象访问协议）定义了服务请求者和服务提供者之间的消息传输规范。SOAP用XML来格式化消息，用HTTP来承载消息。通过SOAP，应用程序可以在网络中进行数据交换和远程过程调用（Remote Procedure Call，RPC）。

REST（Representational State Transfer，表述性状态转移）是一种只使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。它的简单性和缺少严格配置文件的特性，使它与SOAP很好地隔离开来。

微服务

首先，微服务也是属于面向服务的架构。

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的RESTfulAPI)。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

与单体架构的对比

特点与缺点

微服务的特点及优点：

小服务【且专注于做一件事情】
轻量级的通信机制
松耦合
独立测试
独立部署【简单部署】
独立运行【每个服务独立在其独立进程中】
支持异构【如每个服务使用不同数据库】
更好的可用性与弹性
化整为零，易于小团队开发

微服务的缺点与挑战：

分布式环境下的数据一致性【更复杂】
测试的复杂性【服务间依赖测试】
管理的多样性【服务间依赖管理】
运维的复杂性，运维成本增加
部署自动化
DevOps与组织结构

微服务与SOA的对比

微服务	SOA
团队级，自底向上开展实施	企业级，自顶向下开展实施
一个系统被拆分成多个服务，粒度细	服务由多个子系统组成，粒度大
无集中式总线，松散的服务架构	企业服务总线，集中式的服务架构
集成方式简单（HTTP/REST/JSON）	集成方式复杂（ESB/WS/SOAP）
服务能独立部署	单块架构系统，相互依赖，部署复杂

模型驱动MDA

MDA是Model Driven Architecture 的缩写，也叫模型驱动架构。起源于分离系统规约和平台实现的思想，MDA的主要目标是：Portability（可移植性），Interoperability（互通性），Reusability（可重用性）。

其中，M为Model，客观事物的抽象表示；Model-Driven，使用模型完成软件的分析、设计、构建、部署、维护等各开发活动；A是Architecture ，构成系统的部件、连接件及其约束的规约。

MDA的3种核心模型：

平台独立模型（PIM)【平台无关模型】：具有高抽象层次、独立于任何实现技术的模型。
平台相关模型（PSM)【平台相关模型】：为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。
代码（Code）：用源代码对系统的描述（规约）。每个PSM都将被变换成代码。

MDA是模型驱动架构，由OMG定义的一个软件开发框架，基于UML及其他工业标准。MDA把建模语言用作一种编程语言而不仅仅是设计语言，模型在软件开发中扮演了非常重要的角色。

形式化语言ADL

ADL（Architecture Description Language）是一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体化语法和概念框架。

ADL三个基本元素：

构件：计算或数据存储单元，包括构件和相应的构件接口
连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则
架构配置：描述体系结构的构件和连接件的连接图

ADL是建模用的，是一些伪代码

例题3：

例题3解析与答案：

答案：C

解析：略

特定领域软件架构DSSA

DSSA（Domain Specific Software Architecture）特定领域软件架构，可以看做开发产品线的一个方法或理论，目标就是支持一个特定领域中多应用的生成。

基本活动

建立领域模型，一个严格定义的问题域或解决域。其中，垂直域是在相同领域中深入；水平域是在不同领域中平移。
具有普遍性，使其可以用于领域中某个特定应用的开发。
对整个领域的合适程序的抽象。
具备该领域固定的、典型的在开发过程中的。可复用元素。

领域分析机制

建立过程

三层次模型

例题4：

例题4解析与答案：

答案：C C

解析：略

基于架构的软件开发方法ABSD

基于架构的软件设计（ABSD，Architecture-Based Software Design）是一种架构驱动方法，架构驱动也就是说架构先行，需求获取和分析还没有完成就开始架构设计，需求获取和分析与架构设计并行，例如产品线系统和长期运行的系统，我们不可能开始就能决定所有的需求。

ABSD强调由业务、质量和功能需求的组合驱动架构设计，强调采用视角和视图来描述软件架构，采用用例（功能需求）和质量场景（质量需求）来描述需求。

ABSD方法有三个基础：

第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。
第二个基础是通过选择架构风格来实现质量和业务需求。
第三个基础是软件模板的使用。

例题5：

例题5解析与答案：

答案：B C C

解析：略

ABSD的开发模型（ABSDM）

传统的软件开发过程是问题定义，需求分析，软件设计，实现，测试。ABSD把整个软件过程分成六个部分，架构需求，设计，文档化，复审，实现，演化六个步骤。

例题6：

例题6解析与答案：

答案：A A C

解析：略

ABSD的开发过程

软件架构质量属性

性能

性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

例如：

同时支持1000并发
响应时间小于1s
显示分辨率达到4K

可用性

可用性（availability）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。

例如：

主服务器故障，1分钟内切换至备用服务器
系统故障，1小时内修复
系统支持7×24小时工作

安全性

安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。

例如：

可抵御SQL注入攻击
对计算机的操作都有完整记录（日志，审计追踪）
用户信息数据库授权必须保证99.9%可用

可修改性

可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。

例如：

更改系统报表模块，必须在2人周内完成
对Web界面风格进行修改，修改必须在4人月内完成

易用性

易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。

例如：

界面友好
新用户学习使用系统时间不超过2小时

可测试性

软件可测试性是指通过测试揭示软件缺陷的容易程度。

例如：

提供远程调试接口，支持远程调试

例题7：

例题7解析与答案：

答案：A D A

解析：略

例题8：

例题8解析与答案：

答案：B C A C C D

解析：略

软件架构评估

架构评估的基准是架构质量属性，

敏感点是一个或多个构件（和/或构件之间的关系）的特性。

权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

风险点是指架构设计中潜在的、存在问题的架构决策所带来的隐患。

非风险点是指不会带来隐患，一般以“XXX要求是可以实现（或接受）的”方式表达。

例如：

对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计（敏感点）
假设每秒中用户交易请求的数量是10个，处理请求的时间为30毫秒，则“在1秒内完成用户的交易请求”这一要求是可以实现的（非风险点）
目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性（风险点）
更改加密的级别将对安全性和性能产生影响（权衡点）

例题9：

例题9解析与答案：

答案：D B

解析：略

评估方法

软件架构评估有三种方式：基于调查问卷（检查表），基于度量，基于场景。

基于调查问卷（检查表）：是指组织相关人员进行评估，这种方式最简单易行，但是主观性强。

基于度量：强调量化指标，最客观，但是这种方式实施难度大，因为需要评估者对系统非常熟悉，不然很难量化清楚各项指标。

基于场景：筛选出系统的关键场景，根据系统在不同场景中的表现进行评估，这种方式客观程度介于2者之间，这也是目前较为流行的结构评估方法。

基于场景的方式主要有三种（前2种方式用得比较多）：

软件架构分析法（SAAM，Software Architecture Analysis Method）
架构权衡分析法（ATAM，Architecture Tradeoff Analysis Method）
成本效益分析法（CBAM）

基于场景 - 软件架构分析法SAAM

SAAM，最初用于分析架构可修改性，后扩展到其它质量属性

软件架构分析法分为6个步骤：

形成场景
描述架构
对场景进行分类和确定优先级
对场景进行单个评估
评估场景的相互作用
形成总体评价

基于场景 - 架构权衡分析法ATAM

架构权衡分析法（ATAM，Architecture Tradeoff Analysis Method）是在SAAM上发展而来。核心是结合质量属性效用树对系统进行评价，确定风险点、敏感点、权衡点，并对系统架构做出决策和折中。整个评估过程强调以质量属性作为评估核心，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

ATAM分成4个阶段，如下图：

场景和需求收集
架构视图和场景实现
质量模型构造和分析
质量模型折中

例题10：

例题10解析与答案：

答案：D

解析：略

例题11：

例题11解析与答案：

答案：C C

解析：略

质量属性效用树

质量属性效用树：识别质量属性并排序，主要包含性能、可用性、可修改性、安全性四个方面。

性能：性能延时（将用户数据库存储延迟到了最小值300ms，提供了实时的视频图像），交易吞吐量（使认证服务器的平均吞吐量最大化）。

可修改性：新增产品目录，商业产品修改（已小于20人月的工作量添加CORBA中间件，以小于4人周的工作量更改web界面）。

可用性：硬件故障（若站点A断电，要求在3秒内将任务重定向到站点B，若磁盘出现故障，要求在5分钟内重新启动，要在1-5分钟之内检测并恢复网络故障），商业软件故障。

安全性：数据机密性（信用卡交易在99.999%的时间内是安全的，客户数据库z认证在99.999%的时间内能正常工作），数据完整性。

质量属性效用树示例图如下：

软件产品线

软件产品线主要由两部分组成，分别是核心资源和产品集合。核心资源是领域工程的所有结果的集合，是产品线中产品构造的基础。

软件产品线开发有4个基本技术特点，即过程驱动、特定领域、技术支持和架构为中心。与其它软件开发方法相比，组织选择软件产品线的宏观上的原因有：对产品线及其实现所需的专家知识领域的清楚界定；对产品线的长期远景进行了战略性规划。

组织选择软件产品线的原因：

对产品线及其实现所需要的知识领域的清楚界定。
对产品线的长期远景进行了战略性规划。

过程模型 - 双生命周期模型

双生命周期模型分成两个重叠的生命周期：领域工程和应用工程。

领域工程使用DSSA，主要任务有领域分析，领域设计，领域实现。

领域工程主要任务：

领域分析，利用现有系统的设计、架构和需求建立领域模型。
领域设计，用领域模型确定领域/产品线的共性和可变性，为产品线设计架构。
领域实现，基于领域架构开发领域可重用资源（构件、文档、代码生成器）。

应用工程领域：需求分析，系统设计，系统实现。

应用工程在领域工程结果基础上构造新产品：

需求分析，划分领域公共需求和独特需求，得出系统说明书。
系统设计，在领域架构基础上，结合系统独特需求设计应用的软件架构。
系统实现，按应用架构，用领域可重用资源实现领域公共需求，用定制开发的构件满足系统独特需求，构件新的系统。

过程模型 - 三生命周期模型

三生命周期模型为有多个产品线的大型企业增加企业工程流程，以便在企业范围内对所有资源的创建、设计和重用提供合理规划。

过程模型 - SEI模型

SEI模型基本活动分为三部分，分别是核心资源开发（即领域工程）、产品开发（即应用工程）和管理。

SEI模型的主要特点：

循环重复是产品开发过程的特征，也是核心资源开发、产品线开发以及核心资源和产品之间协作的特征。
核心资源开发和产品开发没有先后之分。
管理活动协调整个产品线开发过程的各个活动、对产品线的成败负责。
核心资源开发和产品开发是两个互动的过程，三个活动和整个产品线开发之间也是双向互动的。

核心资源开发活动的目标是建立产品线的生产能力。根据输入端的产品约束、框架、生产约束、生产策略和遗留资产清单，核心资产开发活动产出三项输出：

产品线范围。产品线范围是关于构成产品线的产品或产品线所能包括的产品的描述，该描述列举了所有产品的共性和他们之间彼此的差异，包括产品所提供的特征或操作、产品所表现出的性能和其他产品属性等。
核心资产：是产品线中产品生产的基础。这些资产包括产品共享的架构，以及为贯穿产品线进行系统化重用所开发的产品组件。提供了将纳入资产库的组件接口规范。
生产计划：描述了如何从核心资产中生产产品。

建立方式

划分依据：用演化方式和革命方式引入产品线开发过程，基于现有产品还是开发全新的产品线。

四种方式的基本特征如下：

	演化方式	革命方式
基于现有产品	基于现有产品架构设计产品线的架构，经演化现有构件,开发产品线构件	核心资源的开发基于现有产品集的需求和可预测的、将来需求的超集
全新产品线	产品线核心资源随产品新成员的需求而演化	开发满足所有预期产品线成员的需求的核心资源

组织结构

软件产品线开发过程分为领域工程和应用工程，相应的软件开发组织结构也应该有两个基本组成部分，即负责核心资源的小组和负责产品的小组。这也是产品线开发与独立系统开发的主要区别。

组织模型：开发部门、商务部门、领域工程部门和层次领域工程部门。

动态的组织结构，根据产品线的建立方式和发展阶段、成熟程度的变化，有一种组织结构向另一种组织结构演变。

组织结构类型：

设立独立的核心资源小组
不设立独立的核心资源小组
动态的组织结构

要成功实施产品线，主要取决于以下因素：

对该领域具备长期和深厚的经验
一个用于构建产品的好的核心资源库
好的产品线架构
好的管理（软件资源、人员组织、过程）支持

构件

定义1：软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。

定义2：构件是某系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某清晰的功能。

定义3：构件是一个独立发布的功能部分，可以通过其接口访问它的服务。

构件系统架构特性：

构件系统体系结构由一组平台决策、一组构件框架和构件框架之间的互操作设计组成。
构件框架是一种专用的体系结构（通常围绕一些关键的机制)，同时，也是一组固定地作用于构件层次机制的策略。
概念框架的互操作设计包括系统体系结构连接的所有框架间的互操作的规则。
构件是一组通常需要同时部署的原子构件。构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。
一个原子构件是一个模块和一组资源。
模块是一组类和可能的非面向对象的结构体，比如过程或者函数。
资源是一个类型化的项的固定集合。
资源这个概念可以包含代码资源，进而包含模块。问题在于除了编译器编译一个模块或包生成的资源外，还可能存在其他的资源。在“纯对象”的方法中，资源是外部化的不可改变的对象-―不可改变是因为构件没有持久化的标志，而且复制不能被区分。

构件的复用

软件复用（软件重用）是使用已有的软件产品（如设计、代码和文档等）来开发新的软件系统的过程。

复用的发展过程：

复用的维度：

水平复用，复用不同应用领域中的软件元素，如标准函数库
垂直复用，是在一类具有较多公共性的应用领域之间重用软件构件

例题12：

例题12解析与答案：

答案：B

解析：略

构件的组装

第一步，检索与提取构件

基于关键字的检索，特点：树形或有向无回路图结构。
刻面检索法，特点：利用Facet描述构件执行的功能、被操作的数据、构件应用的语境或任意其他特征。

例如，分多个刻面：1 应用领域、2 使用环境、3 功能
超文本检索法，特点：按照人类的联想思维方式任意跳转到包含相关概念或构件的文档。

第二步，理解与评价构件

要复用构件，准确地理解构件至关重要。特别是对构件修改使用时。
为达到目的,必须要求构件的开发过程遵循公共标准。
一般构件库的文档中全面而准确地说明以下内容：构件的功能与行为、相关的领域知识、可适应性约束条件与例外情形、可以预见的修改部分及修改方法。

第三步，修改构件

理想状态是直接复用构件库中现成的构件，但大多数情况下，必须对构件进行或多或少的修改，以应对新需求。
为了减少构件修改的工作量，要求开发人员尽量使构件的功能、行为和接口设计更为抽象化、通用化和参数化。这样，复用者即可通过对实参的选取来调整构件的功能或行为。如果这种调整仍不足以使构件适用于新系统，复用者就必须借助设计信息和文档来修改构件。
构件库中若无可修改使用的构件，则按新需求开发构件，并存入构件库。

第四步，组装构件

组装的三种方式：

基于功能的组装，采用子程序调用和参数传递的方式将构件组装起来。
基于数据的组装，仍然是传统的子程序调用与参数传递。但它所依赖的软件设计方法不再是功能分解,而是面向数据的设计方法，例如，Jackson系统开发方法。
面向对象的组装，如果从类库中检索出来的基类能够完全满足新系统的需求，则可以直接应用。否则,必须以基类为父类,生成相应的子类，以满足新系统的需求。

构件组装失配问题：

由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配。
由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配。
由于系统成分对全局体系结构的假设存在冲突引起的失配等。要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。

例题13：

例题13解析与答案：

答案：C

解析：略

构件的标准

构件标准规范包括OMG的CORBA、Sun的EJB/J2EE和微软的COM/DCOM/COM+。

COBRA

CORBA体系的主要内容包括以下几部分：

对象请求代理(Object Request Broker，ORB)。负责对象在分布环境中透明地收发请求和响应，它是构建分布对象应用、在异构或同构环境下实现应用间互操作的基础。
对象服务(Object Services)。为使用和实现对象而提供的基本对象集合，这些服务应独立于应用领域。
公共设施(Common Facilitites)。向终端用户提供一组共享服务接口，例如系统管理、组合文档和电子邮件等。
应用接口 (Application Interfaces)。由销售商提供的可控制其接口的产品，相应于传统的应用层表示,处于参考模型的最高层。
领域接口(Domain Interfaces)。为应用领域服务而提供的接口，如OMG组织为PDM系统制定的规范。

四种构件：

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

构件模型：

伺服对象（Servant）：CORBA对象的真正实现，负责完成客户端请求。
对象适配器（Object Adapter）：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。
对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。

EJB/J2EE

EJB是Sun的JavaEE服务器端组件模型，设计目标与核心应用是部署分布式应用程序。EJB (Enterprise JavaBean)是J2EE(javaEE)的一部分，定义了一个用于开发基于组件的企业多重应用程序的标准。EJB 构件用于封装业务逻辑，使开发人员无须再担心数据访问、事务处理支持、安全性、高速缓存和迸发等琐碎任务的编程。

支持的5种构件模型：Applet、Servlet、JSP、EJB、Application Client。

其中，EJB中的BEAN分三种：

会话bean，负责维护一个短暂的会话。
实体bean，负责维护一行稳固持久的数据。
消息驱动，异步接受消息。

COM/DCOM/COM+

COM+ ⊇ DCOM ⊇ COM

可以参考https://blog.csdn.net/lili40342/article/details/128586533

例题14：

例题14解析与答案：

答案：A

解析：略

中间件

中间件是一类构件，中间件是一类系统软件。

中间件，简化结构、屏蔽差异、利于复用。

采用中间件技术的优点：

面向需求。即设计师集中精力于业务逻辑本身。
业务的分隔和包容性。应用开发人员可以按照不同的业务进行功能的划分，体现为不同的接口或交互模式。
设计与实现隔离。构件对外发生作用或构件间的交互，都是通过接口进行的，构件使用者只需要知道构件的接口，而不必关心其内部实现，这是设计与实现分离的关键。
隔离复杂的系统资源。架构很重要的一个功能就是将系统资源与应用构件隔离，这是保证构件可复用甚至“即插即用”的基础，与中间件的意图也是一致的。
符合标准的交互模型。中间件则实现了架构的模型，实现了标准的协议。
软件复用。中间件提供了构件封装、交互规则、与环境的隔离等机制，这些都为软件复用提供了方便的解决方案。
提供对应用构件的管理。基于中间件的软件可以方便地进行管理，因为构件总可以通过标识机制进行划分。

中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于操作系统之上，管理计算资源和网络通信，实现应用之间的互操作。

6个基本功能

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

类型和分类

通信处理（消息）中间件。在分布式系统中，人们要建网和制定出通信协议，以保证系统能在不同平台之间通信，实现分布式系统中可靠的、高效的、实时的跨平台数据传输，这类中间件称为消息中间件，也是市面上销售额最大的中间件产品。目前主要产品有BEA的eLink、IBM的MQSeries、TongLINK等。实际上，一般的网络操作系统如Windows已包含了其部分功能。
事务处理（交易）中间件。在分布式事务处理系统中，经常要处理大量事务，特别是OLTP中，每项事务常常要多台服务器上的程序按顺序协调完成，一旦中间发生某种故障，不但要完成恢复工作，而且要自动切换系统，达到系统永不停机，实现高可靠性运行。要使大量事务在多台应用服务器上能实时并发运行，并进行负载平衡的调度，实现与昂贵的可靠性机和大型计算机系统同等的功能，为了实现这个目标，要求中间件系统具有监视和调度整个系统的功能。BEA的Tuxedo由此而著名，它成为增长率最高的厂商。
数据存取管理中间件。在分布式系统中，重要的数据都集中存放在数据服务器中，它们可以是关系型的、复合文档型、具有各种存放格式的多媒体型，或者是经过加密或压缩存放的，该中间件将为在网络上虚拟缓冲存取、格式转换、解压等带来方便。
Web服务器中间件。浏览器图形用户界面已成为公认规范，然而它的会话能力差、不擅长做数据写入、受HTTP协议的限制等，就必须进行修改和扩充，形成了Web服务器中间件，如SilverStream公司的产品。
安全中间件。一些军事、政府和商务部门上网的最大障碍是安全保密问题，而且不能使用国外提供的安全措施（如防火墙、加密、认证等），必须用国产产品。产生不安全因素是由操作系统引起的，但必须要用中间件去解决，以适应灵活多变的要求。
跨平台和架构的中间件。当前开发大型应用软件通常采用基于架构和构件技术，在分布式系统中，还需要集成各节点上的不同系统平台上的构件或新老版本的构件，由此产生了架构中间件。功能最强的是CORBA，可以跨任意平台，但是过于庞大；JavaBeans较灵活简单，很适合于做浏览器，但运行效率有待改善；COM+模型主要适合Windows平台，在桌面系统已广泛使用。由于国内新建系统多基于UNIX（包括Linux）和Windows，因此，针对这两个平台建立相应的中间件市场相对要大得多。
专用平台中间件。为特定应用领域设计领域参考模式，建立相应架构，配置相应的构件库和中间件，为应用服务器开发和运行特定领域的关键任务（如电子商务、网站等）。
网络中间件。它包括网管、接入、网络测试、虚拟社区、虚拟缓冲等。

应用服务器

目前，应用服务器已经成为电子商务应用中一种非常关键的中间件技术。通过它能将一个企业的商务活动安全有效地实施到Internet上，实现电子商务。它并非一种传统意义上的软件，而是一个可以提供通过Internet来实施电子商务的平台。在分布式、多层结构及基于构件和服务器端程序设计的企业级应用开发中，它提供的是一个开发、部署、运行和管理、维护的平台。它可以提供软件“集群” 的功能，因而可以让多个不同的、异构服务器协同工作、相互备份，以满足企业级应用所需要的可用性、高性能、可靠性和可伸缩性等。

故而，从某种意义上说，应用服务器提供了一个“企业级应用的操作系统”。实现 J2EE规范的应用服务器称为 J2EE 应用服务器。