rabbit-obsidian/Clippings/「软件架构」软件架构概述.md

---
title: "「软件架构」软件架构概述"
source: "https://zhuanlan.zhihu.com/p/610293282"
author:
  - "[[知乎专栏]]"
published:
created: 2024-12-16
description: "软件架构（architecture）是指软件系统的基本结构以及创建这种结构和系统的规程。每个结构都包含软件元素、它们之间的关系以及元素和关系的属性。[1]软件系统的架构是一个隐喻，类似于架构物的架构。[2]它作为系统…"
tags:
  - "clippings"
---
软件架构（architecture）是指软件系统的基本结构以及创建这种结构和系统的规程。每个结构都包含软件元素、它们之间的关系以及元素和关系的属性。\[1\]软件系统的架构是一个隐喻，类似于架构物的架构。\[2\]它作为系统和开发项目的蓝图，布置设计团队需要执行的任务。\[3\]

软件架构（architecture）是指做出基本的结构选择，一旦实现，改变这些选择的代价是高昂的。软件架构（architecture）选择包括软件设计中可能出现的特定结构选项。例如，控制航天飞机运载火箭的系统要求非常快和非常可靠。因此，需要选择合适的实时计算语言。此外，为了满足可靠性的需要，可以选择有多个冗余和独立生成的程序副本，并在交叉检查结果的同时在独立硬件上运行这些副本。

记录软件架构有助于利益相关者之间的沟通，捕获有关高级设计的早期决策，并允许在项目之间重用设计组件。

## **范围**

对于软件架构的范围，人们的看法各不相同：\[5\]

- 宏观系统结构：这是指架构，它是一个软件系统的高级抽象，由一组计算组件和描述这些组件之间交互的连接器组成。\[6\]
- 不管是什么重要的东西：这指的是软件架构师应该关注那些对系统及其涉众有重大影响的决策。\[7\]
- 对理解一个系统在其环境中所处的环境至关重要的东西\[8\]
- 人们认为很难改变的事情：由于设计架构发生在软件系统生命周期的开始，所以架构师应该关注那些“必须”在第一时间正确的决策。按照这种思路，一旦架构设计问题的不可逆性能够被克服，它们就可能变成非架构性的问题
- 一组架构设计决策：软件架构不应仅仅被视为一组模型或结构，而应包括导致这些特定结构的决策及其背后的理论基础。\[9\]这种见解导致了对软件架构知识管理的大量研究。\[10\]

软件架构（architecture）与设计（design）和需求工程（requirement engineering）之间没有明显的区别（参见下面的相关字段）。它们都是从高层意图到底层细节的“意向链”的一部分

## **特点**

软件架构展示了以下内容：

- 利益相关者众多：软件系统必须迎合各种利益相关者，如业务经理、所有者、用户和运营商。这些利益相关者对系统都有自己的关注点。平衡这些关注点并证明它们得到了解决是系统设计的一部分。\[4\]：29–31这意味着架构涉及到处理各种各样的关注点和涉众，并且具有多学科性质。
- 关注点分离：架构师降低复杂性的既定方法是分离驱动设计的关注点。架构（Architecture）文档显示，所有涉众关注点都是通过从与各种涉众关注点相关联的不同角度建模和描述架构来解决的。\[12\]这些单独的描述称为架构视图（例如，请参见4+1架构视图模型）。
- 质量驱动：经典的软件设计方法（如Jackson结构化编程）是由系统所需的功能和数据流驱动的，但目前的观点\[4\]：26-28是软件系统的架构与其质量属性（如容错性、向后兼容性）的关系更为密切，可扩展性、可靠性、可维护性、可用性、安全性、可用性和其他此类功能。干系人关注点通常转化为对这些质量属性的需求，这些属性被不同地称为非功能需求、额外功能需求、行为需求或质量属性需求。
- 重复样式：与构建架构一样，软件架构规程已经开发了解决重复问题的标准方法。这些“标准方法”在不同的抽象层次上由不同的名称来调用。重复性解决方案的常用术语是架构样式，\[11\]：273–277策略，\[4\]：70–72参考架构\[13\]\[14\]和架构模式。\[4\]：203–205
- 概念完整性：Fred Brooks在《神话人月》中引入的一个术语，用来表示软件系统的架构代表了它应该做什么以及应该如何做的总体构想。这一设想应与实施分开。架构师承担着“视觉守护者”的角色，确保系统的添加与架构一致，从而保持概念的完整性。\[15\]：41–50
- 认知约束：计算机程序员Melvin Conway在1967年的一篇论文中首次观察到，设计系统的组织被限制生成设计，这些设计是这些组织的通信结构的副本。与概念完整性一样，弗雷德·布鲁克斯在其优雅的经典作品《神话人月》（Mythical Man Month）中引用了这篇论文和这一理念，并称之为“康威定律”（Conway's Law），将其介绍给了更广泛的读者

