软考 - 系统架构设计师（软件架构设计）

架构的定义

软件架构仍在不断发展中，还没有形成一个统一的、公认的定义，这里仅举出几个较为权威的定义。

软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式的约束组成。
软件架构是指一个系统的基础知识，它具体体现在：系统的构件，构件之间、构件与环境之间的关系，以及指导其设计和演化的原则上。（IEEE1471-2000）

从技术角度看，软件架构的重要性：
1. 项目关系人之间交流的平台
2. 早期设计决策。从软件生命周期来看，软件架构是所开发系统的最早设计决策的体现。
  表现为：（1）架构明确了对系统实现的约束条件；（2）架构影响着系统的质量属性；（3）架构可以用来预测系统的质量；（4）架构为维护的决策提供依据；（5）架构有助于原型开发。
3. 在较高层面上实现软件复用
4. 架构对开发的指导与规范意义不容忽略

基于架构的软件开发模型则明确地把整个软件过程划分为：架构需求、设计、文档化、评审（评估）、实现、演化等 6 个子过程。

架构的模型

最常用的是结构模型和动态模型。

结构模型。这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接件和其他概念来刻画结构，并力图通过结构来反应系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是架构描述语言。
框架模型。框架模型于结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应问题的机构。
动态模型。动态模型是对结构或框架模型的补充，研究系统“大颗粒”的行为性质。例如，描述系统的重新配置和演化。动态可能指系统总体结构的配置、建立或查出通信通道或计算的过程。
过程模型。过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。
功能模型。该模型认为架构由一组功能构件按层次组成，且下层向上层提供服务。它可以看做是一种特殊的框架模型。

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

在这里插入图片描述

视图名称	功能	关注点	关注人员
逻辑视图	主要支撑系统的功能需求	描述系统功能	用户
开发视图（模块视图、实现视图）	主要侧重于软件模块的组织和管理	描述系统配置、装配	编程人员
进程视图	侧重于系统的运行特性，一些非功能性的需求	描述系统性能、吞吐	系统集成人员
物理视图	主要考虑如何把软件映射到硬件上	描述系统安装、拓扑结构、通信等	系统工程师
场景视图（用例视图）	使四个视图有机得联系起来	描述人机互动的系统行为	分析人员和测试人员

在这里插入图片描述

软件质量属性

案例分析常考

属性	子属性	作用及要点	应对策略
性能		效率指标：处理任务所需时间或单位时间内的处理量	增加计算资源、减少计算开销、引入并发机制、资源调度
可靠性	容错	出现错误后仍能保证系统正常运行，且自行修正错误	主动冗余
可靠性	健壮性	错误不对系统产生影响，按既定程序忽略错误	主动冗余
可用性		正常运行时间比例	心跳、Ping/Echo、主动冗余、被动冗余、选举
安全性		系统向合法用户提供服务并组织非法用户的能力	侵入检测、用户认证、用户授权、追踪审计、限制访问
可修改性	可维护性	局部修复故障对架构的负面影响最小化	软件模块泛化、限制模块之间通信、使用中介和延迟绑定、运行时注册、接口实现分离、信息隐蔽
	可拓展性	因松散耦合更易实现新特性/功能，不影响架构
	结构重组	不影响主体进行的灵活配置
	可移植性	适用于多样的环境（硬件平台、语言、操作系统）
功能性		需求的满足程度	构建协作
可变性		总体架构可变	预先定义规则，作为相关产品基础
互操作性		通过可视化或接口方式提供更好的交互操作体验	交互作用
可测试性		软件发现故障并隔离，定位其故障的能力特性	记录回放

软件架构风格

这部分内容比较多，我又总结了另一篇文章
软考-系统架构设计师（软件架构风格）

层次系统架构风格

二层C/S架构

提出的原因：C/S架构是基于资源不对等，且为实现共享而提出来的

结构：C/S结构将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与客户的交互任务。

优点：C/S软件架构具有强大的数据操作和事物处理能力，模型思想简单，易与人们理解和接受。

局限：（1）二层C/S结构为单一服务器且以局域网为中心，所以难以扩展至大型企业广域网或Internet；
            （2）软、硬件的组合及集成能力有限；
            （3）服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏；
            （4）数据安全性不好。

