架构的定义

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

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

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

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

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

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

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

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

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

架构的模型

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

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

“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 设计原则：

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

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

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

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

SOA 的实现方法：

1. Web Service

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
• 商业动机的表述
• 架构的表述
• 对架构方法进行分类
• 生成质量属性效用树
• 分析架构方法
• 集体讨论并确定场景的优先级
• 分析架构方法
• 结果的表述

分析得到的信息：

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

首先明确应用架构的定义，从百度百科上即可了解到何为应用架构：

应用架构（Application Architecture）是描述了IT系统功能和技术实现的内容。应用架构分为以下两个不同的层次：

• 企业级的应用架构：企业层面的应用架构起到了统一规划、承上启下的作用，向上承接了企业战略发展方向和业务模式，向下规划和指导企业各个IT系统的定位和功能。在企业架构中，应用架构是最重要和工作量最大的部分，他包括了企业的应用架构蓝图、架构标准/原则、系统的边界和定义、系统间的关联关系等方面的内容。
• 单个系统的应用架构：在开发或设计单一IT系统时，设计系统的主要模块和功能点，系统技术实现是从前端展示到业务处理逻辑，到后台数据是如何架构的。这方面的工作一般属于项目组，而不是企业架构的范畴，不过各个系统的架构设计需要遵循企业总体应用架构原则。

简而言之，应用架构图分为两类，一类为多系统应用架构，用来分层次说明不同系统间的业务逻辑关系、信息流、系统边界等等。一类为单系统应用架构，用来分层次说明系统主要组成模块和功能点之间的业务逻辑关系。
从应用架构图的描述方式或岗位角度而言，又分为系统功能性架构图（或叫业务架构图）和系统技术层次架构图（或叫技术架构图）。两者的差异如下：

架构图类型	适用岗位	定位
业务架构图	产品经理	①帮助产品经理基于对企业业务系统生态有全局掌握的情况下参与制定业务决策。 ②帮助产品经理梳理新增系统在企业应用生态中的定位以及和其他系统之间的关系
技术架构图	技术人员	帮助技术人员搭建良好的技术规范和编码大纲

一般而言，由于现互联网公司产品经理越来越聚焦于功能设计和业务决策，而技术人员则越来越聚焦于技术设计。所以对于产品经理而言，架构图的运用则侧重在业务架构图上，技术架构图则由技术经理负责。当然产品经理如果也有技术背景，有能力理解技术架构图则更好。
下面分别引用网上大神所做的架构图例子来说明何为业务架构图，何为技术架构图。

技术架构图

由上图可见，技术架构图的特点在于用技术语言来描述系统的七个层级。

业务架构图

业务架构图可以按多系统业务架构图和单系统业务架构图进行说明。

多系统业务架构图

 

由上图可见，业务架构图是从业务逻辑的视角出发，为产品经理整齐地展现出一个企业各类系统之间的层次和关系。在产品大神杨堃的《深度｜从一个故事说起，谈谈企业应用架构的演变史》一文中，形象地为我们描述了业务架构图从无到有的过程，非常值得各位产品人学习的。下面就根据大神的经验说一下自己对业务架构图的理解。
业务架构图按照层次结构可以分为经典的三层结构：展现层、业务逻辑层和数据层，而上图作者在该基础上又分别对展现层和业务逻辑层做了细分。在上图的基础上其实还可以加上一层运维层来说明系统所需要的硬件条件。对于单个系统的架构图而言尤其重要。

一级层次	二级层次	说明
展现层	前端	面对外部客户的客户端、Web官网、公众号、小程序等
	后台	面对内部人员的后台系统
业务逻辑层	业务单元支持系统	主要指可以在同一企业的不同子系统中复用的支持同类业务的单元系统
	职能单元支持系统	主要指企业职能部门使用到的OA、邮箱等系统。一般中小企业这块都是相对比较独立的。比较难嵌合进其他业务系统体系中。
	基础架构支持系统	基础业务逻辑，包括账号体系、鉴权授权体系、定位、短信、支付等等
数据层	数据仓库	负责打通各系统之后的全部数据存储和处理
运维层	运维层	主要指企业各系统的硬件环境

使用多系统应用架构图还有一个好处在于，每当有新增的子系统时，可以提前预判是否需要共用哪些单元或者业务逻辑。例如是否用同一套账户体系，这对产品前期开发至关重要。

单系统业务架构图