## **动机**

软件架构（architecture）是复杂系统的“智能可理解”抽象。\[4\]：5–6该抽象提供了许多好处：

- 它为在系统构建之前对软件系统的行为进行分析提供了基础。\[2\]验证未来软件系统是否满足其利益相关者的需求而无需实际构建它的能力代表了大量的成本节约和风险缓解。\[16\]已经开发了许多技术来执行此类分析，比如阿塔姆。
- 它为元素和决策的重用提供了基础。\[2\]\[4\]：35一个完整的软件架构或其部分，如单个架构策略和决策，可以跨多个系统重用，这些系统的涉众需要相似的质量属性或功能，从而节省设计成本并降低设计错误的风险。
- 它支持影响系统开发、部署和维护寿命的早期设计决策。\[4\]：31正确地做出早期、高影响的决策对于防止进度和预算超支非常重要。
- 它促进了与涉众的沟通，有助于建立一个更好地满足其需求的系统。\[4\]：29–31从涉众的角度沟通复杂系统，有助于他们理解所述需求的后果以及基于这些需求的设计决策。架构使得在系统实现之前就设计决策进行交流的能力，而这些决策仍然相对容易适应。
- 它有助于风险管理。软件架构有助于减少风险和失败的机会
- 它可以降低成本。软件架构是在复杂的IT项目中管理风险和成本的一种手段

## **历史**

软件设计和（民用）架构的比较最早出现在20世纪60年代末，\[18\] 但是直到20世纪90年代，“软件架构”这个术语才被广泛使用。\[19\]计算机科学领域自形成以来就遇到了与复杂性相关的问题。\[20\]早期的复杂性问题是由开发人员通过选择正确的数据结构、开发算法和应用关注点分离。虽然“软件架构”这个术语对业界来说是相对较新的，但自20世纪80年代中期以来，该领域的基本原理就被软件工程的先驱们零星地应用。早期捕获和解释系统的软件架构的尝试是不精确和无序的，通常以一组方框图和折线图为特征。\[21\]

软件架构作为一个概念起源于1968年Edsger Dijkstra和70年代早期David Parnas的研究，这些科学家强调软件系统的结构至关重要，正确的结构至关重要。在20世纪90年代，有一个共同的努力来定义和编纂该学科的基本方面，研究工作集中在架构风格（模式）、架构描述语言、架构文档和形式方法上

作为一门学科，研究机构在促进软件架构的发展方面发挥了突出的作用。卡内基梅隆大学的Mary Shaw和David Garlan在1996年写了一本书，名为《软件架构：对一门新兴学科的展望》，该书提倡软件架构概念，如组件、连接器和样式。加州大学欧文软件研究所致力于软件架构研究，主要针对架构风格、架构描述语言和动态架构。

IEEE 1471-2000《软件密集型系统架构描述推荐规程》是软件架构领域的第一个正式标准。它于2007年被ISO采用为ISO/IEC 42010:2007。2011年11月，IEEE 1471-2000被ISO/IEC/IEEE 42010:2011“系统和软件工程-架构描述”（由IEEE和ISO联合发布）取代

在IEEE 1471中，软件架构是关于“软件密集型系统”的架构，定义为“软件对整个系统的设计、构建、部署和演化产生重要影响的任何系统”，2011年版更进一步，包括了ISO/IEC 15288和ISO/IEC 12207对系统的定义，这些定义不仅包括硬件和软件，还包括“人、过程、程序、设施、材料和自然发生的实体”。这反映了软件架构、企业架构和解决方案架构之间的关系。

