软件开发参考文献-议论文写法的参考+文献

1 简介

架构评估是决策过程中的一个里程碑。 它旨在证明架构设计决策满足系统质量要求的程度，尤其是在面临操作不确定性和不断变化的需求时。 评估有助于及早识别和减轻设计风险； 这种努力通常是为了节省集成、测试和演化成本。 开创性工作的示例包括体系结构权衡分析方法 (ATAM) 和成本收益分析方法 (CBAM)。

在物联网和云应用程序等动态和非静态环境中运行的软件架构需要对其评估方式进行根本性转变。 这是由于不可预见的因素可能影响评估，包括（但不限于）QoS 波动、多租户、超连接、传感器老化效应等。

虽然现有的设计时评估方法承诺在不确定的情况下灵活地评估架构及其对实施变化的响应，但它们通常在高度动态的环境中受到限制，因为架构师的潜力不能仅依赖于在设计时评估的新场景。 此类场景需要运行时评估来通知和校准设计时决策。 在这方面，更连续的方法将有助于评估过程。 我们将持续的软件架构评估定义为对软件架构的多次评估，这些评估从开发的早期阶段开始，并在软件系统的整个生命周期中定期重复。 持续评估是连续或偶尔进行的，涵盖一个功能（例如 QoS）或多个功能。

有许多研究旨在评估软件架构以处理可能隐式或显式采用连续方法的不确定性。 该领域吸引了广泛的研究人员和从业者。 然而，持续评估不被认为是软件架构研究的关键领域。 对于持续软件架构评估方法的要素，我们仍然缺乏清晰的愿景。

在过去的几年中，许多研究回顾了设计时架构评估方法，而一些研究试图回顾运行时方法，而不是从持续架构评估的上下文中解决它们。 特别是，到目前为止，还没有系统的文献回顾软件体系结构不确定性评估方法，这些方法可能隐含或明确地采用连续方法。 系统文献综述（systematic literature review，SLR）是一种方法论手段，用于总结实证研究，系统地调查研究课题，回答特定的研究问题，并最终确定研究课题的差距和研究方向。

本研究的目的是 (i) 提供一个基本的分类方案，用于在不确定性下对软件架构评估方法进行分类； 分类; (iii) 确定制定持续评价方法的必要标准； (iv) 确定不确定环境中未来软件架构研究的当前差距和方向，我们在其中考虑设计和运行时评估，同时考虑系统将/正在运行的环境中可能存在的不确定性。 具体来说，我们的目标是为以下研究问题提供答案：

(1) 如何对当前不确定性下的软件架构评估研究进行分类，目前与该分类相关的最新方法有哪些？ 目标是在不确定性下对现有的体系结构评估方法进行分类，并在该分类法下对最先进的方法进行分类。

(2) 这些架构评估方法采取了哪些措施来应对不确定性？ 这个问题的目的是展示和讨论现有方法如何处理不确定性，以及这些行为是否有助于开发更连续的方法。

(3) 软件架构不确定性评估的当前趋势和未来方向以及持续评估的考虑因素是什么？ 本期旨在展示研究人员和从业人员在开发持续评估方法时如何从现有方法中获益，以从中获得灵感并满足基本需求。

2 系统的文献综述过程

在本节中，我们将讨论 SLR 协议、系统审查过程的工作原理，最后讨论与标准和审查目标相关的现有体系结构评估方法。

2.1 单反协议

在制定我们的审查协议时，我们遵循了系统文献审查和参考工作的指南和程序。 特别是，该协议定义了审查的目标、必要的背景、研究问题、纳入和排除标准、搜索策略、数据提取和收集数据的分析。 一位作者制定了审查协议，然后其他作者修改了结果以限制偏倚。

2.2 纳入和排除标准

我们在下面提供了包含和排除标准的摘要。 如果出版物符合第 2.2 节中的所有纳入标准，则它们将被纳入。 如果出版物符合第 2.2 节中的任何排除标准，则被排除在外。

2.2.1 纳入标准。

• 1990 年至 2020 年初发表的研究。

• 软件架构评估领域的研究。 特别是，该研究应将软件体系结构评估方法作为其贡献之一。

