PDF静态分析工具的UI设计
使用SWAN评估工具设计指南
Daniil Tiganov，阿尔伯塔大学
Lisa Nguyen Quang Do，谷歌苏黎世
Karim Ali，阿尔伯塔大学
过去的研究表明，静态分析工具存在常见的可用性问题，例如误报率高、响应速度慢以及警告描述和分类不清晰。尽管这些工具变得越来越复杂，并且其行业使用范围也在扩大，但这些问题仍然突出。6,7,9,11,13,15,19,20
为了解决静态分析工具的可用性问题，Lisa Nguyen Quang Do等人20 提出了以用户为中心的方法，在分析开发过程中设计这些工具，而不是将分析开发与其 UI（用户界面）分开。为此，他们为分析工具的 UI 设计定义了 10 条指南。作者从现有文献以及他们对 Software AG 的 17 个静态分析工具和 87 位软件开发人员进行的研究中提取了这些指南。这些指南考虑了分析引擎要求、用户行为、报告平台以及公司政策对静态分析工具的使用和采用的影响。18
本文探讨了将这种以用户为中心的方法和设计指南应用于 SWAN26（一种针对 Swift 编程语言的安全静态分析工具）的效果。SWAN 正在积极开发中，以更好地集成到 Swift 开发工作流程中，提供更快、更精确的分析引擎和新的 UI。本文的目的是评估该方法和指南在提高下一版本 SWAN 的可用性方面的有效性。
创建 SWAN 是为了解决 Swift 缺乏公开可用的静态分析工具的问题。它为用户提供了 CLI（命令行界面）和 GUI（图形用户界面），以可视化其静态分析的结果。SWAN 的目标之一是在开发过程中提供即时分析结果，而不是像行业中经常做的那样，隔夜运行分析。9,15
SWAN 的多个要素使其成为探索静态分析工具可用性的有趣案例研究。首先，它拥有庞大的目标受众：所有 Swift iOS 开发人员（在本文的其余部分，术语Swift 开发人员和 iOS 开发人员 可以互换使用）。虽然这个用户群体涵盖了从大型组织到个体开发人员的不同概况，但 SWAN 的即时性、轻量级特性以及与 Swift 开发工作流程的紧密集成驯服了他们不同的需求。因此，各种类型的开发人员解决警告的方式非常相似，他们的 UI 要求也很相似。
其次，由于其提供即时结果的目标，SWAN 有潜力轻松集成到开发人员的工作流程中，从而在未来支持更多的用例和可用性测试。第三，SWAN 独立于现有的分析平台。因此，它的 UI 可以进行修改，而不会受到这些平台施加的外部约束，从而可以探索不同的 UI 设计。
分析 Swift 程序
Swift23 是一种开源编程语言，也是 Apple 推荐的用于在其移动操作系统 iOS3 和桌面操作系统 macOS4 上进行开发的语言。网络流量分析工具 StatCounter 估计，2019 年，iPhone 和 iPad 占全球移动设备的 24.79%，22 macOS 设备占台式机的 16.46%。21 趋势还表明，2020 年这两种操作系统的普及率分别增长了 4.41% 和 3.82%。因此，对 Swift 应用程序进行静态分析的能力对全球数百万用户具有重大影响。
尽管存在许多用于 Android 设备的静态分析框架（例如，FlowDroid、5 SCanDroid8 和 DroidInfer12），但 Swift 缺乏可比工具。虽然 LLVM16 和 Clang17 支持一些低级分析，但它们不适合对 Swift 应用程序进行更深入的分析，例如精确检测数据泄漏。这是因为在将 Swift 源代码编译为低级 LLVM IR 的过程中，特定于语言的结构和信息通常会丢失。此外，目前大多数可用于 Swift 的工具（例如，SwiftLint24 和 Tailor25）仅有助于执行 Swift 最佳编码实践。
SWAN 弥合了 Swift 日益普及与缺乏可用分析工具之间的差距。26 这种用于 Swift 的开源静态分析框架主要针对应用程序开发人员。它提供 CLI 和 GUI。CLI 使开发人员能够将 SWAN 集成到持续集成工作流程中，在主要的开发里程碑处提供分析结果。或者，开发人员可以使用 GUI 直接在 VSCode 中获得按需分析结果。28 这种相对即时的反馈有助于开发人员专注于手头的任务，从而帮助他们以更少的时间修复更多错误。14
图 1 显示了 SWAN VSCode 扩展的主要 GUI 元素。用户通过选择 SWAN 选项卡并在侧边栏中按下 运行污点分析 来启动 SWAN。然后，如果 SWAN 实例正在运行，扩展程序会自动附加到现有实例，如果没有任何实例正在运行，则启动一个新实例。对于图中的代码示例，SWAN 以文件树状形式在侧边栏中显示结果。每个易受攻击的路径都是树中的一个元素，用红色十字标记。它的子节点是路径中的节点。第一个子节点是源，最后一个是接收器，中间的任何节点都是中间节点。用户可以选择任何路径节点，扩展程序将在相应的源位置打开文件。在图中，用户选择了最后一个节点。因此，SWAN 在源文件中突出显示第 13 行，向用户显示受污染的数据作为参数到达函数 sink()。
设计指南
在过去的研究中，Nguyen Quang Do 等人20 研究了 Software AG 静态分析工具的使用情况，重点关注代码开发人员使用这些工具的动机（例如，工作环境、工具类型）、他们在面对常见可用性问题时的行为，以及内部创建的解决这些问题的策略。他们的研究跨越了 17 个分析工具、87 位开发人员和两个大型项目，其中包括一项开发人员调查以及对其中一个项目的分析结果和开发人员对这些结果的响应的研究。
该研究发现，时间限制是开发人员如何与静态分析工具交互的主要影响因素，因此也影响了他们用来优化工作的策略。例如，为了节省时间，44% 的参与者根据问题的类型将警告标记为误报，而没有进一步调查警告。同样，如果某些参与者不理解警告的描述，他们会忽略或抑制警告。在这两种情况下，不同的 UI 可能会帮助开发人员做出更好的决策（例如，通过提供已解决的类似警告的示例）。
因此，Nguyen Quang Do 等人定义了 10 条关于如何为静态分析工具创建 UI 的指南（在本文中称为 G1-G10），这些指南可以更好地支持开发人员。这些指南呼应了以前的研究中报告的可用性问题，稍后将详细介绍。
以下描述了这些指南，并指出了其中哪些指南适用于 SWAN。
G1 — 在设计 UI 流程时考虑时间限制
Nguyen Quang Do 等人发现，参与者主要在业余时间（例如，会议之间）使用静态分析工具，Carmine Vassallo 等人27 的研究也呼应了这一发现。由于时间限制是使用静态分析工具的主要动机，因此所有 UI 交互都必须在此背景下设计。例如，该工具可以帮助开发人员确定修复给定警告需要多长时间，并帮助他们规划工作。SWAN 的即时分析方法和与 Swift 开发工作流程的紧密集成可能会减少对此类基于时间的警告指标的需求。
G2 — 分析响应速度和工具界面应精心设计，以最大限度地减少等待时间
提交修复后等待警告更新是参与者报告的停止使用分析工具工作的主要原因之一。由于复杂的分析可能需要很长时间才能运行，因此修复过程可能会中断，将一个修复分散到多个调试会话中。此可用性问题也被报告为工作流程中断的原因。11,13,15 SWAN 的创建考虑了响应速度。它的 UI 可以设计为显示和更新即时警告，但这带来了挑战。
G3 — 将开发人员知识反馈到分析中
Nguyen Quang Do 等人20 和 Vassallo 等人27 的研究观察到，程序员开发了关于如何解释分析结果的启发式方法。例如，Software AG 工程师构建了关于哪些 API 调用分析处理不好的知识，并且他们驳回包含此类调用的警告。20 Istehad Chowdhury 和 Mohammad Zulkernine10 表明，此类分析弱点可能有助于区分真假阳性。因此，Nguyen Quang Do 等人提倡将开发人员知识反馈到分析中，以便所有其他用户都可以从中受益。SWAN 最初缺乏 API 安全建模可能会产生许多误报和误报；在这种情况下，开发人员可以采取一些步骤。
G4 — 提供具体的警告解释
正如过去的研究报告的那样，警告描述通常是通用的，并且需要安全漏洞或被分析项目的领域特定知识。6,11,13,15 这会使开发人员难以理解警告并弄清楚如何修复它们。Nguyen Quang Do 等人20 建议使警告尽可能具体到正在分析的特定代码段，并提供针对用户上下文的含义解释（例如，修复难度以及需要哪种知识）。由于 SWAN 旨在容纳所有开发人员，包括那些技术经验有限的开发人员，因此提供可理解的解释对于其采用至关重要。SWAN 最初将提供传统的解释，其中包含诸如类别、严重性、警告如何影响代码以及如何利用它以及如何在高级别修复警告等信息。本文稍后将提出评估 SWAN 解释有效性的建议。
G5 — 根据开发人员的知识协助开发人员提出建议
如 G4 中所述，修复警告需要特定的领域知识。由于分析工具可以访问修复历史记录，因此它们是为特定开发人员推荐特定警告或为特定警告推荐过去修复的理想角色。SWAN 首先需要在一个大型用户群中进行测试，以增加对如何开发和集成包含过去警告、修复和开发人员信息的知识库系统的理解。因此，本指南属于未来计划。
G6 — 提供协作选项
关于 G3 和 G5，Nguyen Quang Do 等人20 建议提供一个平台，用于共享开发人员知识和推荐可能拥有修复某些错误所需知识的开发人员。与 G5 一样，本指南需要一个知识库，稍后将在本文中讨论。
G7 — 鼓励良好的开发人员策略
在他们的研究中，Nguyen Quang Do 等人观察了他们在警告方面的行为策略。例如，他们创建启发式方法来区分真假阳性，或者他们对他们不理解的警告（例如，忽略、升级或抑制这些警告）默认采用某些行为模式。作者建议使用分析知识和集体开发人员知识来鼓励良好的策略（例如升级），并阻止更危险的策略（例如警告抑制）。SWAN 首先必须经过测试，以确定先前的指南是否不足以促进良好行为。本指南将在后面的未来计划部分中讨论。
G8 — 使用不同类型的分析工具来涵盖不同的方面
由于这是分析用户的责任，因此本指南被认为超出了 SWAN 的范围。
G9 — 为所有警告使用单个报告平台
与 G8 一样，集成不同的分析工具是分析用户的责任，因此，G9 也超出了 SWAN 的范围。但是，为了方便集成工作，SWAN 的下一个迭代版本可能会在 SARIF（静态分析结果交换格式）中包含导出选项。1
G10 — 通过政策执行和提高意识来促进分析工具的使用
SWAN 可以平滑集成到 git、构建和 IDE 中，从而使其更容易采用、配置和使用。这应该使开发人员更愿意采用 SWAN，这也将使通过公司政策执行其使用变得更容易。SWAN 还可以附带特定的政策建议和宣传材料，以帮助开发人员了解 SWAN 为他们提供的功能。但是，工具无法直接影响公司的政策，因此 G10 超出了本文的范围。
短期设计目标
现在让我们从 SWAN 的角度检查立即适用的可用性指南。
时间限制
G1 — 开发人员的时间有限。重要的是，他们在任务之间有很小的可用时间跨度。这是他们最愿意解决警告的时候。
Nguyen Quang Do 等人建议，“[分析] 工具可以为给定的时间跨度 [开发人员可以选择] 提出适合修复的警告。”换句话说，开发人员选择修复警告的期望时间跨度（例如，15 分钟或 30 分钟），然后分析工具提供一批在该时间跨度内修复的警告。
为了实现这一点，需要一种启发式方法来估计修复给定警告所需的时间。这种启发式方法应考虑多个因素，例如警告复杂性（例如，它流经多少文件和方法）、警告类型和开发人员经验。为了有效地选择警告，必须在它们的优先级（或严重性）与修复它们所需的时间之间取得平衡。开发这种时间估计启发式方法需要通过经验性的开发人员试验对其进行调整，这可能会包含在未来的试验中。如果通过立即修复来限制上游警告，从而减少对时间限制的强调，那么开发这种启发式方法可能不是优先事项。
SWAN 将促进立即修复并限制上游出现的警告数量。上游状态仍然可以查看未解决的警告。此外，SWAN 以安全性为重点，因此任何出现的警告都不应被忽略，这通常是通用错误或代码风格问题的情况。
Swift 开发工作流程的性质以及 SWAN 如何通过构建系统集成到工作流程中，使其能够在开发人员积极开发应用程序时快速查找警告。开发人员在开发过程中必须修复的警告数量预计足够少，可以立即修复。因此，在这方面，解决时间限制的重要性可能会大大降低。
但是，有两种主要方法可以一次引入许多警告，这可能需要时间估计。首先，当开发人员首次在代码库上运行分析时，SWAN 可能会发出许多开发人员无法立即解决的警告。其次，每当 SWAN 的分析在新版本中发生更改时，由于新的警告支持，它可能会产生许多新警告。未来的计划包括探索如何评估 SWAN 是否以及在多大程度上会产生开发人员必须在有限时间内解决的警告积压。这将有助于确定是否以及在多大程度上需要进行时间启发式方法的开发。
此外，当开发人员工作时，他们可能不想立即解决警告，因为他们专注于编码并且很忙。在这种情况下，时间估计也可能有所帮助。一个粗略的估计可能就足够了。SWAN UI 还可以提供一个方便的按钮，提示日历事件，其中包含警告信息和时间估计，以便开发人员可以分配时间稍后解决警告——因此，立即处理警告而不是忽略它。
该研究领域的下一步将是研究开发人员如何使用 SWAN 来确定将哪些指标纳入时间估计。这些指标的范围可以从开发人员对给定类型警告的经验到代码库的大小再到一天中的时间。此类指标对时间估计的影响可能因开发人员而异，但由于 SWAN 专注于非常具体的代码警告，因此这些不确定性可能会受到限制。
响应速度
G2 — 开发人员不喜欢等待分析工具，尤其是在他们有时间限制的情况下。分析响应速度和工具界面应精心设计，以最大限度地减少等待时间。
Swift 应用程序遵循基于模块的设计，其中每个用户（非包）模块通常都足够小，可以被 SWAN 快速分析。用户的代码可能分布在多个模块中，所有包都作为模块包含在内。
Swift 库不以二进制形式分发，因此可以由 SWAN 与用户代码一起分析。SWAN 的新基础设施正在设计为单独处理这些模块并自动将它们链接在一起。因此，在重建时，SWAN 不需要重新分析所有模块，而只会处理更改的模块。然后，SWAN 将它们与来自先前构建的缓存模块链接，以获得完整的数据流信息。通过这种设计，SWAN 为每个后续构建提供快速的迭代分析。
关于 UI，SWAN 旨在在开发人员工作时提供即时反馈。轻量级分析将在他们每次构建应用程序时运行，他们应该在 IDE 中收到警告更改通知。但是，并非所有 IDE 都提供插件支持。2 因此，插件不应被视为创建 SWAN 主要 UI 的手段，但目标是实现 IDE 集成，至少可以通知用户新警告。详细的警告信息将在 SWAN 的专用（主要）UI 中提供，该 UI 将是桌面或基于 Web 的应用程序。
开发人员应该能够轻松地判断他们的更改对当前警告列表有何影响——即，他们的更改是否已解决或引入了警告。SWAN 可以在专用 UI 中提供多个列表，以帮助开发人员了解他们的更改：与最新提交不同的警告（类似于 git）以及与先前构建不同的警告，包括每个先前构建中的警告状态。前面提到的 IDE 通知也可以类似地配置为显示来自最新提交或构建的更改。SWAN UI 的未来工作的一部分将努力设计和测试可以显示实时更新而不会使用户感到困惑的不同功能。该系统将在稍后关于鼓励良好行为及其在 SWAN 未来计划部分中的评估中进一步讨论。
可自定义的启发式方法
G3 — 开发人员应该能够使用自己的规则或启发式方法配置分析工具，以便在必要时使其适应自己的需求。
Swift 开发人员使用各种包（即库或 API）。Swift 构建系统的一个主要优点是所有非 Apple/专有包都包含在源代码中。这意味着不必对通过这些包的基本数据流进行建模，但必须对它们的安全性行为进行建模。由于 SWAN 目前没有资源来支持所有常见的 API，因此缺少一些安全信息，例如哪些 API 方法是源、接收器或消毒器。但是，在发布之前，SWAN 至少会对 Swift 标准库进行建模。
不可避免地，开发人员会发现某些警告是误报（例如，当缺少消毒器时）或误报（例如，当缺少源或接收器时）。SWAN 将提供两种方式，开发人员可以同时调整其本地分析以最大限度地减少这些不正确的警告，并通知 SWAN 开发人员不正确的行为。
首先，在误报的情况下，开发人员可以创建关于缺少行为的简短报告，包括有问题的 API 方法、其正确的行为（源、接收器或消毒器）以及可选的简短描述。这将自动为分析引擎中的 API 方法赋予所需的行为，并将报告发送给 SWAN 开发人员。
其次，他们可以创建关于特定警告的类似报告，但在这种情况下，将自动提供更多报告信息。发送给 SWAN 开发人员的报告中不会包含用户代码。通过这些选项，开发人员可以继续使用 SWAN 而不抑制警告，并且 SWAN 团队可以调整 SWAN 以在下一个版本中获得更好的支持。
通过此报告数据，SWAN 开发人员可以构建一个关于开发人员启发式方法的实质性知识库。一旦对这些启发式方法进行分类，就可以使用更详细的 UI 来改进 SWAN 的初始错误报告系统，供软件工程师输入不同类型的启发式方法，并将这些启发式方法自动反馈到分析引擎中。这将需要在不同类型的启发式方法应如何以及何时影响分析引擎方面进行进一步研究。
讨论和未来计划
虽然某些设计指南立即适用于 SWAN，但其他指南则不适用。本节讨论了后者，以及评估 SWAN 可用性的未来计划。
警告积压
SWAN 专注于最大限度地减少开发人员不立即解决的警告数量，方法是紧密集成到他们的工作流程中，并提供简单的方法来理解他们的更改引起的警告。但是，可能会突然引入许多警告，开发人员最终将不得不处理这些警告。SWAN 团队需要评估这种情况是否以及在多大程度上发生。事实证明，一旦开发人员修复了初始警告集，就很少需要使用时间估计 (G1)、推荐器 (G5) 或协作 (G6) 系统。这将降低这些指南对 SWAN 的相关性。警告解释 (G4) 也可以在帮助开发人员立即解决警告方面发挥重要作用。因此，在未来的试验中，SWAN 开发人员计划分析有多少警告未解决，以及警告解释在这一结果中起什么作用。
鼓励良好行为
前面关于 G2 的部分讨论了在开发人员工作时出现的 IDE 警告通知，以提高响应速度。这是开发人员决定是否处理警告的关键时刻。因此，至关重要的是，开发人员不要忽略重要的警告（我们认为所有安全警告都很重要），并且有清晰的信息来帮助他们解决警告。时间估计和良好的警告解释可以帮助实现这一目标，但这可能还不够，因此应探索鼓励良好行为 (G7) 的其他方法。例如，SWAN 专注于安全性，并将产生许多可以通过将数据传递到消毒 API 来快速解决的警告。对于这些警告，“快速修复”选项可能是可能的，尽管缺乏 IDE 插件支持可能会使这变得困难。SWAN 试验可以帮助评估开发人员是否以及为什么不立即解决警告，并导致确定哪些策略可以改进或添加到鼓励良好行为中。
知识库
以下指南要求 SWAN 具有知识库，其中包含诸如过去警告、修复和开发人员信息等信息。在开发此类系统之前，必须在一个重要的用户群中测试 SWAN，以查找哪些数据可用于记录和使用。
G5 — 警告消息和推荐系统应考虑开发人员的知识和可用时间。
个性化的警告消息可能有助于开发人员更有效地解决警告。如前所述，在计算警告时间估计值时应考虑开发人员知识，这些估计值包含在警告消息中。此外，警告消息应建议可以帮助开发人员解决警告的人员，例如团队成员。该消息应推荐有解决类似警告经验、曾在警告流经的代码库部分工作过或已自我认定为特定警告类型或类别的专家的开发人员。
G6 — 用户应具有协作解决警告的方法，例如通过消息传递系统，他们可以在其中就特定警告进行交流。
UI 应提供一种关于警告进行交流的手段，例如聊天系统。它应提供一种启动关于警告的对话的方式，然后开发人员应该能够标记建议的开发人员以寻求帮助。这些对话的存档应提供给所有开发人员，以便他们可以阅读以前关于他们被分配的警告的对话，然后再寻求帮助。对话存档还可以稍后提供关于开发人员最难以解决（寻求帮助）的警告、开发人员具体不理解的内容以及他们获得帮助的速度的见解，以便提高工具的可用性。警告消息中应包含指向相关对话的快速链接。
未来用户研究
为了评估下一代 SWAN UI，该团队计划进行多项用户研究。特别是，识别开发人员工作流程中的集成点将有助于理解如何自动化分析工具并最大限度地减少干扰。此外，深入探索 UI 设计和布局，并结合行业静态分析工具 UI 的具体示例，将有助于设计新的 SWAN UI。结合 Nguyen Quang Do 等人的工作，未来的可用性研究将提供对 SWAN 的全面理解。
参考文献
1. Anderson, P. 2018. 静态分析结果：一种格式和一种协议：SARIF & SASP。GrammaTech 博客； https://blogs.grammatech.com/static-analysis-results-a-format-and-a-protocol-sarif-sasp。
2. Apple Developer. 2021. Xcode； https://developer.apple.com/xcode/。
3. Apple iOS Team. 2007. iOS 14； https://www.apple.com/ca/ios/。
4. Apple macOS Team. 2001. macOS Big Sur； https://www.apple.com/ca/macos/mojave/。
5. Arzt, S., Rasthofer, S., Fritz, C., Bodden, E., Bartel, A., Klein, J., Le Traon, Y., Octeau, D., McDaniel, P. D. 2014. FlowDroid：用于 Android 应用程序的精确上下文、流、字段、对象敏感和生命周期感知污点分析。在第 35 届 SIGPLAN 编程语言设计与实现会议 (PLDI) 论文集中，259—269； https://doi.org/10.1145/2594291.2594299。
6. Ayewah, N., Pugh, W., Hovemeyer, D., Morgenthaler, J. D., Penix, J.,2008. 使用静态分析查找错误。IEEE 软件 25(5), 22—29； https://doi.org/10.1109/MS.2008.130。
7. Ayewah, N., Pugh, W. 2008. 关于静态分析用户调查和研究的报告。在大型软件系统缺陷研讨会论文集中； https://doi.org/10.1145/1390817.1390819。
8. Azim, T., Neamtiu, J. 2013. Targeted and depth-first exploration for systematic testing of Android apps. 载于 SIGPLAN 面向对象程序设计系统、语言与应用会议 (OOPSLA)论文集, 编辑：A. L. Hosking, P. Th. Eugster, 和 C. V. Lopes, 641—660; https://doi.org/10.1145/2509136.2509549.
9. Bessey, A., Block, K., Chelf, B., Chou, A., Fulton, B., Hallem, S., Henri-Gros, C., Kamsky, A., McPeak, S., Engler, D. 2010. A few billion lines of code later: using static analysis to find bugs in the real world. 通讯 53(2), 66—75; https://doi.org/10.1145/1646353.1646374.
10. Chowdhury, I., Zulkernine, M. 2010. Can complexity, coupling, and cohesion metrics be used as early indicators of vulnerabilities? 载于 应用计算研讨会论文集, 1963—1969; https://doi.org/10.1145/1774088.1774504.
11. Christakis, M., Bird, C. 2016. What developers want and need from program analysis: an empirical study. 载于第 31 届 IEEE/ 自动化软件工程国际会议论文集, 332—343; https://doi.org/10.1145/2970276.2970347.
12. Huang, W., Dong, Y., Milanova, A., Dolby, J. 2015. Scalable and precise taint analysis for Android. 载于软件测试与分析国际研讨会论文集, 编辑：M. Young 和 T. Xi, 106—117; https://doi.org/10.1145/2771783.2771803.
13. Johnson, B., Song, Y., Murphy-Hill, E., Bowdidge, R. 2013. Why don't software developers use static analysis tools to find bugs? 载于国际软件工程会议论文集, 672—681; https://dl.acm.org/doi/10.5555/2486788.2486877.
14. Kersten, M., Murphy, G. C. 2006. Using task context to improve programmer productivity. 载于第 14 届 SIGSOFT 国际软件工程基础研讨会论文集, 1—11; https://doi.org/10.1145/1181775.1181777.
15. Lewis, C., Lin, Z., Sadowski, C., Zhu, X., Ou, R., Whitehead, E. J. 2013. Does bug prediction support human developers? Findings from a Google case study. 载于第 35 届国际软件工程会议, 372—381. IEEE; https://doi.org/10.1109/ICSE.2013.6606583.
16. LLVM Developer Group. 2003. The LLVM compiler infrastructure; https://llvm.net.cn/.
17. LLVM Developer Group. 2007. Clang: a C language family front end for LLVM; https://clang.llvm.net.cn/.
18. Nguyen Quang Do, L. 2019. User-centered tool design for data-flow analysis. 博士论文. 帕德博恩大学; https://doi.org/10.17619/UNIPB/1-820.
19. Nguyen Quang Do, L., Ali, K., Livshits, B., Bodden, E., Smith, J., Murphy-Hill, E. R. 2017. Just-in-time static analysis. 载于第 26 届 SIGSOFT 国际软件测试与分析研讨会论文集. 307—317; https://doi.org/10.1145/3092703.3092705.
20. Nguyen Quang Do, L., Wright, J. R., Ali, K. 2020. Why do software developers use static analysis tools? A user-centered study of developer needs and motivations. IEEE 软件工程汇刊 (6 月 24 日). IEEE; https://ieeexplore.ieee.org/document/9124719.
21. StatCounter GlobalStats. 2019. Desktop operating system market share worldwide; https://gs.statcounter.com/os-market-share/desktop/worldwide/#monthly-201901-201912.
22. StatCounter GlobalStats. 2019. Mobile operating system market share worldwide; https://gs.statcounter.com/os-market-share/mobile/worldwide/#monthly-201901-201912.
23. Swift. 2015. The Swift Programming Language; https://swift.org/.
24. SwiftLint. 2015. A tool to enforce Swift style and conventions. GitHub; https://github.com/realm/SwiftLint.
25. Tailor. 2015. Cross-platform static analyzer and linter for Swift. GitHub; https://github.com/sleekbyte/tailor.
26. Tiganov, D., Cho, J., Ali, K., Dolby, J. 2020. SWAN: A static analysis framework for Swift. 载于第 28 届 欧洲软件工程会议暨软件工程基础研讨会联合会议论文集, 1640—1644; https://doi.org/10.1145/3368089.3417924
27. Vassallo, C., Panichella, S., Palomba, F., Proksch, S., Zaidman, A., Gall, H. C. 2018. Context is king: the developer perspective on the usage of static analysis tools. 载于IEEE 第 25 届软件分析、演化与再工程国际会议论文集, 38—49. IEEE; https://doi.org/10.1109/SANER.2018.8330195.
28. Visual Studio. 2015. Visual Studio Code — Code editing. Redefined; https://vscode.js.cn.
Daniil Tiganov 是阿尔伯塔大学的计算机科学专业的学生。他是 SWAN 项目的主要贡献者。
Lisa Nguyen Quang Do 是苏黎世谷歌的软件工程师。她于 2019 年在帕德博恩大学获得博士学位。她的研究重点是通过优化分析算法、实现其框架以及提高其界面的可用性等不同方面，来提高代码开发人员和分析开发人员的分析工具的可用性。
Karim Ali 是阿尔伯塔大学计算机科学系的助理教授。他的研究兴趣在于编程语言，特别是在程序分析工具的可扩展性、精确性和可用性方面。他的工作范围从开发可扩展且精确的程序分析新理论到程序分析在安全和即时编译器中的应用。
版权所有 © 2021，所有者/作者持有。出版权已许可给 。
最初发表于 Queue vol. 19, no. 4—
在 数字图书馆 中评论这篇文章
更多相关文章
Catherine Hayes, David Malone - 质疑非加密哈希函数的评估标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。加密哈希存在许多由各种安全需求驱动的标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对现实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉接受，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过介绍使用基于代码、低代码和极端低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。低代码技术已清晰地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性以及未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。为了快速前进，它容易受到时尚潮流的影响，并且可能会忘记或忽略某些它面临的永恒问题的成熟解决方案。用例于 1986 年首次引入，后来得到普及，就是这些成熟的解决方案之一。
© 保留所有权利。