软件架构师考试经验分享_软件架构师考试时间

像学写文章一样，在学会字、词、句之后，就应上升到段落，就应追求文章的“布局谋
篇”，这就是架构。通俗地讲，软件架构设计就是软件系统的“布局谋篇”。

人们在软件工程实践中，逐步认识到了软件架构的重要性，从而开辟了一个崭新的研究
领域。软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架
构评价和软件架构的形成方法等。

软件设计人员学习软件架构知识旨在站在较高的层面上整体地解决好软件的设计、复用、
质量和维护等方面的实际问题。
 

1、软件架构概述

1.1、软件架构的定义

（1）架构是对系统的抽象（2）架构由多个结构组成（3）任何软件都存在架构（4）元素及其行为的集合构成架构的内容（5）架构具有“基础”性（6）架构隐含有“决策”

1.2、软件架构的重要性

（1）项目关系人之间交流的平台（2）早期设计决策（3）在较高层面上实现软件复用（4）架构对开发的指导与规范意义不容忽略

从软件开发过程来看，如果采用传统的软件开发模型（生命周期模型），则软件架构的建
立应位于概要设计之前，需求分析之后。

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

1.3、 架构的模型

“4+1”视图模型

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

2、架构需求与软件质量属性

软件属性包括功能属性和质量属性，但是，软件架构（及软件架构设计师）重点关注的
是质量属性。因为，在大量的可能结构中，可以使用不同的结构来实现同样的功能性，即功能性在很大程度上是独立于结构的，架构设计师面临着决策（对结构的选择），而功能性所关心的是它如何与其他质量属性进行交互，以及它如何限制其他质量属性。

2.1 软件质量属性

2.2 6 个质量属性及实现

本节从架构关注点来研究质量属性实现，将质量属性分为 6 种：可用性、可修改性、
性能、安全性、可测试性、易用性。其他的质量属性一般可纳入这几个属性中（在其他文献
中为了强调常单列出来），例如，可扩充性可归入可修改性中（修改系统容量），可移植性也
可以作为平台的可修改性来获得。对于未能纳入的其他质量属性，可以用本章的方法进行研
究。

 3、软件架构风格

 软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式（ idiomaticparadigm）

4、层次系统架构风格

C/S 架构
B/S 架构
MVC 架构风格
MVP 架构风格	在 MVP 中 View 并不直接使用 Model，它们之间的通信是通过 Presenter （ MVC 中的 Controller）来进行的， 所有的交互都发生在 Presenter 内部，而在 MVC 中 View 会直接从 Model 中读取数据而不是通过 Controller。

 5、面向服务的架构

 （1） W3C 的定义： SOA 是一种应用程序架构，在这种架构中，所有功能都定义为独
立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成
业务流程。

（2） Service-architecture.com 的定义：服务是精确定义、封装完善、独立于其他服务
所处环境和状态的函数。 SOA 本质上是服务的集合，服务之间彼此通信，这种通信可能是
简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进
行连接。

（ 3） Gartner 的定义： SOA 是一种 C/S 架构的软件设计方法，应用由服务和服务使用
者组成， SOA 与大多数通用的 C/S 架构模型不同之处，在于它着重强调构件的松散耦合，
并使用独立的标准接口。

5.1、SOA 设计原则：

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

5.2、SOA 的关键技术

5.3、SOA 的实现方法

Web Service
企业服务总线	服务注册表（service registry）虽然也具有运行时的功能，但主要在 SOA 设计时使用。 它提供一个策略执行点（Policy Enforcement Point， PEP），在这个点上，服务可以在 SOA 中 注册，从而可以被发现和使用。
服务注册表	ESB 的概念是从 SOA 发展而来的，它是一种为进行连接服务提供的标准化的通信基础 结构，基于开放的标准，为应用提供了一个可靠的、可度量的和高度安全的环境，并可帮助 企业对业务流程进行设计和模拟，对每个业务流程实施控制和跟踪、分析并改进流程和性能。

 5.4、微服务

将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 协议的 RESTfulAPI）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。

