软考高级架构师——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．属性驱动设计法