七个软件打包生态系统中依赖体系演化的实证比较外文翻译资料

 2022-12-29 01:12

本科毕业设计(论文)

外文翻译

七个软件打包生态系统中依赖体系演化的实证比较

作者:Alexandre Decan、Tom Mens、Philippe Grosjean

国籍:德国

出处:Springer Science Business Media, LLC, part of Springer Nature 2018

几乎每种流行的编程语言都有一个或多个包管理器。这些软件包形成了大型软件的生态系统。这些打包生态系统包包含着大量的定期更新的发行版的包,这些发行版的包与其他的发行版的包有许多的依赖关系。虽然打包系统对于各自的开发人员社区非常有用,但是他们也面临着与它们的规模、复杂性和进化速度等的挑战。典型的问题是向后不兼容的包的更新,以及(暂时性地)依赖已过时或者不活动的包的风险。这份手稿使用了图书文献。Io数据集进行定量实证分析的异同的包依赖网络的进化,七种包装的大小不同的生态系统以及年龄:Cargo for Rust, CPAN for Perl, CRAN for R, npm for JavaScript, NuGet for the .NET platform, Packagist for PHP, andRubyGems for Ruby.我们提出了新的度量标准来捕捉这些依赖网络的增长、变化率、可重用性、脆弱性,并用这些指标去分析和比较他们的发展。我们观察到无论是包的大小还是包更新的数量上,网络依赖都会随着时间的推移而增长。而只有少数包负责大部分包的更新。大多数的包依赖于其他的包,只有少数的包构成大多数包的反向依赖。我们观察到,由于传递依赖关系的数量越来越多,“脆弱”包的比例很高。这些发现有助于评估包依赖关系网络的质量,并通过依赖关系管理工具和强加的策略来改进它。

关键字:软件资源产业、软件系统、包管理器、网络依赖、软件发展。

1.介绍

传统上,软件工程研究的重点是理解和改善单个软件系统的开发和进化。围绕分布式版本控制工具(如Git和GitHub)的在线协作开发解决方案的广泛使用,导致了所谓的软件生态系统的日益流行。开源软件生态系统的典型例子是针对Linux操作系统的发行版和针对特定编程语言的打包生态系统。

软件系统往往非常大,包含数万甚至数十万个包,它们之间的依赖性甚至要高于一个数量级。复杂并且不断变化的对的依赖关系对于开发人员来说是一个“负担”,其经常被称为“依赖地狱”(Artho et al. 2012; Bogart et al.2016)。如果没有适当的维护,这些依赖关系的存在可能会对系统的质量造成损害。事实上,开发人员不愿意升级它们的依赖关系(Bavota et al. 2015),而过时的依赖关系会更容易受到安全问题的影响(Cox et al. 2015)。因此,研究人员一直在更加积极地研究打包依赖关系的包装动力学的发展,以支持其宏观层面出现的诸多问题(Decan et al. 2016; Gonzacute;alez-Barahona et al. 2009)。这类问题的一个著名的例子是npm包管理器的leftpad事件。尽管体积很小(只有几行代码),leftpad包的突然和意外删除造成了数千个直接或间接项目的中断,包括非常流行的项目:Atom和Babel (Schlueter 2016;Haney2016)。

对不同系统的包依赖网络的对比研究是非常迫切的,以为了去了解它们的相似性和差异性还有它们是怎样随着时间演变的。通过考虑特定的系统,从而更好地管理和控制不断发展的软件生态系统的内在脆弱性和复杂性,这些研究可能有利于提高软件分析工具。

本论文是在我们以前的工作的基础之上发展起来的。Decan等人(2016)对三种流行的打包生态系统的包依赖网络进行了实证比较:CRAN代表R,PyPI代表Python,npm代表JavaScript。

这些分析集中在网络依赖的结构复杂性上。我们发现了之前所考虑过系统的差异,这些可以通过生态系统的底层编程语言的标准库提供的功能以及其他生态系统特性来解释。这表示一个生态系统的发现并不一定能推广到另一个生态系统上。因此我们建议通过考虑更多的生态系统以及考虑网络依赖的演变来扩大分析。在Decan et al.(2017),我们开始对CRAN、npm和rubygems的包依赖网络演化进行历史分析。我们研究了大多数的包往往依赖于其他的包,以及在多大程度上包更新在存在(传递性)包依赖关系时存在问题。我们注意到,由于存在许多的传递依赖,一个包的失败可能会潜在地影响到许多其他的包。虽然每个生态系统提供了独特的、不同的方法去减少有问题的包更新的影响,但是没有一个解决的方法是完美的,并且包维护人员偶尔也会遇到包更新问题。