三层C/S架构

结构：将应用功能分成表示层、功能层和数据层三个部分

表示层：是应用的用户接口部分，它负担着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，并显示应用输出的数据。在变更用户接口时，只需修改显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。
功能层：相当于应用的本体，它是将具体的业务处理逻辑编入程序中。而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交互要尽可能简洁。
数据层：就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此，一般从功能层传送到数据层的要求大都使用 SQL 语言。

在这里插入图片描述

解决方案：对这三层进行明确分割，并在逻辑上使其独立。原来的数据层作为数据库管理系统已经独立出来，所以，关键是要将表示层和功能层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。一般情况下是只将表示层配置在客户机中，如果将功能层也放在客户机中，与二层 C/S 结构相比，其程序的可维护性要好得多，但是其他问题并未得到解决。客户机的负荷太重，其业务处理所需的数据要从服务器传给客户机，所以系统的性能容易变差。如果将功能层和数据层分别放在不同的服务器中，则服务器和服务器之间也要进行数据传送。但是，由于在这种形态中三层是分别放在各自不同的硬件系统上，所以灵活性很高，能够适应客户机数目的增加和处理负荷的变动。

B/S 架构风格

使用技术：B/S 结构主要是利用不断成熟的 WWW 浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原本需要复杂的专用软件才能实现的强大功能，并节约了开发成本。

在这里插入图片描述

优点：基于 B/S 架构的软件，系统安装、修改和维护全在服务器端解决（零客户端），很容易在运行时自动升级。也可以更加充分利用网络上的各种资源，同时应用程序维护的工作量也大大减少。

不足：（1）B/S 架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；
（2）采用 B/S 架构的应用架构，在数据查询等响应速度上，要远远地低于 C/S 架构；
（3）B/S 架构的数据提交一般以页面为单位，数据的动态交互性不抢，不利于在线事务处理（OnLine Transaction Processing，简称 OLTP ）应用。

MVC架构风格

定义：全名是 Model ViewController，是模型（model）- 视图（view）- 控制器（controller）的缩写，分层架构的一种。

分工协作：

Model 是对应用状态和业务功能的封装。Model 接受 Controller 的请求并完成响应的业务处理，在状态改变的时候向 View 发出相应的通知。
View 实现可视化界面的呈现并捕捉最终用户的交互操作（例如鼠标和键盘的操作）。
Controller 会根据需要控制原 View 或者创建新的 View 对用户交互操作予以响应。View 捕获到用户交互操作后直接转发给 Controller，后者完成相应的 UI 逻辑。如果需要涉及业务功能的调用，Controller 会直接调用 Model。

在这里插入图片描述

MVP架构风格

定义：全称为 Model-View-Presenter。MVP 是从MVC 演变而来。

与MVC的相同点：基本思想有相通的地方：Model 提供数据，View 负责显示，Controller/Presenter 负责逻辑的处理。

与MVC的不同点：MVC模式中元素之间“混乱”的交互主要体现在允许 View 和 Model 直接进行“交流”，这在MVP 中是不允许的。在 MVP 中 View 并不直接使用 Model，它们之间的通信是通过 Presenter （MVC中的Controller）来进行的，所有的交互都发生在Presenter 内部，而在 MVC 中 View 会直接从 Model 中读取数据而不是通过 Controller。

缺点：由于对视图的渲染放在了 Presenter 中，所以视图和 Presenter 的交互会过于频繁。还有一点需要明白，如果 Presenter 过多的渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么 Presenter 也需要变更了。

优点：（1）模型与视图完全分离，我们可以修改视图而不影响模型；
           （2）可以更高效的使用模型，因为所有的交互都发生在一个地方——Presenter 内部。
           （3）我们可以将一个 Presenter 用于多个视图，而不需要改变 Presenter 的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
           （4）如果我们把逻辑放在 Presenter 中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。

面向服务的架构（SOA）