• 讨论架构评估方法的研究，明确关注高层架构设计（例如，组件级别、样式、架构设计决策和策略），包括设计、运行时和持续评估； 我们排除了对低级结构）方法的讨论。

•关于软件架构的定量分析/模型支持评估的报告研究（例如，效用理论作为 ATAM 的一部分；成本效益分析作为 CBAM 的一部分）

2.2.2 排除标准。 没有明确考虑架构评估的研究。 例如，一些自适应系统研究可能会利用架构评估来告知自适应，但可能不会明确将其称为架构评估，因此这些研究被排除在外：

• 未经同行评审的研究。

• 研究报告不是用英文写成的，无法完整阅读。

2.3 搜索策略

执行搜索策略以通过以下方式识别研究：

(1) 应用初步搜索来识别当前的系统评价和映射研究软件开发参考文献，以识别显着相关的原始研究。

(2) 使用 Zhang 和 Babar 提出的“准黄金”标准的概念，我们对软件架构和软件工程领域进行手动扫描，以交叉检查自动搜索结果。

(3) 从评价的主要目的（即，从公认的书目数据源自动检索），使用不同的关键词组合进行多次试验。

(4) 进行了额外的搜索以手动检查和分析相关参考文献（滚雪球法）以确保我们没有遗漏任何重要研究，从而保证具有代表性的研究集。

2.4 搜索执行

在这个阶段，我们执行了图 1 中的搜索过程，实现了第 2.3 节中的过程。 最初，我们手动搜索了当前的系统评价和映射研究，以确定显着相关的主要研究（13 个结果）。 然后，我们进行了手动搜索（17 个结果）以确定要与自动搜索列表（即“准黄金”标准）进行比较的研究集。 之后，我们搜索了第 2.3 节中提到的所有搜索引擎和书目来源。

2.5 质量评估

为了评估研究结果的质量，我们采用了与参考文献中使用的类似的质量标准。 在分析结果时，以下标准显示了个别研究的可信度：

(1) 本研究为他们的实验评估和数据分析提供了证据或理论推理，而不是依赖于不合理或临时的陈述。

图 1 搜索执行

(2) 本研究描述了进行本研究的背景。

(3) 研究的设计和实施与研究目标相一致。

(4) 本研究全面描述了他们的数据收集过程。

上述检索中确定的所有 48 项研究均符合质量评估标准。

表1 各数据库检索结果及纳入研究摘要

请注意，每个数据库列出的纳入研究数量不包括先前数据库中已纳入的研究。 总共包括 48 项独特的研究。

表 2 数据提取标准

2.6 数据提取过程

在此过程中，我们对包含的 48 篇论文进行了全面扫描以提取相关数据，这些数据使用 Excel 电子表格和书目管理工具 BibTeX 进行管理。 48 项研究的数据提取由表 2 中所示的格式和第 4.1 节中的分类框架驱动。 对于数据分析，我们调查了提取数据之间的关系。 此过程的结果将在后续部分中介绍。

3 纳入研究概述

在这里，我们概述了所纳入的研究、它们在出版渠道中的分布以及它们在过去几年中的排名。

3.1 研究报告的发布渠道

大多数纳入的研究（即 48 项研究）发表在最著名和最负盛名的期刊和会议上。 在表 3 中，我们概述了纳入研究的发表渠道和每个渠道的研究数量。 我们根据质量评估标准检查了纳入的研究，并确认它们确实符合第 2.5 节中描述的质量标准。 我们还在图 2 中绘制了纳入研究相对于出版渠道（即会议、期刊等）的分布。 从这些结果中，我们发现大量研究发表在会议上（约 62%）软件开发参考文献，其次是发表在期刊上的研究较少（19%）。 有限的研究发表在研讨会（约 13%）和书籍（约 6%）中。 这表明该体系结构评估方法是可行的。

表 3 纳入研究分布及发表渠道

3.2 历年纳入研究分布

如图 3 所示，按出版年份分析研究，我们观察到从 2003 年到 2013 年软件架构评估领域的增长趋势（有一些振荡）。尽管在过去四年中对架构评估的兴趣似乎有所下降，但一些最近的研究为架构评估提供了新方法，这些方法包含在本调查中。

3.3 纳入研究的引用率