微服务的优势

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

微服务面临的挑战

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

微服务与 SOA

 6、架构设计

通过架构模式，架构设计师可以借鉴和复用他人的经验，看看类似的问题别人是如何解
决的。但不要把模式看成是一个硬性的解决方法，它只是一种解决问题的思路。 Martin Fowler
曾说：“模式和业务构件的区别就在于模式会引发你的思考。”

6.1、演变交付生命周期

 6.2．属性驱动设计法

属性驱动设计法（Attribute-Driven Design， ADD）就是一种定义软件架构的方法，该方法将分解过程建立在软件必须满足的质量属性之上。 ADD 的输入为：功能需求（一般表示为用例）、限制条件和质量需求（一组特定于系统的质量场景）。

6.3．按架构组织开发团队

在架构的模块分解结构的最初几个层次相对稳定之后，就可以把这些模块分配给开发小组，其结果就是工作视图。
 

6.4．开发骨架系统

演变交付生命周期模型中有两个循环，第一个循环是通过迭代的方式开发出软件架构，第二个循环是在架构的基础上通过迭代的方式开发出交付的最终版本。开发骨架系统就是第二个循环的第一步。
 

6.5．利用商用构件进行开发

模式本来就是针对特定问题的解，因此，针对需求的特点，也可以选用相应的模式来设
计架构，并利用对应于该模式的商用构件进行软件开发。例如可以使用 J2EE/EJB 进行开发
面向对象的分布式系统。
 

7、软件架构文档化

记录软件架构的活动就是架构编档过程，也就是架构的文档化。它包含两个方面：一是过程，编档过程能促使架构设计师进一步思考，使得架构更加完善；二是结果，描述架构的文档将作为架构开发的成果，供项目关系人使用。

7.1．架构文档的使用者

架构文档的使用者是架构的项目关系人。编写技术文档（尤其是软件架构文档）最基本
的原则之一是要从读者的角度来编写，易于编写但很难阅读的文档是不受欢迎的。
 

7.2.软件编档（包括软件架构编档） 的规则

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

7.3．视图编档

（1）视图概述：对系统进行概括性的描述，包含视图的主要元素和元素间的关系（但并不包含所有元素和元素间的关系。

（2）元素目录：对主要表示中所描述的元素及其关系进行详细描述，包括：元素及其 属性、关系及其属性、元素接口、元素行为。

（3）上下文图：用图形展示系统如何与其环境相关。

（4）可变性指南：描述架构的可变化点，如在软件产品线中，产品线架构通过变化，适用于多个系统，因此，文档中应包含这些变化点，如各系统要做出选择的选项、做出选择的时间。

（5）架构背景：为架构的合理性提供足够的、令人信服的论据。包括：基本原理、分析结果及设计中所反映的假定。

（6）术语表：对文档中每个术语进行简要说明。

（7）其他信息：描述不属于架构方面的必要信息，如管理信息（创作者、配置控制数
据及变更历史）。

7.4．跨视图文档

软件架构由多个视图文档来反映，按前面所述的要求完成每个视图的文档后，需要对这
些文档进行一个整体的“打包”工作，这就是跨视图文档。它包括如下内容：
（1）文档有哪些内容，它们是如何组织的：视图目录（含哪些视图）；视图模板（即前
面描述的视图文档，企业可以通过规范化来定义统一的、公共的视图模板）。
（2）架构概述：它描述系统的目的、视图之间的关联、元素表及索引、项目词汇。
（3）为什么架构是这样的（基本原理）：跨视图基本原理解释了整体架构实际上是其需
求的一个解决方案。即解释了做出决策的原因、方案的限制、改变决策时的影响及意义。

7.5．使用 UML

UML 已经成为对软件架构进行文档化的事实上的标准表示法。在视图文档的组织结构
中， UML 主要用于表示元素或元素组的行为。

7.6．软件架构重构

