概述

软件系统架构是关于软件系统的结构、行为和属性的高级抽象。在描述阶段，主要描述直接构成系统的抽象组件以及各个组件之间的连接规则，特别是相对细致地描述组件的交互关系。在实现阶段，这些抽象组件被细化为实际的组件，比如具体类或者对象。软件系统架构不仅指定软件系统的组织和拓扑结构，而且显示系统需求和组件之间的对应关系，包括设计决策的基本方法和基本原理。

软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。但是软件架构与用户对系统的功能性需求没有直接的对应关系。

有3个由大到小的层次：

• 架构模式：软件设计中的高层决策，C/S结构就属于架构模式，架构模式反映开发软件系统过程中所作的基本设计决策
• 设计模式：主要关注软件系统的设计，与具体的实现语言无关；垃圾回收机制是Java语言管理内存资源时常用的一种设计模式。
• 惯用法：最低层的模式，关注软件系统的设计与实现，描述如何实现构件及构件之间的关系，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系，例如引用-计数就是C++语言中的一种惯用法。

软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动，是一个迭代的过程。架构设计主要关注软件组件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。

软件架构设计与系统需求是直交的，两者并无必然联系。

优点

软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素：

• 软件架构设计能够满足系统的性能、安全性、可维护性等品质；
• 软件架构设计能够帮助项目干系人（Stakeholder）更好地理解软件结构；
• 软件架构设计能够有效地管理系统的复杂性，并降低系统维护费用；
• 软件架构设计对系统开发具有指导性；
• 软件架构设计为系统复用奠定的基础；
• 软件架构设计能够支持冲突分析。

ADL

架构描述语言，Architecture Description Language，ADL是一种为明确说明软件系统的概念架构和对这些概念架构建模提供功能的语言。ADL主要包括以下组成部分：组件、组件接口、连接件和架构配置。ADL对连接件的重视成为和其他建模语言区分的重要特征之一。

复用

软件架构设计的一个核心问题是能否使用重复的架构模式，即能否达到架构级的软件重用。即，能否在不同的软件系统中，使用同一架构。基于这个目的，学者们开始研究和实践软件架构的风格和类型问题。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件架构风格定义用于描述系统的术语表和一组指导构件系统的规则。

软件架构复用是指在不改变软件功能的情况下，将已有的软件架构直接或进行微调后复用到新的软件或系统中，从而加快软件开发进程，提高软件生产效率。

软件架构复用包括软件产品复用和软件过程复用两部分的内容。其中，软件产品复用是指将已有的软件组件（如函数、模块、组件等）直接或进行适应性修改后复用到新的软件或系统中；软件过程复用是指将已有的软件生产过程中的各种劳动成果（如设计文档、测试案例、源代码等）直接或进行适应性修改后复用到新的软件或系统中。

复用：开发过程中，只要发现有可复用的资产，就对其进行复用；
计划复用：开发之前就要进行规划，以决定哪些需要复用；

软件架构复用可以分为以下几种类型：

• 代码级复用：通过编写公共类和公共函数等，供开发人员直接使用
• 组件级复用：将功能的组件化封装，对外提供API接口
• 模块级复用：在开发的项目或产品中，如果发现大量重复的功能模块，可以在这些模块设计时注重扩展性，使其能应用到其他类似功能的项目中
• 构架级复用：构架级在设计概念上最为高级的一种。它相当于一个平台或者思想，在这个平台上，可以开发出根据此平台思想稳定而又高效的软件产品

软件架构复用的实现方式主要包括以下几种：

• 白盒复用：源代码可见，可修改和扩展
• 黑盒复用：源代码不可见，不能修改
• 模块层次复用：接口/类，包括继承和委托等

失配

失配是指在软件复用的过程中，由于待复用构件对最终系统的体系结构和环境的假设（assumption）与实际状况不同而导致的冲突。在构件组装阶段失配问题主要包括：

1. 构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配
2. 连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配
3. 系统成分对全局体系结构的假设存在冲突引起的失配等。

要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。

需求