## **架构活动**

软件架构师执行的活动有很多。软件架构师通常与项目经理合作，与干系人讨论架构上重要的需求，设计软件架构，评估设计，与设计师和干系人沟通，记录架构设计等。\[23\]软件架构设计中有四个核心活动。\[24\]这些核心架构活动是在初始软件开发生命周期的不同阶段以及系统的演化过程中迭代执行的。

- 架构（architecture）分析是理解所提议的系统将在其中运行的环境并确定系统需求的过程。分析活动的输入或需求可以来自任何数量的涉众，包括以下项目：

1. 系统运行时将做什么（功能需求）
2. 系统将如何执行运行时非功能性需求，如可靠性、可操作性、性能效率、安全性、ISO/IEC 25010:2011标准\[25\]中定义的兼容性
3. 开发时非功能性需求，如ISO 25010:2011标准\[25\]中定义的可维护性和可转移性
4. 一个系统的业务需求和环境背景可能会随着时间而改变，例如法律、社会、金融、竞争和技术问题\[26\]

- 分析活动的输出是那些对软件系统架构有可测量影响的需求，称为架构上重要的需求
- 架构综合或设计是创造一个架构的过程。考虑到通过分析确定的架构上的重要需求、设计的当前状态和任何评估活动的结果，创建并改进了设计。\[24\]\[4\]：311–326
- 架构（Architecture）评估（evaluation）是确定当前设计或其一部分如何满足分析期间导出的需求的过程。每当架构师考虑设计决策时，评估就可能发生，评估可能发生在设计的某一部分完成之后，评估可能发生在最终设计完成之后，评估也可能发生在系统构建之后。一些可用的软件架构（architecture）评估技术包括架构（architecture）权衡分析方法（ATAM）和TARA。\[28\]比较这些技术的框架在SARA报告\[16\]和架构评审：实践和经验\[29\]等框架中进行了讨论
- 架构演化是维护和调整现有软件架构以满足需求和环境变化的过程。由于软件架构提供了软件系统的基本结构，其演化和维护必然会影响其基本结构。因此，架构演进涉及添加新功能以及维护现有功能和系统行为。

架构需要关键的支持活动。这些支持活动贯穿于核心软件架构（architecture）过程。它们包括知识管理和沟通、设计推理和决策以及文档。

## **架构支持活动**

软件架构（architecture）支持活动在核心软件架构（architecture）活动期间执行。这些支持活动帮助软件架构师进行分析、综合、评估和演化。例如，架构师必须在分析阶段收集知识、做出决策和文档。

- 知识管理和通信是一种探索和管理知识的行为，对设计软件架构至关重要。软件架构师不是孤立地工作的。它们从不同的涉众那里获得输入、功能性和非功能性需求以及设计上下文；并向涉众提供输出。软件架构知识通常是默认的，并保留在涉众的头脑中。软件架构知识管理活动是关于发现、交流和保留知识的活动。由于软件架构设计问题错综复杂且相互依存，设计推理中的知识缺口可能导致不正确的软件架构设计。\[23\]\[30\]知识管理和沟通活动的示例包括搜索设计模式、原型设计、询问有经验的开发人员和架构师，评估类似系统的设计，与其他设计师和利益相关者共享知识，并在wiki页面中记录经验。
- 设计推理与决策是评价设计决策的活动。这项活动是所有三个核心软件架构活动的基础。\[9\]\[31\]它需要收集和关联决策上下文，制定设计决策问题，寻找解决方案选项，并在做出决策之前评估权衡。当评估重要的架构需求和软件架构决策，以及软件架构分析、合成和评估时，此过程在不同的决策粒度级别上发生。推理活动的例子包括理解需求或设计对质量属性的影响，质疑设计可能引起的问题，评估可能的解决方案选项，以及评估解决方案之间的权衡。
- 文档是记录软件架构（architecture）过程中生成的设计的行为。系统设计使用几个视图进行描述，这些视图通常包括显示系统代码结构的静态视图、显示系统在执行期间的操作的动态视图和显示系统如何放置在硬件上执行的部署视图。Kruchten的4+1视图建议描述用于记录软件架构的常用视图；\[32\]记录软件架构：views and Beyond描述了视图描述中可以使用的各种符号。\[1\]文档活动的示例正在编写规范，记录系统设计模型，记录设计原理，开发观点，记录视图。

