软考高级架构师——6、软件架构设计

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

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

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

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 种：可用性、可修改性、
性能、安全性、可测试性、易用性。其他的质量属性一般可纳入这几个属性中（在其他文献
中为了强调常单列出来），例如，可扩充性可归入可修改性中（修改系统容量），可移植性也
可以作为平台的可修改性来获得。对于未能纳入的其他质量属性，可以用本章的方法进行研
究。

可用性	目标是阻止错误发展成故障，至少能够把错误的影响限制在一定范围内，从而使修复成为可能 战术分为：错误检测、错误恢复、错误预防。
可修改性	①局部化修改。在设计期间为模块分配责任，以便把预期的变更限制在一定的范围内， 从而降低修改的成本. ②防止连锁反应。由于模块之间有各种依赖性，因此，修改会产生连锁反应 战术：信息隐藏、维持现有的接口、限制通信路径、仲裁者的使用： ③推迟绑定时间。系统具备在运行时进行绑定并允许非开发人员进行修改（配置）。
性能	性能与时间相关，影响事件的响应时间有两个基本因素：资源消耗、闭锁时间 战术： ① 资源需求：减少处理事件流所需的资源、减少所处理事件的数量、控制资源的使用 ② 资源管理：引入并发、维持数据或计算的多个副本、增加可用资源 ③ 资源仲裁：先进/先出（FIFO）、固定优先级调度、动态优先级调度、静态调度
安全性	战术： ① 抵抗攻击：对用户进行身份验证、对用户进行授权、维护数据的机密性、维护完整性、限制暴露的信息、限制访问 ② 检测攻击：一般通过“入侵检测”系统进行过滤、比较通信模式与历史基线等方法 ③ 从攻击中恢复：识别攻击者：作为审计追踪，用于预防性或惩罚性目的。
可测试性	战术： ① 输入/输出 记录/回放：指捕获跨接口的信息，并将其作为测试专用软件的输入； 将接口与实现分离：允许使用实现的替代（模拟器）来支持各种测试目的； 优化访问线路/接口：用测试工具来捕获或赋予构件的变量值。 ② 内部监控。当监视器处于激活状态时，记录事件（如通过接口的信息）。
易用性	战术: ① 运行时战术 任务的模型：维护任务的信息，使系统了解用户试图做什么，并提供各种协助； 用户的模型：维护用户的信息，例如使系统以用户可以阅读页面的速度滚动页面 系统的模型：维护系统的信息，它确定了期望的系统行为，并向用户提供反馈 ② 设计时战术。将用户接口与应用的其余部分分离开来，预计用户接口会频繁发生变 化，因此，单独维护用户接口代码将实现变更局部化。这与可修改性相关 ③ 支持用户主动操作。支持用户的主动操作，如支持“取消”、“撤销”、“聚合”和 “显 示多个视图”

 3、软件架构风格

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

数据流风格	批处理序列	顺序执行，只有当前一步处理完，后一步处理才能开始
	管道/过滤器	每个构件都有一组输入和输出
调用/返回风格	主程序/子程序	采用单线程控制，调用关系具有层次性
	面向对象风格	对象负责维护其表示的完整性，对象的表示对其他对象而言是隐蔽的
	层次结构	每一层为上层服务，并作为下层客户
独立构件风格	进程通信	构件是独立的过程，连接件是消息传递 消息传递的方式可以是点到点、异步和同步方式及远过程调用
	事件系统 （隐式调用）	触发或广播一个或多个事件 如：程序语法高亮、语法错误提示
虚拟机风格	解释器	自定义流程，按流程执行，规则随时改变，灵活定义，业务灵活组合。 解释器：解释引擎、存储区、工作状态的数据结构、执行进度的数据结构四部分组成。 规则系统：包括规则集、规则解释器、规则/数据选择器及工作内存 如：DDS和人工智能、专家系统、机器人系统
	基于规则的系统
仓库风格	数据库系统	数据库构成：一个是中央共享数据源，保存当前系统的数据状态； 另一个是多个独立处理元素，处理元素对数据元素进行操作 超文本系统：早期的静态网页。 黑板（共享数据）：选取各种黑板、知识源和控制模块的构件来设计 多用于语音识别，知识推理等复杂问题，解空间很大，求解过程不确定的这一类软件系统。
	超文本系统
	黑板系统

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 的关键技术

UDDI	Universal Description Discovery and Integration，统一描述、发现和集成 UDDI 规范描述了服务的概念，同时也定义了一种编程接口。通过 UDDI 提供的 标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信 息，并动态绑定到该服务上。 （1）数据模型（2） API（3）注册服务
WSDL	Web Service Description Language， Web 服务描述语言 对服务进行描述的语言，它有一套基于 XML 的语法定义。 WSDL 描述的重点是服务， 它包含服务实现定义和服务接口定义
SOAP	Simple ObjectAccess Protocol，简单对象访问协议 SOAP 用 XML 来格式化消息，用 HTTP 来承载消息。通过 SOAP， 应用程序可以在网络中进行数据交换和远程过程调用（Remote Procedure Call， RPC） （1）封装（2）编码规则（3） RPC 表示（4）绑定
REST	Representational State Transfer，表述性状态转移 设计概念和准则： （1） 网络上的所有事物都被抽象为资源。 （2）每个资源对应一个唯一的资源标识。 （3）通过通用的连接件接口对资源进行操作。 （4）对资源的各种操作不会改变资源标识。 （ 5）所有的操作都是无状态的。

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

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