软件架构需求是指用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。需求过程主要是获取用户需求，标识系统中所要用到的构件，并进行架构需求评审。其中标识构件又详细分为生成类图、对类图进行分组和将类打包成构件三步。软件架构需求并不应该包括设计构件的过程。

建模

应用架构建模中要绘制的第一个物理数据流图（PDFD）是网络架构DFD，它们不显示单位时间的数据流量，需要显示的信息包括服务器及其物理位置；客户端及其物理位置；处理器说明；传输协议。

生命周期

软件架构贯穿于软件的整个生命周期，但在不同的阶段对软件架构的关注力度并不相同。其中需求分析阶段主要关注问题域；设计阶段主要将需求转换为软件架构模型；软件实现阶段主要关注将架构设计转换为实际的代码；软件部署阶段主要通过组装软件组件提高系统的实现效率。其中设计与实现阶段在软件架构上的工作最多，也最重要，因此关注力度最大。

风格

软件架构风格是描述某一特定应用领域中的系统组织方式和惯用模式，反映领域中众多系统所共有的结构和语义两个方面的特征，主要包括架构定义、架构词汇表和架构约束，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

架构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。

架构风格描述一类软件架构的特征，它独立于实际问题，强调软件系统中通用的组织结构选择。

分类

Garlan和Shaw对通用软件架构风格进行分类：

• 数据流风格：包括批处理序列和管道-过滤器两种风格
• 调用/返回风格：包括主程序/子程序、数据抽象、面向对象、层次结构
• 独立构件风格：包括进程通信、事件驱动、发布-订阅风格的系统
• 虚拟机风格：包括解释器和基于规则的系统
• 仓库风格：包括数据库系统、黑板系统和超文本系统
• 过程控制风格：包括有开环、闭环等
• 其他：包括C2、异构风格、混合风格

架构风格大类	架构小类	构件	连接件
数据流风格	批处理序列	计算单元
数据流风格	管理过滤器	过滤器	数据流传输的管道
调用/返回风格	主/子程序	主子程序	过程调用
调用/返回风格	面向对象	对象	对象间的交付方式
调用/返回风格	层次结构	每一层	层间的交付方式
独立构件	进程通信	独立的进程	消息传递
独立构件	事件驱动	模块	隐式调用
仓库风格	黑板系统	知识源	黑板系统或数据库系统

数据流风格

批处理序列

定义：构建为一序列固定顺序的计算单元，构建之间只通过数据传递进行交付，每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式进行传递
特点：强调整体性，无交互

管理过滤器

定义：

• 每个构建都有一组输入、输出，构建读输入的数据流，经过内部处理，然后产生输出数据流，这个过程通常是通过对输入数据流的变换或计算来完成的，包括：
  • 通过计算和增加信息以丰富数据
  • 通过浓缩和删除以精简数据
  • 通过改变记录方式以转化数据和递增的转化数据
• 构建为过滤器，连接件是数据流传输的管道

特点：不适合处理交互式应用

调用/返回风格

主程序/子程序

定义：

• 所有的计算构件作为子程序协作工作，并由一个主程序顺序地调用这些子程序，构件通过共享存储区交换数据。
• 调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性

构件为主程序和子程序，连接件是过程调用

面向对象

定义：建立在数据抽象和面向对象的基础上，数据的表示和它们的相应操作被封装起来。

构件是对象，对象是抽象数据类型的实例，对象之间通过消息机制进行通信，连接件是对象间的交付方式。

层次结构

定义：每层为上层提供服务，并使用下层提供的服务，一般中间层只对相邻层可见。

构件组成一个层次结构，连接件通过层间交互的协议来定义。

独立构件风格

进程通信

定义：构件通常是命名过程，消息传递可以是点对点、异步或同步方式、以及远程过程调用等。

构件是独立的进程，连接件是消息传递

事件驱动系统（隐式调用）

定义：构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发，系统自动调用在这个事件上注册的所有过程。

构件是一些模块，这些模块可以是过程或事件。连接件以过程之间的隐式调用来实现。