## **软件架构主题**

## **软件架构描述**

Main article: Software architecture description

软件架构描述涉及使用架构描述语言、架构视点和架构框架等机制对架构进行建模和表示的原则和实践。

## **架构描述语言**

Main article: Architecture description language

架构描述语言（ADL）是用来描述软件架构（ISO/IEC/IEEE 42010）的任何表达方式。自20世纪90年代以来，开发了许多专用ADL，包括AADL（SAE标准）、Wright（由卡内基梅隆开发）、Acme（由卡内基梅隆开发）、xADL（由UCI开发）、Darwin（由伦敦帝国理工学院开发）、DAOP-ADL（由马拉加大学开发）、SBC-ADL（由国立中山大学开发）和ByADL（意大利拉奎拉大学）。

## **架构角度**

Main article: View model

![[30db9223d96c3be082656b0cf9d71257_MD5.jpg]]

**4+1架构视图模型。**

软件架构描述通常被组织成视图，类似于在架构架构中生成的不同类型的蓝图。每个视图都按照其视点的约定处理一组系统关注点，其中视点是一个规范，描述了要在视图中使用的符号、建模和分析技术，该视图从给定的一组涉众及其关注点的角度表示所讨论的架构（ISO/IEC/IEEE42010）。该视点不仅指定了所构建的关注点（即要解决的关注点），而且还指定了表示、使用的模型类型、使用的约定以及任何保持视图与其他视图一致的一致性（对应）规则。

## **架构框架**

Main article: Architecture framework

架构（architecture）框架捕获“描述在特定应用领域和/或利益相关者社区中建立的架构的惯例、原则和实践”（ISO/IEC/IEEE42010）。框架通常是根据一个或多个视点或adl来实现的。

## **架构风格和模式**

Main article: Architectural pattern

架构模式是一种通用的、可重用的解决方案，用于解决给定上下文中软件架构中常见的问题。架构模式通常被记录为软件设计模式。

“软件架构风格”是继传统架构风格之后的一种特殊的架构方法，其特点是使其引人注目（架构风格）。

架构样式定义：以结构组织模式表示的一系列系统；组件和连接器的词汇表，以及如何组合它们的约束条件。\[33\]

“架构样式是可重用的设计决策和约束的‘包’，应用于架构以获得所选的理想质量。\[34\]”

有许多公认的架构模式和风格，其中包括：

- 黑板
- 客户端服务器（2层、3层、n层，云计算展示了这种风格）
- 基于组件
- 以数据为中心
- 事件驱动（或隐式调用）
- 分层（或多层架构）
- 微服务架构
- 整体应用
- 模型视图控制器（MVC）
- 对等（P2P）
- 管道和过滤器
- 插件
- 反应式架构
- 代表性状态转移（REST）
- 基于规则
- 服务导向
- 无共享架构
- 空间架构

有些人认为架构模式和架构风格是一样的，\[35\]有些人认为风格是模式的专门化。它们的共同点是模式和风格都是架构师使用的习语，它们“提供了一种共同的语言”\[35\]或“词汇”\[33\]来描述系统的类。

## **软件架构与敏捷开发**

Main article: Agile development

也有人担心软件架构会导致太多的大设计，特别是在敏捷软件开发的支持者中。已经开发了许多方法来平衡前期设计和敏捷性之间的权衡，\[36\]包括敏捷方法DSDM，DSDM要求在“基础”阶段打下“足够”的架构基础。IEEE软件专门出版了一期专门讨论敏捷性和架构之间的交互的专刊\[37\]。

## **软件架构侵蚀**

软件架构侵蚀（或称“衰退”）是指在软件系统的实现过程中，在软件系统的计划架构和实际架构之间观察到的差距。\[38\]当实现决策没有完全实现计划架构或违反这种架构。\[2\]计划架构和实际架构之间的差距有时可以用技术债务的概念来理解。

