Posts Tagged ‘学术’

读论文 宏观层面的软件演化

软件工程进展读论文报告

论文:Macro-level software evolution: a case study of a large software compilation (宏观层面的软件演化:举例研究一个大型软件的编译)于2008年11月29号发表于实证软件工程。

论文的背景和动机:

软件演化(Software Evolution)一般研究的是由相互合作的团队开发的单个的软件产品。但是越来越多的软件系统包含了大量了不同的应用和运行库。很多这些应用和运行库是由不同的团队面向不同的目的开发的。这种大型软件系统是如何演化的呢?他们有些什么特性特点呢。但要研究这样的大型软件系统需要有这个系统所涉及的所有应用和库在各个时间点的源代码。这并非一件易事。因此才鲜有研究文献涉及该类型的系统。

这些年,很多大型自由软件系统取得了巨大成功,例如Fedora Linux, Debian GNU/Linux, FreeBSD, OpenBSD。这些大型自由软件集成成百上千独立应用和库,并且几乎所有自由件的授权都充许自由得到相应的源代码。这为我们研究大型软件系统的演化提供了必要条件。

构成大型软件系统的各个工程是独立开发的(某些软件系统把这些独立开发的工程称之为包),但从整个软件系统的视角来看,它们之间却存在复杂的依存关系,甚至在某些情况下会是冲突关系。因此,单个的研究某特定工程的演化与在整个软件系统中研究软件的演化是不同的。

论文旨在通过分析一个大型自由软件系统的演化来揭示大型自由软件系统的一般规律以至私有大型软件的某些规律和特点。

论文中实证研究的定义、规划、执行与分析:

Debian GNU/Linux是一个非常流行的大型软件系统。它包括了各种大大小小的应用和库,其中一些演化的非常迅速,其中一些又长期没有变化,不断有新的包加入该系统又不断有过时的包被抛弃。仅管这些包是相互独立开发并自我演化,但在Debian系统中,它们之前有着非常复杂的关系。这个复杂关系随着Debian系统的演化而变得更加复杂,使之越来越难以维护。

 

[定义]

这篇论文,即以Debian软件系统为例,主要考察了九年以来Deiban系统中包的总数,包的大小,开发语言,包之间的相互依赖性等多个指标,在宏观上研究整个Debian软件系统的演化。最终得出一些大型自由软件的特点,分析这些特点能指导单独的软件研发使之能更好的集成进大型系统中。

 

[规划和执行]

Debian组织成一个个包(package),一般地讲每个包对应于一个应用或一个库,少数情况下对应于文档或其它。包分两种,一种是包含运行的二进制文件的包,另一个是源文件包。源代码包在构建以后通常生成一个或多个二进制包。Debian为每一个发行版本维护了一系列配置文件,这些配置文件设定了每个发行版所需要的运行环境,包含了哪些包。而每个包的配置文件也约定了它所依赖的其它包的关系。

这份报告研究了Debian从2.0到4.0的所有稳定发行版号,即2.0,2.1,2.2,3.0,3.1,4.0。对于每一个待考察的版本,配置文件被事先写好的脚本分析,把分析到的数据存入数据库中。然后,每一个源码包被自动获取,源代码行数被SLOC工具分析得出;源代码所使用的编程语言也用SLOC工具识别到。而包与包之间的依赖性亦可由Debian发行版的配置文件中记录的Depends,Pre-Depends,Suggests,Recommends字段得到。这些信息被分析出来以后,包与包之间的依赖关系由一个有向图描述出来。有向图中的结点表示一个包,连接结点的边表示包与包之间的依赖关系。每个待研究的Debian发行版都会生成一个这样的IDG(Inter-Dependency Graph),通过运用有向图的算法可以得到很多研究关心的数据,比如最流行的包(The most popular package)。

[分析]

1. 发行版总大小

结果显示每隔两年,发行版的大小(统计发行版的所有源代码行数)就会增加一倍。截止2007年的Debian 4.0,已经共有4亿行代码和1万个包。如此大的规模会为未来的继续发展带来不小的麻烦,在最新的发行版中已经可以看到超大规模的几数级增长已经给某些时间点带来了延迟。

2. 包的大小

而包的平均大小指标在九年内几乎维持不变。因为软件系统的总代码量迅速增长而平均包大小不变,这意味着越来越多的包被增加到系统中。Debian .4.0的包数目是Debian 2.0的包数目的10倍。为了应对包的不断增多,Debian系统需要迅速增加包维护者以及每个维护者需要应对的包数目。包数目的迅速增长也是一个非常棘手的问题,特别影响了包维护者的相互配合。