优点：增加架构的灵活性

缺点：

• 构件放弃对系统计算的控制
• 共享数据问题

实战

在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行。

对于语音识别、知识推理等问题复杂、解空间很大、求解过程不确定的这一类软件系统，通常会采用黑板架构风格，以知识为中心进行分析与推理。

对于因数据而驱动，数据到达某个构件，经过内部处理，产生数据输出的系统通常采用管道-过滤器体系结构风格。

某软件开发公司负责开发一个Web服务器服务端处理软件，其核心部分是对客户端请求消息的解析与处理，包括HTTP报头分离、SOAP报文解析等功能。该公司的架构师决定采用成熟的架构风格指导整个软件的设计，以下（）架构风格，最适合该服务端处理软件。

解析：
Web服务器服务端的核心功能是数据处理，Web服务在数据传输方面具有协议分层的特征，即底层协议会包装上层协议（HTTP协议体中包含整个SOAP消息内容），因此需要数据内容的逐步分解与分阶段处理。由于管道-过滤器的架构风格支持分阶段数据处理，因此特别适合该服务端处理软件的要求。

调温器需要实时获取外界的温度信息，与用户定义的温度进行比较并做出动作。根据该系统的应用领域和实际需求，是典型的过程控制架构风格的应用场景。

某公司拟开发一个轿车巡航定速系统，系统需要持续测量车辆当前的实时速度，并根据设定的期望速度启动控制轿车的油门和刹车。采用过程控制架构风格最为合适。

用户会注册自己的兴趣，系统也会把新闻按兴趣分类，如果某个新闻事件发生，可以通过事件来触发推送动作，将新闻推送给对其感兴趣的用户。事件驱动系统应用场景。

Windows操作系统在图形用户界面处理方面采用的是典型的事件驱动架构风格，首先注册事件处理的是回调函数，当某个界面事件发生时，系统会查找并选择合适的回调函数处理该事件。

某公司欲开发一个基于图形用户界面的集成调试器，该调试器的编辑器和变量监视器可以设置调试断点。当调试器在断点处暂停运行时，编辑程序可以自动卷屏到断点，变量监视器刷新变量数值。采用隐式调用的架构风格最为合适。回调机制。

某企业内部现有的主要业务功能已封装成Web服务。为拓展业务范围，需要将现有的业务功能进行多种组合，形成新的业务功能。针对业务灵活组合这一要求，采用解释器架构风格最为合适。

公司欲开发一个大型多人即时战略游戏，游戏设计的目标之一是能够支持玩家自行创建战役地图，定义游戏对象的行为和对象之间的关系。针对该需求，公司应该采用（ ）架构风格最为合适。解释器题目中提及“支持玩家自行创建战役地图”这说明系统要能应对“自定义”内容的解析，这需要用到解释器风格。

某公司欲开发一个漫步者机器人，用来完成火星探测任务。机器人的控制者首先定义探测任务和任务之间的时序依赖性，机器人接受任务后，需要根据自身状态和外界环境进行动态调整，最终自动完成任务。针对这些需求，该机器人应该采用隐式调用架构风格最为合适。解析： 漫步者机器人需要根据自身状态和外界环境进行自动调整，这是一个典型的根据外部事件进行响应的场景。

解释器是一个用来执行其他程序的程序，解释器可针对不同的硬件平台实现一个虚拟机，将高抽象层次的程序翻译为低抽象层次所能理解的指令，以消除在程序语言与硬件之间存在的语义差异。作为一种体系结构风格，解释器已经被广泛应用在从系统软件到应用软件的各个层面，包括各类语言环境、Internet浏览器、数据分析与转换等；LISP，Prolog、JavaScript、VBScript、HTML、Matlab、数据库系统（SQL解释器）、各种通信协议等。

Java是一种解释型语言，在JVM上运行，从架构风格上看是典型的虚拟机风格，即通过虚拟机架构屏蔽不同的硬件环境。