本文对Decan等人(2017)的研究结果进行了扩展,考虑了针对多种编程语言的七种不同打包生态系统:Cargo for Rust、CPAN for Perl、CRAN for R、npm for JavaScript、NuGet for .net开发平台、Packagist for PHP和rubygems for Ruby。据我们所知,这是第一次比较这么多不同的生态系统,以及利用了最新的图书、io数据集。另一个新奇之处是我们介绍了三种指标去促进生态系统的比较,尽管考虑到生态系统的多样性在于它们的年龄和大小;易变性指数捕获了生态系统随着时间的变化而变化,可重用性指数捕获了生态系统的重用幅度和程度;P-Impact指数评估生态系统的脆弱性。

本文其余部分的结构如下。第二部分讲述了相关工作。第三部分介绍了相关的术语,激发了所选择的包的生态系统和解释了数据提取的过程。第四至第七部分分别针对一个特定的研究问题。

第四部分研究了我们第一个研究的问题:“包依赖网络是怎样随着时间的增长而增长的?”我们观察到包的数量和它们之间依赖关系的持续增长。鉴于我们在Decan et al.(2017)中观察到包依赖关系在包更新时可能存在问题,第5节研究了第二个研究问题:“包更新的频率有多高?”由于包的依赖问题导致了生态系统的脆弱性的增加,第六部分研究了第三个研究问题:“包在多大程度上依赖于其他的包?”第七部分研究了第四个研究问题:“传递性依赖有多普遍?”的确,由于包依赖网络中传递依赖的普遍存在,包失败可能会通过网络传播,并可能影响到生态系统的大部分。

第八部分通过讨论生态系统的政策是如何影响已观察到的结果,现有技术在处理包依赖和包更新上有什么样的限制,以及我们的结果如何构成生态系统级健康分析工具的基础,从而使我们的研究结果具有前瞻性。第九部分提出了对我们研究有效性的威胁。第十部分描述了我们未来的工作,通过提供软件生态系统演化规律的初步证据,并建议从复杂网络或社会技术网络的角度来探索软件生态系统演化。最后,第十一部分结束。

2.相关工作

在那里,软件生态系统的搜索领域是巨大的。我们建议读者参考最近的一些关键参考文献,以便进一步阅读(Manikas and Hansen 2013;Jansen et al.2013;Serebrenik and Mens 2015)。鉴于本文特别关注打包生态系统,尤其是包依赖网络中的技术依赖,本节主要报告这些领域中的相关工作。虽然社交依赖网络本身非常有趣,但它超出了当前工作的范围,因此这里不讨论与此类网络相关的工作。

许多研究人员在单个软件项目中包含的组件级别上研究(并比较)技术依赖网络(例如,研究Java项目中类之间依赖网络的模块化)(Dietrich et al. 2008;萨内蒂和施维泽2012))。对这些工作的详细描述超出了本文的范围,因为我们的重点是在生态系统级别,即,我们考虑不同项目之间的依赖关系(相对于单个项目内的依赖关系)。