3. 包的维护

Debian维护者的任务之一就是跟踪新版本的软件包,给它们重新打包,更新相应的包描述。一但一个新版本的包发布了,包的名字就会相应变化。因此可以通过分析发行版的包的名称确定软件包有没有被维护过。

分析数据后显示Debian 2.0的1096个包里面有721个可以在4.0中找到。这意味着Debian2.0中只有30%的包在九年后的Debian 4.0中被移除。再之,Debian 3.1的10106个包中,而在4.0中仍然存在的有7300个,这个比例也大概是30%。

对于没有改变过的包。Debian 4.0中有132个包与Debian 2.0中毫无改变。换言之,Debian 2.0中不少于15%的包在九年后仍然没有任何改变在Debian 4.0中。

必须指出的是未改变的包所包含的文件数目并不能反应所有的未改变的文件数目。后者的数字应该高一些:有相当多的文件在Debian的各个发行版之间没有改变,即使它们所属的包的名字变化了。

4. 开发语言

统计数据显示Debian各个发行版中最多使用的开发语言仍然是C语言,并且较之于第二名优势明显。但对于C语言,在第Debian 2.0中,C占了77%的份额;到了Debian 4.0,C语言的份额下降到了51%。而对于C++,则是从2.0时占6%的市场份额上升到了4.0时的19%。总体上看,C语言的重要性一直在相对减弱,而C++和其它一些开发语言都保持了一定增长的趋势。必须说明的一点时,仅管C语言的份额在下降,但从C语言代码绝的绝对数量上看仍然在快速增加。

Shell语一直处在第三的位置,因为这种语言在几乎每个包中都有。从大量的小尺寸包到重量级的包,Shell无所不在。

另一个值得关注的必然是Java。在Debian 3.0时,Java编写的应用仅仅占到0.5%。到了Debian 3.1发布时,这个数字飞速上升到1.7%,到了Debian 4.0時,增加到了3.1%,稳定地占据了第四的位置。Java的快速增长得益于几个大型应用使用Java语言进行开发,比如:Eclipse和Azureus。实际上,Java还是被低估了。因为授权许可证的问题,包含大量Java代码的Sun JDK和Sun JRE没有统计在内,而其它语言则至少包含了一个常用的开发环境。

就代码量而言,一些比较生僻冷门的语言也占据了比较明显的份额。这是因为虽然这些生僻语言仅仅出现在少量包中,但这些开发包的尺寸却很大。比如,Ada语言在Debian 3.0中有57万行代码,其中的43万行都来自于Ada的编译器,开发库和开发工具。

通过观察开发语言的使用率趋势,可以估算出有多少开发者比较熟悉某种开发语言。同时,不同语言的不断演化也反映出自由软件在开发语言层面的变化。

5. 文件大小

大多数开发语言的源代码文件大小,一直没有太大的变化。C语言文件的平均大小保持在260行到295行之间,而C++的文件大小则是在140到196行之间。但有一个例外则是Shell语言的文件尺寸,这个尺寸从Debian 2.0到Debian 4.0翻了三倍。个中原由应该是几乎所有的包都有Shell代码来安装,配置或当作胶水语言使用。Shell代码很少被切成多个文件,如果要增加更多功能的时候,增加的代码则被添加到以前的文件里面。因此,Shell文件变得越来越大。

同时很明显地是,过程性语言通常比面向对象的开发语言的源文件要长。比如,C或YACC较之C++通常要大一些。这是因为类继承和其它一些面向对象语言的特性能够有效帮助减少代码量。

6. 依赖性

大型自由软件也是模块化设计。因为没有商用软件的诸多限制,软件复用在自由软件社区里是非常容易的。Debian的各个包之间通常有着非常复杂的依赖关系。

统计数据显示,在Debian 2.0时,有最多依赖项的是phython-gdk-imlib,共19个依赖项。到了Debian 4.0发布时,kde有多达561个依赖项,紧排其后的是gnome,共486个依赖项。

随着新的发行版的发布,包之间的关系变得愈来愈复杂。举例来讲,Mozilla包在Debian 2.1时只有7个依赖项,而到了4.0时则有72个依赖项。PostgreSql在2.0时仅有9个依赖项,到了4.0时则有42个依赖项。