对于一个从0到1的项目而言，产品经理除了要了解这个项目在整个企业应用架构中的定位，还要对整个系统的模块和功能有着清晰的分层次设计和了解。所以产品经理就不仅需要多系统业务架构图，也需要单系统业务架构图。

 

单系统应用架构图

 

由上图可以看出，单系统应用架构图分层可以和多系统应用架构图一致。但是每个层次里面的说明单元就变成功能模块，而非子系统。

应用架构图看起来和具体功能设计没太大关系，但心中存在这一张图时，可以从整个大局去设计系统，做好提前布局，避免后期出现巨坑。

作者：SanCode
链接：https://www.jianshu.com/p/9389301b0bc8
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

2021年准备参加软考获取高级职业技术资格认证的小伙伴咱们约起吧？！

今年刚参加完系分考试，不知道有没有通过，但感觉应该差不多，这里给自己点个赞！自软考系列文章发表之后有很多准备参加软考的小伙伴加我微信，关注我的微博，也有很多因此成了好朋友，甚至是同事。自前年开始，我会在CSDN、简书、GITHUB等平台将我在工作、学习的道路上遇到的各种问题都写成一篇技术博客，因为这样既能给日后查找资料方便，也能进一步提高自己的文档编写能力，还能广交朋友，拓展人脉，何乐而不为呢。当然也希望大家能和我一样，把自己在学习中的问题写成博客放在网上，既锻炼了自己又方便了他人。

软考，说实话除了系统分析师和架构师，其它都是不难的，都是很基础的。很多大公司都对此不屑一顾，但它任然是检验你个人自学能力及拥有相关工作能力的一个证明，况且在很多国有企事业单位都是直接和评职称相关的，在很多城市也是直接和落户积分相关的，所以无论从哪种角度考虑，考一个软考证书都是值得的，总比你刷抖音玩吃鸡强吧！

1. 软考是什么？为什么要考？

• What?
  软考，即计算机技术与软件专业技术资格(水平)考试。由国家人力资源和社会保障部(原人事部)、工业和信息化部(原信息产业部)领导的国家级考试，其目的是，科学、公正地对全国计算机与软件专业技术人员进行职业资格、专业技术资格认定和专业技术水平测试。该考试分为5个专业类别，并在各专业类别中分设了初、中、高级专业资格考试，囊括了共27个资格的考核。
  

• Why?
  软考证书还是非常有用的，特别是在IT行业。

1. 证书是大家求职的敲门砖。当然，软考的科目比较多，如果要考的话，建议大家还是先考初级或中级的专业或工作相关的，例如最近较火的[嵌入式系统设计师]，再考中级的系统集成项目管理工程师，最后考高级的信息系统项目管理师，这3个企业最认可。
2. 拿证是一方面，通过考试，学习，也可以系统进行提升，所学的内容，还是自己最受益的。
3. 软考的考试跟职称有关系，现在IT行业，凭职称的话，一定要通过软考的认证的。有很多同学考软考也是因为职称，要申请居住证，户口等都会参加软考。

2. 报名条件和资格设置

• 软考的报名条件并不多，根据《计算机技术与软件专业技术资格考试暂行规定》第八条相关规定：凡遵守中华人民共和国宪法和各项法律，恪守职业道德，具有一定计算机技术应用能力的人员，均可根据本人情况，报名参加相应专业类别、级别的考试。
• 因此，软考报名不设学历与资历条件、年龄以及专业等限制，符合以上条件的考生均可以报考。
• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YjmRi3Jr-1605192563502)(C:\Users\liang\AppData\Roaming\Typora\typora-user-images\image-20201112201441229.png)]

3. 报名时间和考试时间

• 一般来说，计算机技术与软件专业技术资格(水平)考试每年集中举行两次，上半年于5月21、22日左右举行，下半年于11月12、13日左右举行。软考架构师每年只安排一次考试，考试时间通常安排在下半年。

4. 报名入口

• 不同地区的报名入口可能有所不同，有些地区的报名入口为全国软考办官网：中国计算机技术职业资格网；有些地区报名入口则是当地软考办官网。
• 通过中国计算机技术职业资格网报名的考生，于规定时间内进入中国计算机技术职业资格网，点击报名入口，进入全国计算机技术与软件专业技术资格（水平）考试网上报名平台，选择对应的地区，即可进行报名。如果是在当地软考办官网报名，请大家按照当地软考办公布的报名流程进行。

