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

架构的定义

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

1. 软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。

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

3. 软件架构是指一个系统的基础知识，它具体体现在：系统的构件，构件之间、构件与环境之间的关系，以及指导其设计和演化的原则上。（IEEE1471-2000）

   从技术角度看，软件架构的重要性：

   1. 项目关系人之间交流的平台

   2. 早期设计决策。从软件生命周期来看，软件架构是所开发系统的最早设计决策的体现。
      表现为： （1）架构明确了对系统实现的约束条件；（2）架构影响着系统的质量属性；（3）架构可以用来预测系统的质量；（4）架构为维护的决策提供依据；（5）架构有助于原型开发。

   3. 在较高层面上实现软件复用

   4. 架构对开发的指导与规范意义不容忽略

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

架构的模型

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

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

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

软件质量属性

案例分析常考

软件架构风格

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

层次系统架构风格

二层C/S架构

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

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

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

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

三层C/S架构

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

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

优点：基于 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。

2. 服务注册表

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

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 ：

软件架构文档化

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

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

编档规则：

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

视图编档：

软件架构评估

方法：

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

架构权衡分析法（ATAM）

步骤：

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

分析得到的信息：

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