规则系统体系结构风格是一个使用模式匹配搜索来寻找规则并在正确的时候应用正确的逻辑知识的虚拟机，其支持把频繁变化的业务逻辑抽取出来，形成独立的规则库。这些规则可独立于软件系统而存在，可被随时地更新。它提供一种将专家解决问题的知识与技巧进行编码的手段，将知识表示为条件-行为规则，当满足条件时，触发相应的行为，而不是将这些规则直接写在程序源代码中，规则一般用类似于自然语言的形式书写，无法被系统直接执行，故而需要提供解释规则执行的解释器。扫地机器人系统适用于规则系统体系结构风格。

现代编译器主要关注编译过程和程序的中间表示，围绕程序的各种形态进行转化与处理。这种情况下，可以针对程序的各种形态构建数据库，通过中心数据库进行转换与处理，数据共享风格最符合要求。

某公司为其研发的硬件产品设计实现一种特定的编程语言，为了方便开发者进行软件开发，公司拟开发一套针对该编程语言的集成开发环境，包括代码编辑、语法高亮、代码编译、运行调试等功能。针对上述描述，该集成开发环境应采用（ ）架构风格最为合适。

答案：数据仓储（数据共享）。
解析：现代编译器的集成开发环境一般采用数据仓储（即以数据为中心的架构风格）架构风格进行开发，其中心数据就是程序的语法树。

• 早期的编译器采用管道-过滤器架构风格，以文本形式输入的代码被逐步转化为各种形式，最终生成可执行代码。并且大多数编译器在词法分析时创造独立的符号表，在其后的阶段会不断修改符号表，因此符号表并不是程序数据的一部分
• 现代的编译器采用以数据共享为中心的架构风格，主要关心编译过程中程序的中间表示；分析树是在语法分析阶段结束后才产生作为语义分析的输入，分析树是数据中心中重要的共享数据，为后续的语义分析提供帮助。

分布式

客户机/服务器系统开发时可以采用不同的分布式计算架构：

• 分布式表示架构是将表示层和表示逻辑层迁移到客户机，应用逻辑层、数据处理层和数据层仍保留在服务器上；
• 分布式数据架构是将数据层和数据处理层放置于服务器，应用逻辑层、表示逻辑层和表示层放置于客户机；
• 分布式数据和应用架构是将数据层和数据处理层放置在数据服务器上，应用逻辑层放置在应用服务器上，表示逻辑层和表示层放置在客户机上。

分布式系统开发分为5个逻辑计算层：

• 表示层实现用户界面；
• 表示逻辑层包括为了生成数据表示而必须进行的处理任务，如输入数据编辑等；
• 应用逻辑层包括为支持实际业务应用和规则所需的应用逻辑和处理过程，如信用检查、数据计算和分析等；
• 数据处理层包括存储和访问数据库中的数据所需的应用逻辑和命令，如查询语句和存储过程等；
• 数据层是数据库中实际存储的业务数据。

层次

物联网属于层次型架构，分为：

• 感知层：负责信息采集和物物之间的信息传输；实现对物理世界的智能感知识别、信息采集处理和自动控制；包括传感器、执行器，RFID，二维码和智能装置；
• 网络层：利用无线和有线网络对采集的数据进行编码、认证和传输；利用无线和有线网络对采集的数据进行编码、认证和传输，广泛覆盖的移动通信网络是实施物联网的基础设施；
• 应用层：实现应用。提供丰富的基于物联网的应用，物联网发展的根本目标，将物联网技术与行业信息化需求相结合。

DSSA

特定领域软件架构，Domain Specific Software Architecture，以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，其目标是支持一个特定领域中多个应用的生成。在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构。

特定领域的架构可以分为：

• 垂直域：定义一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构
• 水平域：定义在多个系统和多个系统族中功能区城的共有部分。在子系统级上涵盖多个系统族的特定部分功能。

DSSA通常是一个具有三个层次的系统模型：领域开发环境、领域特定应用开发环境和应用执行环境，其中应用工程师主要在领域特定应用开发环境中工作。

基本活动包括：