典型的定义：（1）W3C 的定义：SOA 是一种应用程度架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。
（2）Service-architecture.com 的定义：服务是精确定义、封装完善、独立于其他服务所处环境和状态的函数。SOA 本质上是服务的集合，服务之间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进行连接。
（3）Gartner 的定义： SOA 是一种 C/S 架构的软件设计方法，应用由服务和服务使用者组成，SOA 于大多数通用的 C/S 架构模型不同之处，在于它着重强调构件的松散耦合，并使用独立的标准接口。

**概述：**SOA是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。由于 SOA 考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。

在这里插入图片描述
服务的基本结构：

在这里插入图片描述

SOA 设计原则：

明确定义的接口
自包含和模块化
粗粒度
松耦合
互操作性、兼容和策略声明

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

SOA 的关键技术：这些技术都是以 XML 为基础而发展起来的。

UDDI	统一描述、发现和集成	数据模型；API；注册服务
WSDL	Web 服务描述语言	服务实现定义包含：服务、端口；服务接口定义包含：绑定、端口类型、消息、类型
SOAP	简单对象访问协议	定义了服务请求和服务提供者之间的消息传输规范。SOAP包含：封装、编码规则、RPC表示、绑定。SOAP消息包含：封装（信封）、SOAP 头、SOAP体。
REST	表述性状态转移	是一种只使用 HTTP 和 XML 进行基于 Web 通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。

SOA 的实现方法：

Web Service

在这里插入图片描述

服务注册表

（1）服务注册
（2）服务位置
（3）服务绑定

企业服务总线（ESB）

内容：ESB 提供了一种基础设施，消除了服务请求者与服务提供者之间的直接连接，使得服务请求者和服务提供者进一步解耦。EJB 是由中间件技术实现并支持 SOA 的一组基础架构，是传统中间件技术于 XML、Web Service 等技术结合的产物，是在整个企业集成架构下的面向服务的企业应用集成机制。

功能：（1）支持异构环境中的服务、消息和基于事件的交互，并且具有适当的服务级别和可管理性；（2）通过使用 ESB ，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使现有系统具有全新的服务接口，并能够在部署环境中支持任何标准；（3）充当缓冲的 ESB 与服务逻辑相分离，从而使不同的系统可以同时使用同一个服务，不用在系统或数据发生变化时，改动服务代码；（4）在更高的层次，ESB 还提供诸如服务代理和协议转换等功能；（5）头攻可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息到不同的目的地。

优势：（1）扩展的、基于标准的连接；（2）灵活的、服务导向的应用组合；（3）提高复用率，降低成本；（4）减少市场反应时间，提高生产率。

微服务

优势：（1）技术异构性；（2）弹性；（3）扩展；（4）简化部署；（5）与组织结构相匹配；（6）可组合型；（7）对可替代性的优化

挑战：（1）分布式系统的复杂度；（2）运维成本；（3）部署自动化；（4）DevOps 与组织结构；（5）服务间依赖测试；（6）服务间依赖管理

微服务与 SOA ：
在这里插入图片描述

架构设计

在这里插入图片描述

软件架构文档化

内容：一是过程，编档过程能促使架构设计师进一步思考，使得架构更加完善；二是结果，描述架构的文档将作为架构开发的成功，供项目关系人使用。

架构文档的使用者：架构的项目关系人。编写技术文档最基本的原则之一是要从读者的角度来编写。

编档规则：

从读者的角度编写文档
避免出现不必要的重复
避免歧义
使用标准结构
记录基本原理
使文档保持更新，但更新频率不要过高
针对目标的适应性对文档进行评审

视图编档：

在这里插入图片描述

软件架构评估

方法：

基于调查问卷或检查表的方式（依赖于评估人员的主观推断）
基于场景的方式：应用在架构权衡分析法（ATAM）和软件架构分析方法（SAAM）中。它是通过分析软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
基于度量的方式：建立在软件架构度量的基础上

架构权衡分析法（ATAM）

步骤：

ATAM 方法的表述：评估负责人向参加会议的项目代表介绍 ATAM
商业动机的表述
架构的表述
对架构方法进行分类
生成质量属性效用树
分析架构方法
集体讨论并确定场景的优先级
分析架构方法
结果的表述

分析得到的信息：

已编写了文档的架构方法
经过讨论得到的场景集合及其优先级
效用树
所发现的有风险决策
已编成文档的无风险决策
所发现的敏感点和权衡点