我们在表 4 中列出了从 Google 获得的纳入研究的引用率。学者引用率未用于比较研究； 相反，我们用它来粗略估计纸张质量。

图2 发布类型分布

图3 各年出版类型分布

表 4 纳入研究的引用率汇总

特别是，不到 10 个来源引用了近 5 个研究。 其中两个在 2004 年和 2010 年被引用，因此我们预计它们不会被进一步引用，而其他的则相对较新。 近 45% 的研究（21 篇出版物）被 10-50 个其他来源引用，5 项研究被引用 50-100 次。 14 项研究的引用率非常高，超过 100 次，排名第一的研究获得了近 1578 次引用。 这表明，总体而言，纳入的研究被高度引用，表明它们的质量和影响。 在表 5 中，我们列出了被引用次数最多的出版物。 第一项研究是一本书，其余的是期刊和会议论文。

表 5 列出了 100 多项被引用次数最多的研究

4 数据提取结果

本节旨在回答第一和第二个研究问题：（1）如何对不确定性下软件体系结构评估的当前研究进行分类，以及与此分类相关的当前最先进的方法有哪些？ (2) 这些架构评估方法采取了哪些措施来应对不确定性？ 我们对每项研究中涉及的研究主题的分析以及对文献中发现的系统回顾和调查帮助我们制定了以下分类学框架。 这种分类法帮助我们过滤、映射和理解架构评估的领域。 我们还讨论了包含的评估方法如何处理不确定性。

图 4 提出的架构评估方法的分类

4.1 分类框架

接下来，我们将详细解释图 4 中显示的标准。

(1) 质量评估：体系结构评估通常作为里程碑审查来完成，以证明体系结构设计决策满足质量要求及其权衡的程度。 评估有助于及早识别和减轻设计风险。 它的重点是避免错误的决策并确定稳定的架构，以节省集成、测试和演化成本，这些成本可归因于不太适合适应变化的设计决策。 我们回顾了评估阶段，包括设计阶段、运营阶段和延续阶段，以及评估方法，包括基于实用程序、基于场景、基于参数、基于搜索、基于经济学和基于学习的主要工作。

(2) 质量属性考虑：我们的文献综述旨在展示所研究的软件架构评估方法如何处理质量属性（即关注单个和多个 QA），以及支持的质量属性是什么。 质量属性的例子有性能、可靠性、安全性、成本等。对质量属性的进一步监控和处理是需要讨论的一个重要方面，它可以为架构师和架构评估人员提供设计持续架构评估框架所需的元素。

(3)自治级别：在软件架构评估中，自治级别是设计持续架构评估框架的一个重要方面。 在这方面，我们回顾了这些研究如何管理利益相关者的投入和相互冲突的需求之间的权衡。

(4) 不确定性管理：在这个类别中，我们关注不确定性的来源以及文献如何处理它。

在第 4.2 至 4.5 节中，我们旨在为上述综述研究问题提供答案。 我们将架构评估方法分为设计时和运行时。 在每个类别中，我们进一步分类和解释与框架相关的现有架构评估方法（回答研究问题 1）。 我们还讨论了这些架构评估方法为处理不确定性所采取的行动（回答研究问题 2）。

4.2 质量评价

4.2.1不确定条件下的评价方法。 架构评估方法可以采用多种形式：这些方法可以定制，为架构师提供阶段和系统指导，以评估架构满足其非功能目标和权衡的程度，例如 ATAM、CBAM 等。此外，架构师可以使用通用框架进行质量评估，该框架可用于评估正在考虑的任何人工制品，软件架构可以从中受益。 无论使用何种评估类型，架构师都可以使用以下常用方法之一来评估存在不确定性的架构设计决策和选择。 常用的方法可分为基于效用的方法、基于场景的方法、基于参数的方法、基于搜索的方法、基于经济学的方法和基于学习的方法。

4.2.2. 评估阶段。 评估可以发生在设计时和/或运行时。 设计时评估发生在系统部署之前，涉众更多地参与对所研究系统的推理，而运行时评估方法使用运行时模拟数据（例如，QoS）来捕获架构决策在不确定性下的动态行为，并利用这些信息在原型设计阶段或部署后分析或评估设计决策。

4.3 质量属性注意事项