• 领域分析：主要目的是获得领域模型。领域模型描述领域中系统之间共同的需求，即领域需求；
• 领域设计：主要目标是获得DSSA，DSSA描述领域模型中表示需求的解决方案；
• 领域实现：主要目标是依据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。

参与DSSA的人员可以划分为4种角色：

• 领域专家：提供关于领域中系统的需求规约和实现的知识
• 领域设计人员：根据领域模型和现有系统开发出DSSA，并对DSSA的准确性和一致性进行验证
• 领域实现人员：
• 领域分析者：控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中

C2

C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。

C2风格中的系统组织规则如下：

• 系统中的构件和连接件都有一个顶部和一个底部
• 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的
• 一个连接件可以和任意数目的其他构件和连接件连接
• 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部

ABSD

基于软件架构的开发，Architecture Based Software Development，强调由商业、质量和功能需求的组合驱动软件架构设计，视角和视图来描述软件架构，用例和质量属性场景来描述需求。用例描述的是功能需求，质量属性场景描述的是质量需求（或侧重于非功能需求）。

ABSD方法有三个基础：

• 功能分解，在功能分解中使用已有的基于模块的内聚和耦合技术
• 通过选择体系架构风格来实现质量和商业需求
• 软件模板的使用

ABSD方法主要包括架构需求等6个主要活动：

• 架构需求：
• 架构设计：
• 架构文档化：应该从使用者的角度进行书写，针对不同背景的人员采用不同的书写方式，并将文档分发给相关人员。架构文档要保持较新，但不要随时保证文档最新，要保持文档的稳定性。架构文档化的主要输出结果是架构规格说明书和架构质量说明书。
• 架构复审：目标是标识潜在的风险，及早发现架构设计中的缺陷和错误
• 架构实现：
• 架构演化：针对用户的需求变化，修改应用架构，满足新的需求

使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，并且设计活动的开始并不意味着需求抽取和分析活动可以终止，而是应该与设计活动并行。ABSD方法是一个自顶向下递归细化的过程，软件系统的架构通过该方法得到细化，直到能产生软件构件的类。

架构设计、文档化和复审是一个迭代的过程。在一个主版本的软件架构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。架构复审过程中，通常会对一个可运行的最小化系统进行架构评估和测试。

质量属性

最常见的质量属性：可用性（Availability）、可修改性（Modifiability）、性能（Performance）、安全性（Security）、可测试性（Testability）、易用性（Usability）。

软件质量特性包括6个方面，每个方面都包含若干个子特性：

• 功能性：适合性、准确性、互操作性、依从性、安全性
• 可靠性：成熟性、容错性、易恢复性
• 易用性：易理解性、易学性、易操作性
• 效率：时间特性、资源特性
• 可维护性：易分析性、易改变性、稳定性、易测试性
• 可移植性：适应性、易安装性、遵循性、易替换性

软件质量属性通常需要采用特定的设计策略实现，设计策略会对其他质量属性产生影响。

改善（提高）软件质量属性的常见策略：

• 可用性（可靠性）

  • 错误检测：命令/响应、心跳机制、Ping/Echo、异常监控
  • 错误恢复：表决（裁决表）、主动冗余、被动冗余、备件（备份）、状态再同步、检查点/回滚、选举
  • 错误预防：从服务中删除异常（失效/失联）节点、事务（要么全成功，要么全失败）、定期重置、进程监视器

• 安全性

  • 抵抗攻击：对用户进行身份验证、对用户进行授权、维护数据的机密性、维护完整性、限制暴露的信息（信息隐藏）、限制访问
  • 检测攻击：部署入侵检测系统、追踪审计
  • 被攻击后恢复：恢复、识别攻击者

• 可修改性

  • 局部化修改：维持语义一致性、预期期望变更、泛化该模块、限制可能的选择、接口-实现分离
  • 防止连锁反应：信息隐藏（高内聚低耦合）、维持现有的接口、限制通信路径、使用仲裁者
  • 推迟绑定时间：运行时注册、配置文件、多态、构件更换