许多研究人员研究了各种编程语言打包生态系统中的包依赖问题。然而大多数的研究限制在单一的生态系统中,Wittern等(2016)研究了npm中JavaScript包子集的演化,分析了其依赖关系、更新频率、流行程度、版本编号等特征。Abdalkareem等人(2017)也对npm进行了实证案例研究,重点研究了他们所说的“琐碎”包,以及依赖这些包的风险。结果是不确定的,从某种意义上说,依赖于简单的包是有用的,并且没有风险的,前提是它们得到了良好的实现和测试。CRAN包装生态系统之前已经被研究过(Hornik 2012;《细菌学》等2013;和依赖关系已被证明是CRAN和GitHub上R包错误的一个重要原因(Decan et al. 2016)。Blincoe等人(2015)将Ruby视为GitHub对软件生态系统出现的更大研究的一部分,并观察到大多数生态系统都以一个项目为中心,并且与其他生态系统相互关联。Bavota et al.(2015)研究了Apache生态系统中依赖关系的演化,并强调依赖关系呈指数级增长,必须由开发人员来处理。考虑到包的更改可能会破坏其依赖的包,Bavota等人发现开发人员不愿意升级他们所依赖的包。Robbes等(2012)研究了Smalltalk生态系统中API方法废弃的涟漪效应,发现API的变化会对系统产生较大的影响,并且在初始变化后很长一段时间内都不会被检测到。

Santana和Werner(2013)专注于研究软件生态系统分析的可视化方面,提出了社区贡献者之间交互的社会可视化,以及生态系统项目依赖关系的技术可视化。然而,他们并没有关注如何计算或可视化关于生态系统的指标。

工业软件项目中已经研究了对带有安全漏洞的包的依赖性(Cadariu et al. 2015)。Cox等人发现,使用过时依赖项的系统出现安全问题的可能性是使用最新依赖项的系统的四倍(Cox等人,2015)。

很少有研究结果能够比较不同包生态系统之间的依赖性和可维护性问题。Bogart等人为了理解社区价值、工具和政策对打破变化的影响,比较了三种不同的生态系统。他们通过对研究生态系统的开发人员的采访进行了定性分析。特别是包依赖关系,他们确定了包开发人员采用的两种主要缓解策略:限制依赖关系的数量;并且只选择它们信任的包的依赖项。Bogart的工作是对现有论文的补充,该论文基于包装生态系统依赖网络的定量实证比较。

Kikas et al. (Kikas et al. 2017)受我们之前工作(Decan et al. 2016, 2017)的启发,对三个生态系统(npm、RubyGems和Rust)的依赖网络进行了实证比较,证实了我们自己关于生态系统脆弱性和易受过渡依赖影响的研究结果。

3.方法

3.1预赛

本文中提出的所有实证分析都得到了一个复制包的支持(Decan和Mens 2017)。表1非正式地定义了本文中使用的所有术语。如果从上下文中清楚地表示术语的各部分,则将隐式地假定在表第一列的括号中表示的各部分。

表1.本文所用术语的非正式定义

术语

非正式定义

包装的生态系统

围绕特定包管理器的所有工具、软件构件和社区成员的集合和历史。

包管理器

一组连贯的软件工具,以一致的方式自动地安装、配置、升级或删除计算机操作系统上的软件包。

提供特定功能的计算机程序。包通常存在于许多版本中,这些版本称为发行版。由于滥用语言,t时刻的包表示它在t时刻的最新可用版本。

(包)发布

可以通过包管理器访问和安装的包的特定版本。它通常会在形式的存档文件包含所需要构建、配置和部署包版本,并包括一个清单包含重要的元数据,如它的主人,名称、描述、时间戳和其他包的直接依赖关系列表所需的正常运转。

(包)更新

由包管理器提供的成功的包的新版本(即,对应较高的版本号或时间戳)相同包的以前版本。

(包)依赖网络(t时刻)

图结构,其中节点表示包管理器在t时提供的所有包,有向边表示在t时最新可用版本之间的直接依赖关系。

依赖

对另一个包的显式文档化引用(在版本清单中),这是该包正常运行所必需的。依赖项可以指定约束来限制目标包的受支持版本。在发布清单中明确记录的依赖项(即,依赖关系网络中的边)称为直接依赖关系。那些属于依赖网络传递闭包的部分称为传递依赖。非直接的传递依赖称为间接依赖。

反向依赖

反向依赖是通过沿着依赖网络相反方向的边缘来获得的。至于正常的依赖关系,它们可以是直接的、传递的或

剩余内容已隐藏,支付完成后下载完整资料


英语原文共 36 页,剩余内容已隐藏,支付完成后下载完整资料


资料编号:[273082],资料为PDF文档或Word文档,PDF文档可免费转换为Word

您需要先支付 30元 才能查看全部内容!立即支付

课题毕业论文、文献综述、任务书、外文翻译、程序设计、图纸设计等资料可联系客服协助查找。