例如，考虑一个严格分层的系统，其中每个层只能使用它下面的层提供的服务。任何不遵守此约束的源代码组件都表示违反了架构。如果不加以纠正，这种违规行为可能会将架构转换为一个整体块，从而对可理解性、可维护性和可演化性产生不利影响。

已经提出了各种办法来解决侵蚀问题。”这些方法，包括工具、技术和过程，主要分为三大类，试图最小化、防止和修复架构侵蚀。在这些大类中，每一种方法都进一步细分，反映了为解决侵蚀问题而采取的高级别战略。这些是面向过程的架构一致性、架构演化管理、架构设计实施、架构到实现的链接、自适应和架构恢复技术，包括恢复、发现和协调

检测架构冲突有两种主要技术：反射模型和领域特定语言。反射模型（RM）技术将系统架构师提供的高级模型与源代码实现进行比较。还有一些特定于领域的语言，重点是指定和检查架构约束。

## **软件架构恢复**

Main article: Software architecture recovery

软件架构（architecture）恢复（或重构，或逆向工程）包括从可用信息（包括其实现和文档）中揭示软件系统架构的方法、技术和过程。在面对过时或过时的文档和架构侵蚀时，架构恢复通常是做出明智决策所必需的：实现和维护决策与设想的架构不同。\[40\]存在将软件架构恢复为静态程序分析的实践。这是软件智能实践课程的一部分。

## 相关领域

## **设计**

Main article: Software design

架构是设计，但并非所有的设计都是架构。\[1\]实际上，架构师是在软件架构（架构设计）和详细设计（非架构设计）之间划清界线的人。没有适合所有情况的规则或准则，尽管有人试图将这种区别形式化。根据内涵/局部性假设，\[41\]架构设计和详细设计之间的区别是由局部性标准定义的，\[41\]根据局部性标准，关于软件设计的陈述是非局部的（架构），前提是满足它的程序可以扩展成不满足它的程序。例如，客户机-服务器样式是架构（战略性的），因为基于此原则构建的程序可以扩展为非客户机-服务器的程序，例如，通过添加对等节点。

## **需求工程**

Main article: Requirements engineering

需求工程和软件架构可以看作是互补的方法：当软件架构以“解决方案空间”或“如何”为目标时，需求工程解决“问题空间”或“什么”。\[42\]需求工程需要启发、协商、规范、验证，要求的文件和管理。需求工程和软件架构都围绕涉众的关注点、需求和愿望。

需求工程（engineering）和软件架构（architecture）之间存在相当大的重叠，例如，对五种工业软件架构（architecture）方法的研究表明，“输入（目标、约束等）通常定义不清，只有当架构开始出现时才能被发现或更好地理解，并且“虽然大多数架构关注点被表达为系统上的需求，但它们也可以包括强制性的设计决策”\[24\]简而言之，所需的行为影响解决方案架构，这反过来又可能引入新的需求。\[43\]双峰模型等方法\[44\]旨在利用需求和架构之间的协同关系。

## **其他类型的“架构”**

Main articles: Computer architecture, Systems architecture, and Enterprise architecture

### **计算机架构**

计算机架构以计算机系统的内部结构为目标，以协作硬件组件（如CPU或处理器、总线和内存）为基础。

### **系统架构**

术语系统架构最初应用于由硬件和软件组成的系统架构。系统架构解决的主要问题是将软件和硬件集成到一个完整、正常工作的设备中。在另一个共同的（更广泛的）含义中，这个术语适用于任何复杂系统的架构，这些系统可能具有技术性、社会技术性或社会性。

### **企业架构**

企业架构的目标是“将业务远景和战略转化为有效的企业”\[45\]企业架构框架，如TOGAF和Zachman框架，通常区分不同的企业架构层。尽管术语因框架而异，但许多术语至少包括业务层、应用程序（或信息）层和技术层之间的区别。企业架构解决了这些层之间的对齐问题，通常采用自顶向下的方法。

## **另见**

架构模式（计算机科学）

- 反模式
- 属性驱动设计
- 计算机架构
- 分布式数据管理架构
- 分布式关系数据库架构
- 系统架构
- 系统设计
- 软件架构分析方法
- 时间触发系统

谢谢大家关注，转发，点赞和点在看。