4.3.1 解决质量属性问题。 有侧重于单个或多个质量属性的评估方法。 基于这些结果，我们发现大多数软件架构评估研究都针对多个质量属性，例如，可移植性和可扩展性的可修改性、成本的稳定性。

4.3.2 支持质量属性。 我们将支持的质量属性分为通用属性和特定属性。 一般来说，我们考虑讨论支持任何质量属性（如性能、可用​​性、可靠性等）的文献。

4.3.3 质量属性的监控和处理。 该标准与运行时和连续评估方法有关，其中质量属性值由运行时监控或预测确定。

4.4 自治级别

4.4.1 利益相关者参与评估管理。 此类别进一步分为人类依赖型、半自主型和自主型。 我们必须区分：(i) 人为依赖（即完全依赖利益相关者评估候选架构选项的行为）； (ii) 半自主架构评估过程，例如，利益相关者和架构师在循环评估中交互； (iii) 自主（即评估是自主进行的，无需人工干预）。 为了进一步阐明这些类别，我们考虑自适应系统 (SAS) 中的架构评估案例：存在依赖于人类的架构设计决策（例如是否引入自适应机制）、半自主（例如人类参与系统）； 和自主架构设计决策（例如 SAS 在运行时调整和部署组件到不同的服务器）。 使用自主架构设计决策的另一个例子是结合智能和学习机制、进化计算等，以协助决策的自动评估。 持续的架构评估可以监控 QA 并从候选选项池中重新配置，其中一些已被确定为技术上可行，但需要进一步分析和验证。

4.4.2 权衡管理。 选择最佳架构决策的一个常见问题是权衡管理。 例如，有关传感器的架构决策可以提供较长的响应时间，但能源效率较低。 因此，一个目标可能是选择一个同时满足这两个质量属性的架构决策。 权衡管理有两种类型：手动和自动。 手动管理意味着使用需要人工干预的工具或技术，而自动管理意味着使用参数模型、自动选择或候选名单来权衡候选人。

4.5 不确定性管理

4.5.1 不确定性来源。 架构可能会经历两种不确定性来源：假设的和认知的。 摘要：不确定性的假设概念是指不确定性源于随机事件可能实现的可变性，即在相似条件下每次进行实验都可能出现未知的不同结果； 不确定性的认知概念 指由于对事实缺乏信心或对该事实缺乏正确或错误的认识而导致的不确定性增加。 我们根据不确定性来源分析了这些作品。

4.5.2 不确定性的处理。 在研究文献中，存在处理显式或隐式不确定性的方法。 显式方法将不确定性作为主要关注点，而其他方法没有提及不确定性，但它们的工具和技术可以用来处理不确定性。

5 结论

我们进行了系统的文献回顾，以检查处理设计时或运行时不确定性的现有架构评估方法。 我们还就开发和实施持续架构评估方法的必要要素提供指导。 我们对著名的软件架构和工程、其他相关系统审查和映射研究以及重要的书目数据源进行自动和手动搜索。 此外，我们采用滚雪球过程来收集我们的初步研究。

我们的发现如下：(a) 设计时架构评估方法比运行时评估方法受到更多关注，尽管后者对于处理软件系统中的动态和日益复杂的问题越来越重要；(b) 缺乏示例演示如何实施和实施持续评估方法； (c) 很少有方法侧重于在运行时管理收益和成本之间的权衡； (d) 很少有方法侧重于采用机器学习技术进行评估； (e) 大多数运行时方法往往是反应性的。

总之，我们建议该领域未来的工作机会如下：(i) 采用基于经济学的方法（即预测复杂架构决策的长期价值）； (ii) 采用基于经济学原理，因为它在不确定性下具有灵活性； (iii) 进行额外的研究，分析机器学习技术的使用，以改进运行时的体系结构评估（持续评估方法的连续阶段）；(iv) 调查体系结构评估过程中计划的发展； (v) 探讨调整正在进行的评估的输入参数（例如，对变化的敏感性、监测间隔、当前/过去数据的相对重要性）如何影响评估，以及哪些参数最适合改进决策； (vi) 分析持续架构评估在物联网和云系统等动态环境中的使用。

谢谢

本文由南京大学软件学院2021级研究生冯子扬翻译，肖元审校。