1. 浏览器打开“中国计算机技术职业资格网”首页：
   
2. 在软考官网主页点击【报名入口】，进入下图所示页面：
   
3. 滚动【机构名称】菜单栏，选择自己所在省市点击【进入】开始报名：
   

5. 报名费用

• 软考报名费用是根据当地相关政策或物价水平等因素决定的，因此每年各地区软考报名收费标准可能有所不同，具体请大家关注当地2020软考报名通知，以通知中公布的报名费用为准。

以上海为例，根据往年上海软考报名收费标准来看，预计2021年架构师报名费用：考试报名费每人10元，考务费每科60元。

• 考生在报名后请于规定时间内及时缴费，以免错过缴费时间而影响报名。

6. 报考流程及考生须知

考生须知：

一、本次考试报名采用网上报名、网上缴费的方式进行。考生完成网上缴费后，方可视为报名成功。

二、根据人力资源社会保障部2020年专业技术人员职业资格考试工作计划（调整）要求，原计划于今年上半年举行的考试科目与下 半年考试科目合并于11月7、8日举行，考生只能选择一个资格报考。
考生网上报名时，本人应牢记报名序号，正确输入报考信息，上传电子照片（考生必须预先下载并使用报名系统指定的“照片审核处理工具”，上传经该工具审核处理并保存后的本人近期彩色白底半身免冠正面证件电子照， JPG格式，原始照片文件大于30K，大于295*413像素，照片清晰，通过审核的照片才能正常上传，否则无法完成注册和报名。严禁小照片放大后使用。），电子照片供考生参加考试和制作合格证书使用，请考生务必按要求上传照片。
考生根据自身实际情况在网上报名时选择一个咨询点，此咨询点为提供考试报名咨询等服务的地点（非考试地点），咨询点选定后不得更改。
考生可通过报名系统缴费平台支持的，已经开通网上支付功能的银行卡或电子扫码支付工具完成网上缴费。网上缴费咨询电话： 95070。

三、考生缴费后应再次查询本人报考信息和缴费状态（网上缴费信息和银行卡扣款信息），确认本人符合报考条件、报考信息无误（特别注意级别、专业和科目务必准确）、缴费成功，并打印报名表备用。网上付费确认后不再办理退考。
由于网络传输速度等不确定因素，缴费确认信息可能会相对滞后，但一般不会超过24小时，请考生不要急于重复支付划款，同时建议考生不要同时开启多个缴费页面进行支付，以免发生错账。

四、考试报名实行告知承诺制。考生报名时应对网上提交的报考信息和相关材料负责。对提交信息不实、伪造报名资料等以不正当手段获取考试资格的，以及考试期间违纪违规的，将按照相关考试违纪违规行为处理规定和《上海市公共信用信息归集和使用管理办法》的规定，给予取消考试成绩、记入考试诚信档案库、向社会公布、将失信情况记入上海市公共信用信息服务平台等严肃处理，由此造成的一切后果责任自负。

五、考试结束后还将采用技术手段进行雷同答卷的甄别和认定，对认定为雷同答卷的，按规定给予成绩无效处理，涉及违纪作弊的按相关条款追加处理。考生有义务妥善保护好自己的考试试卷和答题信息、不被他人抄袭，若有答卷雷同，双方均取消考试成绩。

六、报名成功的考生应按规定时限通过报名网站（www.ruankao.org.cn或www.rsj.sh.gov.cn/spta.shtml）下载并打印准考证，准考证下载打印时间为2020年11月3日10:00－11月5日16:00，逾期视为放弃考试。

7. 合格分数线

• 软考的合格标准是由国家人事部和信息产业部在每次考试结束后发文确定，根据全国考生考试成绩的综合水平统一划线，每年的合格分数线并不是固定的。其合格标准控制在一定的比例内，每个级别资格考试的各科目均及格才算合格，且单科及格的成绩不予保留，不能转到下次考试时使用。

• 根据近几年合格标准来看，架构师及格分数线预计各科目仍为45分，具体请大家以全国软考办公布的2020下半年软考合格标准为准。

8. 考试安排

软考高级系统架构设计师包含三个考试科目：综合知识、案例分析和论文。综合知识安排在上午考试，其它两科安排在下午考试。

9. 考试要求

