Macrolevel software evolution a case study of a large software compilation报告.docx
《Macrolevel software evolution a case study of a large software compilation报告.docx》由会员分享，可在线阅读，更多相关《Macrolevel software evolution a case study of a large software compilation报告.docx（10页珍藏版）》请在冰豆网上搜索。
Macrolevelsoftwareevolutionacasestudyofalargesoftwarecompilation报告
Macro-levelsoftwareevolution:
acasestudyofalargesoftwarecompilation
软件工程进展读书报告
14111111
XXX
14MSE-A
1.背景
软件的进化研究通常被认为是单一团队协同开发的产品，一个软件系统通常是由许多的应用程序和库组成的，其中的大多数来自毫不相关的团体，并且由不同目的的开发团队所开发，这种系统的演变所展现出来的某些方面和特点是值得研究的，然而找到所有的需要被研究的元素，特别是整个系统在某个特定时间点的源代码不是一项容易的工作。
这有可能是在软件进化的研究领域调查者们很少关注的原因。
幸运的是，这种研究变得能够实现因为真正的自由软件分布（libresoftwaredistribution）的出现，自由软件分布指的是软件包协同工作的集合，为用户提供了一个几百个应用集成的操作系统，每个包实际上有不同的团体所研发（被叫做“项目”），团体之间相对隔离。
创建和维护一个分布集的工作主要需要让各个包相互适应、产品安装、包管理和一些外观和用户体验等。
自由软件分布集的例子有Fedora（Red Hat） Linux,FreeBSD, Ubuntu,和DebianGNU/Linux。
虽然每个包看起来都是独立开发的，但是他们之间的联系和交互会在系统完成时显现。
结果是一个类似于经济学的发现：
小型软件（单个的应用程序）的演化和大型软件的演化相互制约竞争。
自由软件分布（libresoftwaredistribution），他们的开发不同于传统的软件开发，相比于传统软件开发的保密性和中央协调，这种自由软件系统通常是由小型的独立的志愿者团队分散开发，通常和一个或多个企业合作。
因此虽然项目相互之间有影响，特别是他们开发的软件存在相关性，但是通常是没有中央协调也没有共同目标和指导方针的。
因此构建和维护此类软件集通常需要提供连续的反馈，根据实际操作的协调性进行修改，也正因为如此，尽管他们不开发过多的代码本身，但是他们必须从细节方面去了解总体框架和原始团队的发展过程。
这种开源式的开发方式显然是适合我们去研究的。
软件演化的研究已经超过30年。
到目前为止的研究一直是关于单一的应用程序的研究，但是从2000年才开始了某些出名自由软件应用程序的研究，包括Apache和GCC，但是一直局限于子系统集中。
我们的方法就认为一个完整的软件编译成为一个系统，是伴随着许多应用程序和库服务于子系统的协同作用。
本文中我们从宏观角度去研究当前最流行的自由软件分布集合：
DebianGNU/Linux，研究人员跟踪研究了Debian稳定版本九年（从2.0版本到4.0版本），对于每个发布的版本下载了所有应用的源代码，分析了包的数量，包的大小，编程语言的使用和包中的依赖关系。
因为使用这种分析方式，我们发现开发人员必须足够掌握他们选择放入分布集中的每个包的兴趣点、可用性和成熟度，基于这种选择标准，大部分拥有所有成熟自由软件的系统会被选择。
因此我们选择了Debian这个具有代表性的拥有所有成熟自由软件的系统。
这项研究不仅仅能够让我们了解Debian软件的进化演变历程，更能够让我们了解一个成熟的自由软件系统的进化演变过程。
2实验内容
软件编译是由不同来源的异构软件组成，相较于一些大型团体设计研发的软件，有一些是由一些少数志愿者所设计研发的，他们提供了一个多样化和全面的自由软件，此外，自由软件分布还能够让我们了解不同的软件之间是如何相互关联的（主要指的是相互之间的依赖关系）。
本文主要全面分析了了Debian来让大家了解到整个自由软件分布系统的宏观格局，了解它是如何在大环境下工作的，对这一现象本身得出一些结论。
因为这样，实验同时也非常需要了解这其中主要参数的演变：
主要参数有：
总代码行数，包的数量。
这些特征的研究能够对软件的演化提供更多方面的了解。
同时，对于编程语言类型的使用状况也是一种需要研究的东西，需要研究其中的编程语言使用情况并讨论可能的原因和变化趋势。
另外每次应用软件的版本升级时，包的数量会提高，包与包之间的依赖关系也会增加，其中的维护工作也会增多，因此我们对软件包进行跟踪，主要跟踪的是包之间的依赖关系。
总而言之，主要需要研究以下几个方面的内容：
代码量，文件大小，包的数量，编程语言，依赖关系。
3实验规划
3.1实验说明
分布集被组织为一组包，每个包通常对应为应用程序或库，虽然他们也可以对应为其他产品例如文档，像大多数自由软件分布集一样，Debian定义了两种不同类型的包：
源包和二进制包。
源包包含了需要安装的二进制安装包的源代码，一旦建立，一个源包会导致一个活多个二进制包。
Debian为每个版本维护一个Sources文件（包含了源包的描述），每个包可以由一个人或一个团队所维护，包含了名字和版本、二进制文件列表、维护人员的姓名和邮箱地址和一些其他的与研究无关的信息。
例子：
下图为一个Debian2.2的Mozilla源包，对应版本M18-3，提供了四个二进制包，由FrankBelew维护。
对于每个Debian的版本，能够获取几个不同体系架构支持的二进制分布（二进制包集合）。
在对应的包文件中，每个二进制分布被定义为二进制包的描述列表，二进制包的描述类似于源包的描述，但是包含了一些有趣的其他领域的内容。
例子：
在Debian2.2中Mozilla的二进制包描述如下：
这个包中的Depend是表示其他二进制包需要它才能够成功运行，因此满足这些依赖关系的包需要提前或同时安装。
在上述条件下，每个在Depend中提到的包都需要在安装Mozilla之前或者同时安装，这种依赖关系要么是显式的（一个切仅有一个包），一对多（被|符号分隔的多个），要么是抽象的（有共同标示的一对多）。
Pre-depend是一个类似的字段，一定要提前安装相关的包。
Debian也有一些可选字段如Recommends和Suggests字段，在Recommends字段中有一些包具有强大但是不必须的依赖关系，只有在某些特殊情况下这种依赖关系才会呈现出来。
3.2实验方法
3.2.1代码统计
本项研究主要检索DebianGNU/Linux2.0~4.0之间的几个稳定版（2.0,2.1,2.2,3.0，3.1,4.0）之中的源文件和包，对应于i386二进制分布。
一旦检索到，对应的源文件就会被解析，接着其中每个包都会被解析，识别出使用的编程语言，并且计算出其中每个文件代码行数（SLOC）。
使用代码行统计工具（SLOCCount）进行统计,这个工具能够分析源代码目录，识别代码文件，分析每个代码文件的编程语言最后计算代码行。
对于物理的代码行数的定义如下：
一个物理的代码行会有一个换行符出现在结束行或文件尾标志，至少包含一个非空格或者非注释的字符。
SLOCCount还能够分析文件的MD5散列，用来启发式检测，避免计算自动生成的代码等，虽然在MD5检测文件时有一些缺陷但是依旧是一个比较有效的工具，，如今已经被用到了研究RedHat。
SLOCCount的分析结果之后会转化成其他的形式，包括SQL和XML的形式被用来分析和发布。
3.2.2依赖关系
准确确定软件分布（Sofwaredistribution）中的依赖关系，以有向图的形式展现，主要搜寻前文提到过的四个字段：
Depends, Pre-Depends, Suggests和 Recommends。
有向图的节点对应于二进制报或者抽象依赖，边对应他们的依赖关系。
当一个包安装完成之后即可满足箭头所指的下一个包的安装条件，我们把这个图叫做IDG图（Inter-Denpendency-Graph），下图为Debian2.0版本的PostgreSQL包的示例图：
如上图：
起始包为圆形，二进制包为矩形，抽象依赖为菱形，Debian系统中经常安装的包是橙色的。
假设分布的IDG图为G=（V,E），这里的V是一组节点，E指的一组边
1.P包中的直接依赖关系是V中的一组节点直接连接到P
2.P包中的直接从属关系对应于这些V中的节点，这些节点有一条边到P，这种P的直接从属关系都是将P作为它的直接依赖关系
Debian人气调查机构（DebianPopularityContest）跟踪调查过Debian中包的使用情况，我们在这里使用它们的数据去预测满足依赖关系最可能的方式，来计算受欢迎实例的IDG图，一般认为高人气的包指它能够满足多个依赖关系的包，因此我们这里去掉了可选字段的包。
我们在此定义连个组：
1.p包的所有依赖关系是一组在它的pIDG中的二进制包的集。
2.p包的所有潜在从属关系是在Debian分布集（包括在它的pIDG中的p）中的所有的二进制包。
举一个Debian2.0的例子说明：
mozilla表中xlib6g属于一个它的直接依赖关系，xlib6g中的xfree86common属于它的一个直接依赖关系，即Mozilla->xlib6g->xfree86common。
这里xlib6g和xfree86common都属于mozilla中的依赖关系，同时，mozilla和xlib6g都属于xfree86common的潜在从属关系。
4实验结果和观察
4.1总大小
如图所示：
图1可以大致看出，总代码的长度和包的数量在九年来增长了一个数量级，但是包的平均规模一直相对稳定。
图2可以看出包的数量和代码行数基本上每两年翻一倍。
4.2包的大小
根据图上的统计数据我们可以了解到，那些最大的包正在变得越来越大，但是令人惊讶的是分布中出现了越来越多的小包。
但是根据上一节的统计数据我们知道包的平均大小是基本稳定的，2.0版本到4.0版本9年之间仅仅增加了3KSLOC，为此我们虽然没有权威的解释，但是能够根据这一节的数据做出一个合理的猜想，其中之一就是：
自由软件生产往往需要创造新的、更加专业的小包（可能有少数人开发），而不是发展那些大型的、复杂的包（大型团体开发的）。
因此随着时间的推移，虽然原有的包越来越大，但是更多的小包的涌入导致了平均大小趋于稳定。
4.3包的维护
在Debian系统中随着版本的提高，基本上只有包的版本号会改变，除了动态库，软件包的名字很少改变，因此我们能够统计新包的产生和旧包的出现，以及一些常用的包和不变的包。
对于给定的Debian系统版本的包可以分为三组：
常用包（出现在这两个版本中），删除的包（老版本有新版本没有），新包（新版本有老版本没有）。
常用包包括了不变的包（出现在这两个版本中，版本号未变）。
接下来的两个表分别为以版本2.0为例和以4.0为例的包变化统计图：
从表中我们可以看出，2.0版本中不少于15%的源码包，在9年后的4.0版本依然被使用，虽然如此，依旧使用的包相对于如今的版本已经是很小的一部分了。
4.4编程语言统计
为了显示软件的进化演变，我们选取了那些至少占了1%的编程语言，汇编大代码在Debian4.0中有八种，但是表中忽略了。
所有版本中最常用的的c语言，随着版本的提高，其他的语言所占的比例越来越高，虽然C语言的使用率从76.7%跌到了51.3%，但是其规模却是一直在提高的，超过了其他的所有语言。
其余增长较快的有C++,Shell和JAVA，但是值得一提的是由于授权问题，研究统计不包括JRE和JDK，这样可能会令JAVA的数据不够准确，因此我们暂且不对其进行分析。
上图也许能够让大家对其应用规模和比例有更好的理解。
下图展示了一个相对的编程语言的演化局势，相对的SLOC（垂直轴）代表了给定版本的SLOC除以Debian2.0中的SLOC。
观察后我们发现Python在9年来代码行数是2.0版本的60倍，C语言仅仅有7倍，结合table4我们可以了解到这些语言的发展是牺牲了C语言和Perl的。
4.5文件大小
由表中数据可以看出，除了SHELL文件外，其余编程语言的文件大小变化都不大，可能由于SHELL文件的独特性，它包含了关于安装配置等工作的所有包，功能的增加可能很少分成好几个文件，通常只是增加单一文件的代码量，很有可能发生的事情就是脚本会随着时间越来越复杂。
通常面向对象语言的文件更小。
4.6依赖关系
在自由软件中，由于小成本的原因，软件的复用是经常出现的，因此，依赖关系也非常的普遍，表6能够表现出一个依赖关系的演化情况，随着二进制包的数量的增加，依赖关系也有着同样的趋势，包之间的依赖关系也越来越多。
随着依赖的发展，依赖图也会发生类似的变化，以下分别是2.2版本和4.0版本的依赖关系图：
5实验结果与分析评价
文章跟踪Debian系统9年内6个版本的相关信息，从文件大小和数量、代码量、编程语言、依赖关系几个方面，搜集统计并分析了大量的数据，以Debian系统为代表，用切实的数据给我们宏观地讲述了整个libresoftwareditribution的发展过程。
本文所做的实证研究非常规范和细致，从文中能够看出作者的用词很严谨，对于libresoftwareditributionde的数据统计，考虑到了各个方面的数据和可能产生的误差，对于那些不能够确定的数据作者做了筛选。
作者的目的在于了解整个软件演化的历程，从一个开源的libresoftwareditribution来进行全面的统计与分析，使用SLOCCount来对6个版本的Debian进行统计。
实验的结果能够清晰展现自由软件发展的趋势，随着时间的推移，两年内软件的规模就会翻一番，并且随着规模的增大，依赖关系会增多。
另外实验让我们能够了解到目前的编程语言的使用趋势，C语言的使用比率逐渐下降，但是规模依旧在增大，其他面向对象语言的发展越来越快。
对Debian的版本研究也能够对整个软件行业的情况有一个参考，结尾处作者也对其工作做了高度的总结和概括，以及一些可以继续延展的实证研究。
升级会员 