软件体系结构
软件体系结构是推理软件系统以及创建此类结构和系统的纪律所需的一组结构。每个结构都包含软件元素，它们之间的关系以及元素和关系的属性。
软件系统的架构是一个隐喻，类似于建筑物的架构。它可以用作系统和开发项目的蓝图，后来可以使用该项目来推断团队和相关人员执行所需的任务。
软件体系结构设计通常与软件应用程序设计并列。虽然应用程序设计着重于支持所需功能的流程和数据的设计（系统提供的服务），但软件体系结构设计着重于设计可以实现和执行应用程序功能的基础架构，以使功能在一个中提供了功能。满足系统非功能要求的方式。
软件体系结构是关于做出基本的结构选择，这些选择是一旦实施而更改为代价高昂的。软件体系结构选择包括来自软件设计中可能性的特定结构选项。
例如，控制航天飞机发射车的系统要求非常快速且非常可靠。因此，需要选择适当的实时计算语言。此外，为了满足对可靠性的需求，可以选择具有多个冗余和独立生产的程序副本，并在独立硬件上运行这些副本，同时交叉检查结果。
记录软件体系结构有助于利益相关者之间的沟通，捕获有关高级设计的早期决策，并允许在项目之间重复使用设计组件。
范围
意见因软件体系结构的范围而异：
- 宏观系统结构：这是指架构作为软件系统的高级抽象，该软件系统由计算组件的集合以及描述这些组件之间相互作用的连接器组成。
- 重要的东西 - 无论是什么：这是指软件架构师应该关注那些对系统及其利益相关者产生很大影响的决策的事实。
- 这对于理解一个系统在其环境中的基础是
- 人们认为很难改变的事情：由于设计架构是在软件系统生命周期开始时进行的，因此建筑师应专注于“必须”第一次正确的决策。遵循这种思路，一旦克服了它们的不可逆性，建筑设计问题可能会成为非架构的。
- 一组架构设计决策：软件体系结构不应仅被视为一组模型或结构，而应包括导致这些特定结构的决策以及其背后的基本原理。这种见解导致对软件体系结构知识管理的大量研究。
软件体系结构与设计与需求工程之间没有明显的区别（请参见下面的相关字段）。它们都是从高级意图到低级细节的“意图链”的一部分。
特征
软件体系结构将展示以下：
多种利益相关者：软件系统必须迎合各种利益相关者，例如业务经理，所有者，用户和运营商。这些利益相关者都对系统有自己的关注。平衡这些问题并证明它们已解决的是设计系统的一部分。这意味着建筑涉及处理各种各样的关注和利益相关者，并且具有多学科的性质。
关注点的分离：建筑师降低复杂性的既定方法是将驱动设计的关注点分开。体系结构文档表明，通过与各种利益相关者关注的不同角度进行建模和描述架构来解决所有利益相关者的关注。这些单独的描述称为架构视图（例如，参见4+1架构视图模型）。
质量驱动的：经典软件设计方法（例如杰克逊结构化编程）是由所需功能和通过系统的数据流驱动的，但是当前的见解是，软件系统的体系结构与其质量属性（例如容错，向后兼容，可扩展性，可靠性，可维护性，可用性，可用性，可用性等。利益相关者的问题通常会转化为这些质量属性的要求，这些质量属性称为非功能性要求，功能外要求，行为要求或质量属性要求。
经常性样式：像构建体系结构一样，软件体系结构纪律已经开发了解决重复关注的标准方法。这些“标准方式”以各种抽象级别的各种名称调用。重复解决方案的常见术语是建筑风格，战术，参考架构和体系结构模式。
概念完整性：弗雷德·布鲁克斯（Fred Brooks）在1975年的《神话人物月刊》（The Man Manth）中提出的一个术语，以表示软件系统的体系结构代表了它应该做什么以及如何做到这一点的整体愿景。该愿景应与其实施分开。建筑师扮演“视觉守护者”的角色，确保对系统的添加符合体系结构，从而确保概念上的完整性。
认知限制：计算机程序员梅尔文·康威（Melvin Conway）在1967年论文中首次提出的观察，该组织被限制为生成这些组织的通信结构副本的设计。与概念上的完整性一样，弗雷德·布鲁克斯（Fred Brooks）在他的优雅经典《神话人物月亮》中引用了报纸和想法时将其介绍给更广泛的听众，称其为“康威的律法”。
动机
软件体系结构是复杂系统的“智力上可以掌握”的抽象。该抽象提供了许多好处：
- 在构建系统之前，它为软件系统行为分析提供了基础。验证未来的软件系统能够满足其利益相关者的需求的能力，而无需实际构建它，这代表了大量的省略成本和降低风险。已经开发了许多技术来执行此类分析，例如ATAM或通过创建软件系统的可视化表示。
- 它为重新使用要素和决策提供了基础。完整的软件架构或其中的一部分，例如单个架构策略和决策，可以在利益相关者需要类似质量属性或功能的多个系统中重新使用，从而节省了设计成本并减轻设计错误的风险。
- 它支持影响系统开发，部署和维护寿命的早期设计决策。做出早期，高影响力的决定对于防止日程安排和预算超支很重要。
- 它促进了与利益相关者的沟通，从而为更好地满足他们需求的系统做出了贡献。从利益相关者的角度来沟通复杂系统，有助于他们了解其既定要求的后果以及基于他们的设计决策的后果。架构使在系统实施之前，在相对容易适应系统之前就可以进行有关设计决策的能力。
- 它有助于风险管理。软件架构有助于减少风险和失败的机会。
- 它可以降低成本。软件体系结构是管理复杂IT项目中风险和成本的一种手段。
历史
软件设计与（民用）体系结构之间的比较是在1960年代后期首次绘制的，但是“软件体系结构”一词直到1990年代才看到广泛使用。自计算机科学的形成以来，计算机科学领域遇到了与复杂性相关的问题。开发人员通过选择正确的数据结构，开发算法以及应用关注点的概念来解决早期复杂性问题。尽管“软件体系结构”一词对行业来说是相对较新的，但该领域的基本原理自1980年代中期以来由软件工程先驱偶尔应用。捕获和解释系统软件体系结构的早期尝试是不精确和混乱的，通常以一组盒子图为特征。
软件体系结构作为概念的起源于1968年的Edsger Dijkstra的研究和1970年代初的David Parnas 。这些科学家强调，软件系统的结构至关重要，并正确完成结构至关重要。在1990年代，有一致的努力来定义和编纂该学科的基本方面，研究工作集中于建筑风格（模式），建筑描述语言，体系结构文档和正式方法。
研究机构在促进软件体系结构作为纪律方面发挥了重要作用。卡内基·梅隆（Carnegie Mellon）的玛丽·肖（Mary Shaw）和戴维·加兰（David Garlan）在1996年写了一本书，题为《软件体系结构：关于新兴学科的观点：促进了组件，连接器和样式之类的软件体系结构概念。加利福尼亚大学，欧文大学的软件研究研究所在软件体系结构研究中的工作主要针对建筑风格，建筑描述语言和动态体系结构。
IEEE 1471 -2000，“软件密集型系统的架构描述的建议实践”是软件体系结构领域的第一个正式标准。它是2007年由ISO AS 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的系统定义包括在内，它不仅包含硬件和软件，还包括“人类，过程，过程，设施，材料，材料和自然发生的实体”，将其迈出一步。这反映了软件体系结构，企业体系结构和解决方案体系结构之间的关系。
建筑活动
软件架构师执行的活动有许多活动。软件架构师通常与项目经理合作，与利益相关者讨论架构上的重要要求，设计软件架构，评估设计，与设计师和利益相关者进行交流，记录建筑设计等等。软件体系结构设计中有四个核心活动。这些核心体系结构活动是在最初软件开发生命周期的不同阶段迭代和在系统演变上进行的。
架构分析是理解拟议系统将运行和确定系统要求的环境的过程。分析活动的投入或要求可以来自任何数量的利益相关者，并包括以下项目：
- 系统运行时系统将要做什么（功能要求）
- 系统将如何执行运行时的非功能要求，例如可靠性，可操作性，性能效率，安全性， ISO/IEC 25010 ：2011标准中定义的兼容性
- 非功能要求的开发时间，例如ISO 25010：2011标准中定义的可维护性和可传递性
- 可能会随着时间而变化的系统的业务需求和环境环境，例如法律，社会，财务，竞争和技术问题
分析活动的输出是那些对软件系统架构具有可测量影响的要求，称为建筑意义重大要求。
建筑综合或设计是创建体系结构的过程。鉴于由分析确定的建筑意义重大要求，设计的当前状态和任何评估活动的结果，设计并改进了设计。
架构评估是确定当前设计或部分的一部分满足分析过程中要求的过程的过程。每当建筑师考虑设计决策时，就可以进行评估，在设计的一部分完成后，可能会发生，它可能在最终设计完成后发生，或者在系统构建后可能发生。一些可用的软件体系结构评估技术包括架构权衡分析方法（ATAM）和TARA。比较技术的框架在诸如SARA报告和体系结构评论之类的框架中进行了讨论：实践和经验。
体系结构演变是维护和适应现有软件体系结构以满足需求和环境变化的过程。由于软件体系结构提供了软件系统的基本结构，因此其发展和维护必然会影响其基本结构。因此，体系结构的演变与添加新功能以及维护现有功能和系统行为有关。
建筑需要关键的支持活动。这些支持活动在整个核心软件体系结构过程中进行。它们包括知识管理和沟通，设计推理和决策以及文档。
支持活动的建筑
在核心软件体系结构活动期间，进行了软件架构支持活动。这些支持活动有助于软件架构师进行分析，综合，评估和进化。例如，建筑师必须在分析阶段收集知识，做出决策和文件。
- 知识管理和沟通是探索和管理对设计软件体系结构至关重要的知识的行为。软件架构师不孤立地工作。他们从各种利益相关者那里获得投入，功能和非功能要求以及设计环境；并向利益相关者提供产出。软件架构知识通常是默认的，并且保留在利益相关者的负责人中。软件体系结构知识管理活动是关于查找，沟通和保留知识。由于软件体系结构设计问题是复杂且相互依存的，因此设计推理的知识差距会导致不正确的软件体系结构设计。知识管理和沟通活动的示例包括搜索设计模式，原型制作，询问经验丰富的开发人员和建筑师，评估相似系统的设计，与其他设计师和利益相关者共享知识，以及在Wiki页面上记录经验。
- 设计推理和决策是评估设计决策的活动。此活动对于所有三个核心软件体系结构活动都是至关重要的。它需要收集和关联决策环境，制定设计决策问题，找到解决方案选项并在做出决策之前评估权衡。此过程发生在不同级别的决策粒度上，同时评估重要的体系结构需求和软件架构决策以及软件体系结构分析，综合和评估。推理活动的示例包括了解需求或设计对质量属性的影响，质疑设计可能引起的问题，评估可能的解决方案选项以及评估解决方案之间的权衡。
- 文档是记录软件体系结构过程中生成的设计的行为。使用多种视图来描述系统设计，这些视图经常包含静态视图，显示系统的代码结构，一个动态视图，显示了在执行过程中系统的操作以及显示如何将系统放置在硬件上进行执行的部署视图。 Kruchten的4+1视图提出了记录软件体系结构的常用视图的描述；记录软件体系结构：视图及以后的描述可以在视图描述中使用的各种符号。文档活动的示例是编写规范，记录系统设计模型，记录设计的理由，开发一个观点，记录视图。
软件架构主题
软件体系结构描述
软件体系结构描述涉及使用架构描述语言，体系结构观点和体系结构框架等机制建模和代表体系结构的原理和实践。
体系结构说明语言
架构描述语言（ADL）是用于描述软件体系结构的任何表达方式（ ISO/IEC/IEEE 42010 ）。自1990年代以来已经开发了许多特殊用途的ADL ，DAOP-ADL（由Málaga大学开发），SBC-ADL（由国立Sun Yat-Sen University开发）和Byadl（意大利L'Aquila大学）。
建筑观点
软件体系结构描述通常被组织成视图，这些视图类似于构建体系结构中所做的不同类型的蓝图。每个视图都按照其观点的惯例来解决一组系统问题，其中一个观点是一个规范，描述了在给定集的角度表达所讨论的架构中使用的符号，建模和分析技术利益相关者及其担忧（ ISO/IEC/IEEE 42010 ）。该观点不仅指定了问题（即要解决的问题），还指定了所使用的模型，所使用的惯例和任何一致性（通信）规则，以保持与其他视图一致的视图。
建筑框架
一个体系结构框架捕获了“惯例，原则和实践，以描述在利益相关者的应用和/或社区中建立的架构”（ ISO/IEC/IEEE 42010 ）。通常以一个或多个观点或ADL来实现框架。
建筑风格和模式
架构模式是在给定上下文中软件体系结构中常见问题的一般，可重复使用的解决方案。建筑模式通常被记录为软件设计模式。
遵循传统的建筑体系结构，“软件体系结构样式”是一种特定的构造方法，其特征是使其引人注目的功能（建筑风格）。
建筑风格定义了：结构组织模式的系统家族；组件和连接器的词汇量，对它们的结合方式有限制。
建筑风格是设计决策的“包装”，这些决策和约束都适用于建筑，以诱导所选理想的素质。
其中有许多公认的建筑模式和样式：其中：
- 黑板
- 客户端服务器（2层， 3层， n -tier ，云计算展示此样式）
- 基于组件
- 以数据为中心
- 事件驱动（或隐式调用）
- 分层（或多层体系结构）
- 微服务体系结构
- 整体应用
- 点对点（P2P）
- 管道和过滤器
- 插件
- 反应性架构
- 代表性国家转移（REST）
- 基于规则
- 面向服务
- 没有共享架构
- 空间架构
- 无服务器体系结构
有些人将建筑模式和建筑风格视为相同的，有些将样式视为模式的专业。他们拥有的共同点是模式和样式是构建建筑师使用的成语，它们“提供了一种通用语言”或“词汇”，以描述系统类别。
软件架构和敏捷开发
还担心软件体系结构会导致太多的大型设计，尤其是在敏捷软件开发的支持者中。已经开发了许多方法来平衡前期设计和敏捷性的权衡，包括敏捷方法DSDM ，该方法授权“基础”阶段，在此阶段，在此阶段中，“足够”的建筑基础是。 IEEE软件专门针对敏捷性和体系结构之间的相互作用。
软件体系结构侵蚀
软件体系结构侵蚀（或“衰减”）是指在实施中实现的软件系统计划和实际体系结构之间观察到的差距。当实施决策无法完全实现按计划的架构或以其他方式违反该体系结构的约束或原理时，就会发生软件架构侵蚀。
例如，考虑一个严格的分层系统，其中每一层只能使用紧接其下方的层提供的服务。任何不观察此约束的源代码组件都代表违反体系结构。如果没有纠正，这种违规会将架构转变为单片块，对可理解性，可维护性和可发展性产生不利影响。
已经提出了各种方法来解决侵蚀。 “这些方法，包括工具，技术和过程，主要分为三个一般类别，试图最大程度地减少，预防和修复体系结构侵蚀。在这些广泛类别中，每种方法都会进一步分解，反映了采用的高级策略应对侵蚀。这些是面向过程的体系结构符合，体系结构的演变管理，建筑设计执法，实现链接的体系结构，自我适应和体系结构恢复技术，包括恢复，发现和和解。”
有两种主要的技术来检测建筑违规：反射模型和特定于领域的语言。反射模型（RM）技术比较了系统架构师提供的高级模型与源代码实现。还有特定于域的语言，重点是指定和检查体系结构约束。
软件体系结构恢复
软件体系结构恢复（或重建或反向工程）包括方法，技术和流程，以发现软件系统架构中可用信息（包括其实施和文档）的方法。面对过时或过时的文档和架构侵蚀，通常需要进行架构恢复，以做出明智的决策：实施和维护决策与所设想的体系结构有所不同。存在将软件体系结构作为静态程序分析恢复的实践。这是软件情报实践所涵盖的主题的一部分。
相关字段
设计
建筑是设计，但并非所有设计都是建筑。实际上，建筑师是在软件架构（体系结构设计）和详细设计（非架构设计）之间划清界限的人。尽管有试图形式化区别，但没有适合所有案件的规则或准则。根据旨意/局部性假设，架构和详细设计之间的区别是由局部标准定义的，根据该标准，有关软件设计的陈述是非本地（架构）的，并且仅当且仅当满足其满足程序的情况下才能扩展到没有的程序。例如，客户端风格是架构（战略性的），因为基于此原则的程序可以扩展到不是客户端的程序（例如，通过添加点对点节点）。
需求工程
需求工程和软件体系结构可以看作是互补方法：当软件体系结构以“解决方案空间”或“如何”为目标时，需求工程旨在解决“问题空间”或“什么”。需求工程需要启发，谈判，规范，验证，文档和要求的管理。需求工程和软件架构都围绕利益相关者的关注，需求和愿望。
需求工程和软件体系结构之间存在很大的重叠，例如，通过对五种工业软件体系结构方法进行的研究证明了“输入（目标，约束等）通常是错误的定义，并且只发现或更好地定义被理解为架构开始出现， “尽管大多数架构问题是在系统上表示的，但它们也可以包括规定的设计决策” 。简而言之，所需的行为会影响解决方案体系结构，这又可能引入新的要求。诸如Twin Peaks模型之类的方法旨在利用需求与体系结构之间的协同关系。
其他类型的“体系结构”
- 无服务器体系结构
- 无服务器体系结构是一种云计算范式，通常被误解为无服务器。它本质上将服务器管理职责从开发人员转移到云服务提供商。这使企业可以在云基础架构上运行其后端代码，从而消除了对物理服务器管理的需求。无服务器体系结构的事件驱动方法依赖于按需执行的小型，特定于任务的功能。这些功能被称为服务（FAAS），它们通过付费计费模型和基于应用程序需求的动态资源扩展提供了成本效益。
- 系统体系结构
- “系统架构”一词最初已应用于由硬件和软件组成的系统体系结构。系统体系结构解决的主要关注点是将软件和硬件集成在完整，正确工作的设备中。在另一个更广泛的含义中，该术语适用于任何可能具有技术，社会技术或社会性质的复杂系统的架构。
- 企业架构
- 企业体系结构的目标是“将商业愿景和战略转化为有效的企业”。企业体系结构框架（例如Togaf和Zachman框架）通常会区分不同的企业体系结构层。尽管术语因框架而异，但许多术语至少包括业务层，应用程序（或信息）层和技术层之间的区别。企业体系结构在这些层之间的一致性通常以自上而下的方法来解决。