• 性能

  • 资源需求：减少处理时间所需的资源、减少所处理事件的数量、控制资源使用（改善资源需求）、限制执行时间、降低计算复杂度（减少计算开销）
  • 资源管理：引入并发、维持数据或计算的多个副本、增加可用（计算）资源
  • 资源仲裁：先进/先出、固定优先级、动态优先级调度、静态调度

• 可测试性

  • 输入/输出：记录/回放、将接口—实现分离、优化访问线路/接口
  • 内部监控：当监视器处于激活状态时、记录事件

刻画质量属性的手段由六部分组成：刺激源、刺激、环境、制品、响应、响应度量；

SAAM

基于场景的架构分析方法，Scenarios-based Architecture Analysis Method。卡耐基梅隆大学软件工程研究所的Kazman等人于1983年提出的一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛应用的软件架构分析方法。

场景

在进行体系结构（架构）评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。为得出这些目标而采用的机制做场景。场景是从风险承担者的角度对与系统的交互的简短描述。在体系结构评估中，一般从三方面来对场景进行描述：

• stimulus：刺激，场景中解释或描述风险承担者怎样引发与系统的交互部分。如，用户可能会激发某个功能，维护可能会做某个更改，测试人员可能会执行某种测试
• environment：环境，描述的是刺激发生时的情况。如，当前系统处于什么状态？有什么特殊约束条件？系统负载是否很大？某个网络通道是否出现阻塞等
• response：响应，指系统是如何通过体系结构对刺激作出反应的例如，用户所要求的功能是否得到满足？维护人员的修改是否成功？测试人员的测试是否成功等

SAAM的主要输入：问题描述、需求说明和架构描述；

其分析过程主要包括场景开发、架构描述、单个场景评估、场景交互和总体评估。

ATAM

架构权衡分析方法，Architecture Tradeoff Analysis Method。主要关注系统的需求说明。该方法强调对软件的质量属性进行分析、分类和优先级排序等工作，在此基础上构建质量属性效用树对质量属性描述进行刻画和排序，并对风险点、非风险点、敏感点和权衡点进行识别和分析。

效用树从根部到叶子节点依次是：树根、质量属性、属性分类、质量属性场景。

在SAAM基础之上发展起来的一种系统架构评估方法，主要对软件体系结构的设计结果进行评估。评估是软件系统详细设计、实现和测试之前的阶段工作，因此评估不涉及系统的实现代码和测试，因为评估是考査软件体系结构是否能够合适地解决软件系统的需求，并不对软件需求自身是否准确进行核实，而软件需求是否准确是需求评审阶段的工作。不是一种精确的评估方法，主要形式是评审会议。

主要包括：场景和需求收集、架构视图和场景实现、属性模型构造和分析、属性模型（架构决策）折中等4个阶段。

ATAM方法要求在系统开发之前，首先针对性能、可用性、安全性和可修改性等质量属性进行评价和折中。

整个评估过程强调以属性作为架构评估的核心概念。

4点

识别风险、非风险、敏感点和权衡点是进行软件架构评估的重要过程:

• 风险是某个存在问题的架构设计决策，可能会导致问题：非风险与风险相对，是良好的架构设计决策。风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念，即可能引起风险的因素，可称为风险点。
• 敏感点是一个或多个构件（和/或构件之间的关系）的特性。研究敏感点可使设计入员或分析员明确在搞清楚如何实现质量目标时应注意什么。敏感点是实现一个特定质量属性的关键特征，该特征为一个或多个软件构件所共有。
• 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。权衡点是影响一个或多个质量属性的特性，是多个质量属性的敏感点。

例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。

【改变业务数据编码方式会对系统的性能和安全性产生影响】是对权衡点的描述；
【改变加密的级别可能会对安全性和性能都产生显著的影响】是对系统权衡点的描述；
【假设用户请求的频率为每秒1个，业务处理时间小于30毫秒，则将请求响应时间设定为1秒钟是可以接受的】是对非风险的描述
【系统需要支持的最大并发用户数量直接影响传输协议和数据格式】描述敏感点

参考