从另一个角度看依赖性有项图。每一个结点表示一个包,有多少有向边指向该结点则表示这个包被多少其它的包依赖,我们把这些依赖它的包称为下属(Subordinate)。则一个包愈重要,则它的下属愈多。对于大多数包,它们的下属数目为零。而只有少数包拥有大量的下属。总体来看,包的平均下属数目随着整个软件系统包总数的增多而不断快速增多。比如,在Debian 2.0时,perl有118个下属,而到了Debian 4.0这个数量增长到11459。毫不奇怪,有最多下属的包是一些运行库,如libc,脚本语言解析器,如perl,传统Unix工具,如binutils和sed,awk。在某种程度上,一个包拥有越来多的下属数目则表示它的开发越成功。

对论文的个人评价和理解:

因为个人兴趣爱好,我对Unix/Linux相关的技术比较感兴趣,并有多年使用Debian OS的经验。因此我选择了这篇以Debian为研究对象的论文。全篇论文没有很难理解的地方,只是统计了Debian发展过程中的各种指标,把统计数据列出来再概括一个趋势。我想,这其间最困难的地方应该是编写分析Debian发行版配置文件的自动化程序。

另外我觉得这篇文章概括出来的一些大型软件系统的特点仅适用于自由软件。而商业软件在很多特性上很可能同自由软件相差甚远。比如,自由软件重代码轻文档,因些有这样的说法“代码即文档”。很多自由软件的项目代码编写优先入文档编写,文档通常相当程度落后于实际的开发进度。而商业大型软件则基本上是先确定文档再编写代码。开发方式的大相径庭使得该论文的结论不适用于大型商业软件。

另一个注意到的地方是关于流行开发语言的统计数据。虽然该篇论文发表于2008年,已是4年之前,Sun还没被Oracle收购,OpenJava还未加入Debian。但即便是4年之前,在整个软件开发工业里,Java已然是占有份额最多的开发语言,C语言紧随其后。该篇论文的数据则显示在Debian 4.0版本中,C语言占51%的份额,Java仅占3%的市场份额。虽然论文中有指出因为没有统计私有许可证的Sun SDK和Sun JRE的Java代码量。Java和C的占用率仍然是相差甚远,都不在一个数量级之上。我个人的理解主要有两点原因。其一,Debian搭建的是一个桌面生态环境,Java主要用到Web开发移动开发企业开发,开发桌面应用还是不多。其二,开源社区排斥由商业公司控制的开发语言,如果要开发效率,社区宁可选择选择自由许可证的Python。

从论文中提供的数据看来,Debian的规模是每两年增加一倍,如此迅速的演化速度,以前的组织方式必然需要提出创新和改变。我觉得论文不足的地方是对大型自由软件的未来发展趋势以及技术创新涉及甚少,没有一个前瞻性的预判。

copyright blog.ykyi.net

Be the first to comment - What do you think?  Posted by zausiu - February 22, 2012 at 13:30

Categories: Life and Others, Tech Articles   Tags:

业务连续性读书报告

第一部分  概述

什么是业务连续性

业务连续性就是为了应对系统宕机,无法接受的性能下降之类的问题。

为什么要有业务连续性

因为如果系统宕机会造成无法估计的巨大损失。怕你不信,PPT里画了张表,列举了几个行业宕机会造成的损失估计。最低的一般零售业每小时损失一百万美金;损失最大的是投资银行,每小时造成接近七百万美金的损失。

恢复时间 Recovery Time

Recovery Time includes1. Fault detection 2. Recovering data 3.Bringing apps back online。

灾难恢复和灾难重启的区别

灾难恢复是在人为干预下使用备份技术恢复数据把数据恢复到备份的某个完整点。而灾难重启则是重启镜像数据和应用程序。

5. 造成系统宕机的原因

有人为因素,系统本身的原因,支持系统的外围设备的故障(比如电网断电),另外还有自然灾难,战争什么的。苦逼的伊斯兰世界天天哭喊着要圣战啊。

6. 业务连续性和灾难恢复

业务连续性是一盘大棋,包括:计划,准备,从灾难中恢复。它侧重在预防。而灾难恢复计划(Disaster recovery planningabbreviated as BCP)应被看成业务连续性的一部分。灾难恢复侧重于事发后采取的措施和行动。

7. 业务连续计划(BCP)

界定关键业务功能;收集当前业务流程的数据;风险管理;制定应急预案(Contingency Plans)和灾难恢复计划(DR Plan);培训;测式;维护。

8. 业务连续性计划的生命周期