考试合格人员应该能根据系统需求规格说明书，结合应用邻域和技术发展的实际情况，考虑有关约束条件，设计正确、合理的软件架构，确保系统架构具有良好的特性；能够对项目的系统架构进行描述、分析、设计与评估；能够按照相关标准编写相应的设计文档；能够与系统分析师、项目管理师相互协作、配合工作；具有高级工程师的实际工作能力和业务水平。

1) 考试内容：

• 掌握计算机硬软件与网络的基础知识；
• 熟悉信息系统开发过程；
• 理解信息系统开发标准、常用信息技术标准；
• 熟悉主流的中间件和应用服务器平台；
• 掌握软件系统建模、系统架构设计基本技术；
• 熟悉掌握信息技术安全、安全策略、安全管理知识；
• 了解信息化、信息技术有关法律、法规的基础知识；
• 了解用户的行业特点，并根据行业特点架构合适的系统设计；
• 掌握英语数学的基础知识
• 数学阅读和正确理解相关领域的英文文献。

3)考试科目

（1）信息系统综合知识，考试时间为150分钟，笔试，选择题；

（2）系统架构设计案例分析，考试时间为90分钟，笔试，问答题；

（3）系统架构设计论文，考试时间为120分钟，笔试，论文题。

10. 考试难度

• 系统架构师考试目标主要是按照要求分析用户的需求和约束条件，指导制订企业的战略数据规划，组织开发信息系统，具有高级工程师的实际工作能力和业务水平。由于架构师本身属于技术类考试，因此相对于软考中级其他管理类的考试资格来说会更具难度。首先对于考试大纲中的要求以及各科目考试的知识点要进行充分理解、掌握透彻，一方面第一场考试为客观选择题，因此可能会考到一些理论上的知识，另一方面第二场和第三场考试为主观问答题，需要综合运用相关知识及工作实践经验对案例进行分析与回答，特别是论文题需要利用自己曾经的项目，综合题目方向进行系统全面客观的分析论述，所以这就不仅需要懂得把理论与实际相结合，进行系统与全面的回答，更要掌握一般学术性论文的书写原则和方法，这样才能争取拿到高分。

• 由于每个考生的知识基础不同，因此对于不同考生来说系统分析师的考试难度也会不一样。对于一些有相关知识基础和工作经历的考生来说可能学习起来效率会更高，但通过考试依然不会感觉轻松，因为综合历年数据来看，系分的通过率不超过20%。而对于零基础的考生来说，更是望而却步，也正因如此，系统分析师的含金量还是相当高的。

11. 参考教程

• 2021年系统架构设计师考试官方指定的教材为**《系统架构设计师教程》**，由杨春晖主编，根据2009版大纲编写。

• 2021年系统架构设计师考试官方指定的大纲为**《系统分析师考试大纲》**，由清华大学出版社出版，2006年出版，2013年6月再版。

• 2021年系统架构设计师考试官方指定的教材为**《系统架构设计师考试全程指导》**，由杨春晖主编，清华大学出版社出版，2009年出版，2010年6月再版。

• 12. 复习资料（重点）

  全部复习资料共分为备考阶段一、备考阶段二和参考资料三大块。前者主要是官方教程和学习笔记，阶段二主要是历年真题和一些专题讲座。由于平台限制，我不过多展开说，有意者可以加我某信（用户名是DarkBirds）向我索要。

  • 历年真题解析：通过对近20年真题的详细分析，彻底掌握软考架构师出题规律和题目难以程度，并再不断做题过程中通过查阅教程，加深知识点印象，对所涉及的各知识点再一次巩固提高！
  • 系统架构师重点技术介绍：通过重点学习分析常考主题，串起来领域综合知识，为做好案例分析题打下理论基础。
  • 论文写作指导：通过业内口碑较好的希赛网内部论文写作培训课课件，掌握撰写小论文的套路、方法和技巧；精选了150余篇高质量论文，帮你打开各方面论文写作方向和思路；提供论文方格纸打印版，模拟真实考场环境，锻炼和熟悉写作论文你需要花的时间。（PS：我就是因为平时基本不用笔，结果考试中写作字迹潦草、高估自己写字速度，造成论文失分较多。）
  • 考前模拟题20套：复习到这一步，估计离考试也不远了。为了测试自己复习的到底怎样，我们提供了20套模拟题供你测试用。当然你也可以分阶段测试，就和高考的一模、二模那样。
    

---

获取更多知识，请点击关注：
嵌入式Linux&ARM
CSDN博客
简书博客
知乎专栏

---