1）信息提取（View Extraction）。可以使用各种工具进行信息提取，如解析器、语法
分析器等；可以利用 build 和 makefile 文件中关于模块的依赖关系；可以从源代码、编译
时制品和设计制品中提取静态信息；可以使用分析工具提取动态信息。
（2）数据库构造（Database Construction）：将提取的信息转化为标准的形式，并置于
数据库中。
（3）视图融合（View Fusion）：将数据库中的信息组合在一起，生成该架构的一个内聚
的视图。
（4）重构（Reconstruction）：构建数据抽象和各种表示以生成架构表示，主要由两个
活动组成：可视化和交互、模式定义和识别。最后生成需要的架构文档（Documentation）。
 

8、软件架构评估

软件架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它也可以
灵活地运用于对软件架构进行评审等工作中。

8.1 软件架构评估的方法

（1）基于调查问卷或检查表的方式：该方式的关键是要设计好问卷或检查表，它充分
利用系统相关人员的经验和知识，获得对架构的评估。其缺点是在很大程度上依赖于评估人
员的主观推断。
（ 2）基于场景的方式：基于场景的方式由 SEI 首先提出并应用在架构权衡分析法
（Architecture Tradeoff Analysis Method， ATAM）和软件架构分析方法（Software Architecture
Analysis Method， SAAM）中。它是通过分析软件架构对场景（也就是对系统的使用或修改
活动）的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。下节将对
ATAM 进行重点介绍。
（3） 基于度量的方式：它是建立在软件架构度量的基础上的，涉及三个基本活动，首
先需要建立质量属性和度量之间的映射原则，即确定怎样从度量结果推出系统具有什么样的
质量属性；然后从软件架构文档中获取度量信息；最后根据映射原则分析推导出系统的质量
属性。它能提供更为客观和量化的质量评估，但它对评估人员及其使用的技术有较高
的要求。 ATAM 中也使用了度量的思想（度量效用）。

8.2 架构的权衡分析法

从技术角度对软件架构进行评估，旨在通过分析来预见软件的质量；通过分析来创建、
选择、评估与比较不同的架构。例如， Kazman 等人在 2000 年提出的架构的 ATAM 方法。
ATAM 方法不但能够揭示架构如何满足特定的质量需求（例如，性能和可修改性），而且还
提供了分析这些质量需求之间交互作用的方法。使用 ATAM 方法评价一个软件架构的目的
是理解架构设计满足系统质量需求的结果。

ATAM 的 9 个步骤：

（1）ATAM 方法的表述

（2）商业动机的表述

（3）架构的表述

（4）对架构方法进行分类

（5）生成质量属性效用树

（6）分析架构方法

（7）集体讨论并确定场景的优先级

（8）分析架构方法

（9）结果的表述

8.3 成本效益分析法

在大型复杂系统中最大的权衡通常必须考虑经济性，因此，需要从经济角度建立成本、
收益、风险和进度等方面软件的“经济”模型。成本效益分析法（the Cost Benefit Analysis
Method， CBAM）是在 ATAM 上构建，用来对架构设计决策的成本和收益进行建模，是优
化此类决策的一种手段。

CBAM 的步骤：

（1）整理场景

（2）对场景进行求精

（3）确定场景的优先级

（4）分配效用

（5）架构策略涉及哪些质量属性及响应级别

（6）使用内插法确定“期望的”质量属性响应级别的效用

（7）计算各架构策略的总收益

（ 8）根据受成本限制影响的 ROI（ Return On Investment，投资报酬率）选择架构策略

9、构件及其复用

定义 1：构件是指软件系统中可以明确辨识的构成成分。而可复用构件（ reusablecomponent）是指具有相对独立的功能和可复用价值的构件。

定义 2：构件是一个组装单元，它具有约定式规范的接口及明确的依赖环境。

定义 3：构件是软件系统中具有相对独立功能、可以明确辨识、接口由契约指定、和语境有明显依赖关系、可独立部署的可组装软件实体。

对构件更广义的理解是把所有种类的工作成品（例如，各类文档、方案、计划、测试案例、代码）都看成是可复用的构件。
 

今天的文章
软件架构师考试经验分享_软件架构师考试时间分享到此就结束了，感谢您的阅读。