包括五个阶段。1. Implement, Maintain, and assess 2. Objectives 3. Analysis 4. Design & Develop 5. Train, Test & Document.

单点失效

这个概念N多学科里都有提到哇。顾名思义都知道单点失效是什么咯。解决的方法就是冗余!PPT里列举了HBA失效,交换机/阵列端口失效,磁盘失效,主机失效,站点/存储阵列失效。

10 业务连续性技术的解决方案

有三种。 A. 本地复制 B. 远端复制 C. 备份/恢复

11 EMC的相关产品

EMC在业务连续性方面的产品叫PowerPathPowerPath是个基于Server的软应用,它在HBA和存储子系统间提供了多通路。嗱,它提供冗余通路。好明显冗余是为了防止单点失效;还提供了负载平衡;应用层的透明性。这个东东增强了数据的有效性和可达性。

第二部分 解决方案

A) 备份和恢复

1. 备份是数据恢复和恢复的目的,可以使用的额外副本。主副本丢失或损坏时,使用备份副本。

2. 备份恢复的策略:复制数据,反射(或快照)后复制,远程备份等。

 

3. 备份计划的原因包括以下几个方面:硬件损伤、人为因素、应用程序崩溃、安全机制失败、自然灾难、定期的以及公司的需求。

4. 数据库备份方法:热备份,生产不中断;冷备份,生产中断。

5. 备份粒度和等级:全备份,累积备份,增加的备份

6. 备份架构拓扑,3种基本备份拓扑:基于直接附属设备的备份,基于局域网的备份,基于SAN的备份。

7. 备份媒介,磁带,磁盘。

8. 管理备份过程

备份应用程序接口一般包括两类,CLI和GUI。

备份报告:目的是要便于阅读和提供重要信息,如:备份的数据量;完成备份数;备份不完整的号码(失败);可能发生的错误类型。

备份日志的重要性:从日志中我们可以看到备份操作的强度和完整度等等,备份日志丢失,软件无法找到确定的备份文件来进行恢复。

B) 本地复制

1. 复制是产生拷贝数据的过程。

2. 备份关注两方面的,可恢复性,一致性。

3. 文件系统复制。

4. 数据库应用程序复制,包括数据和日志。

5. 本地复制技术,基于主机:基于存储阵列,分别举了几个例子。逻辑卷管理(LVM),基于镜像文件系统快照。

C) 远程复制

1. 学习目标:阐释远程复制的概念,能从各方面讨论基于主机和基于阵列的远程复制技术。

2.  同步复制:确保源和远程副本,在任何时候都相同的数据

3.  异步复制:数据缓冲,并且送到远程

4.  远程复制技术包括:基于主机的复制;基于阵列存储设备 zausiu's blog

/////////

介个是EMC存储课的作业.

 

Be the first to comment - What do you think?  Posted by zausiu - January 13, 2012 at 19:52

Categories: Life and Others   Tags:

Prof. Zixiang Xiong讲座 脏纸编码

作为主要兴趣在Linux方面的偏应用硕士,听了一个电信传输方面的学术讲座。所谓Dirty Paper Coding,我的理解是如果已知信道干扰,在发射机对发射信号预先减去该干扰,则发射信号经信道传输被接收机接收后,则信道干扰被自动抵消。很简单的Idea,但实际实施起来应该非常困难吧。Prof. Zixiang Xiong先介绍了他所工作的学校。呵。然后从Dirty-paper Coding的历史发展讲起。Instances of dirty paper coding include Costa precoding(1983) ,Tomlinson-Harashima precoding (1971) and the vector perturbation technique of Hochwald et al. (2005)。两位科学家GelfandPinsker开创了这个领域,到信息理论的实际设计准则如何应用到实践之中。Prof. Zixiang Xiong提出了两种有效的编码设计方法。理论回到实路,再介绍这两种编码设计方法在图形图象的数据隐藏,MIMO广播,抗噪预编码,无线网络传输协调方面的实际应用。Gaussian arbitrarily varying channel with a known interference signal at the encoder.

好复杂好深奥的数学变换。想起本科阶段的傅丽叶级数变换,卷积分就已经让我伤透脑筋。本次讲座的收获也就是让我一定程度上开拓了视野,接触到N多电信方面的术语。小波变换,脏纸编码,数字水印之类。术业有专功,我要专功我的Linux去嘞。。。

Be the first to comment - What do you think?  Posted by zausiu - December 26, 2011 at 19:11

Categories: Life and Others   Tags:

Next Page »