首页 | 本学科首页   官方微博 | 高级检索  
相似文献
 共查询到20条相似文献,搜索用时 749 毫秒
1.
类间结构型代码味道自动检测的研究   总被引:1,自引:0,他引:1  
软件重构是改造软件遗留系统、软件重用的重要手段。代码味道用于描述软件设计缺陷,检测代码味道是软件重构的重要步骤。按照代码味道的特征给代码味道分类,对引发重构的主要缺陷――类之间结构型代码味道,给出了自动化检测的原理,设计和实现了一个检测工具。  相似文献   

2.
陈秋远  李善平  鄢萌  夏鑫 《软件学报》2019,30(4):962-980
代码克隆(code clone),是指存在于代码库中两个及以上相同或者相似的源代码片段.代码克隆相关问题是软件工程领域研究的重要课题.代码克隆是软件开发中的常见现象,它能够提高效率,产生一定的正面效益.但是研究表明,代码克隆也会对软件系统的开发、维护产生负面的影响,包括降低软件稳定性,造成代码库冗余和软件缺陷传播等.代码克隆检测技术旨在寻找检测代码克隆的自动化方法,从而用较低成本减少代码克隆的负面效应.研究者们在代码克隆检测方面获得了一系列的检测技术成果,根据这些技术利用源代码信息的程度不同,可以将它们分为基于文本、词汇、语法、语义4个层次.现有的检测技术针对文本相似的克隆取得了有效的检测结果,但同时也面临着更高抽象层次克隆的挑战,亟待更先进的理论、技术来解决.着重从源代码表征方式角度入手,对近年来代码克隆检测研究进展进行了梳理和总结.主要内容包括:(1)根据源代码表征方式阐述并归类了现有的克隆检测方法;(2)总结了模型评估中使用的实验验证方法与性能评估指标;(3)从科学性、实用性和技术难点这3个方面归纳总结了代码克隆研究的关键问题,围绕数据标注、表征方法、模型构建和工程实践4个方面,阐述了问题的可能解决思路和研究的未来发展趋势.  相似文献   

3.
采用代码生成技术能大幅度提高软件开发的质量和生产率,降低软件开发的风险.文中讲解了基于C#的NHibernate代码生成器的设计与实现过程.并分析了常见的代码生成.技术;同时结合实例说明核心源代码.  相似文献   

4.
现有代码安全审计主要是关注语言自身的缺陷,即语言所包含的API函数的风险,无法理解软件源代码中逻辑和核心资产与外界的关系,更无法判断源代码中所存在的恶意后门代码,因此,外包开发团队或者恶意开发人员设置的后门代码将无法查找和定位。为了解决上述现有方案的缺点和盲点,在现有的代码安全审计的基础之上,结合最小攻击面和保护资产列表,分析所有受保护的信息资产与攻击面的关系,查找保护资产在系统内对所有代码元素的影响,并审查其相关路径,找出不期望的代码执行路径,从而达到定位恶意代码功能。识别恶意程序,降低源代码安全风险。  相似文献   

5.
刘石  李合  王啸吟  张路  谢冰 《计算机科学》2009,36(8):165-168
通过示例代码学习简单算法的实现和具体API的使用方式是程序开发人员在软件开发中进行软件复用的高效手段,也是使用代码搜索引擎的主要目的.代码搜索引擎从网页搜索技术发展而来,提供对网络上源代码资源的检索功能,能够有效定位与搜索内容相关的代码,为程序开发人员提供帮助.但现有的代码搜索引擎没有在搜索结果中区别API的实现代码与使用代码,搜索结果存在冗余,导致用户无法快速有效地找到提供有用信息的代码片段.为了使用户更好更快地找到代码搜索目标,阐述了应用语法与语义分析技术从区分API实现代码和使用代码、相似代码聚类、搜索结果摘要3个方面对代码搜索结果进行优化的方法,给出了一个代码搜索引擎的实现,并在实例研究中展示了该方法的有效性.  相似文献   

6.
目前在软件代码缺陷审查以及缺陷预测中,研究人员对源代码进行分析研究却忽略了代码的缺陷信息.本文通过对缺陷信息进行分析,发现缺陷信息对于相似缺陷的检测有着重要的参考价值.基于这一思想,本文分析软件缺陷社区Stack Overflow中关于缺陷代码的信息,提出一种基于缺陷代码特征分析的相似缺陷检测方法.该方法首先对缺陷报告进行LDA主题分析并将缺陷报告分类到不同的主题(类别)中,统计得到高频缺陷类别;其次对于高频缺陷类别的缺陷代码提取特征;最后根据缺陷代码特征构建相似缺陷检测模型.为了验证相似缺陷检测模型的有效性,针对数据操作缺陷数据构建诊断模型并对该模型进行实证,实验结果表明该方法对检测其他代码中相似缺陷有较好的效果.  相似文献   

7.
郑建华  朱蓉 《福建电脑》2011,27(12):8-9
代码自动生成技术是提高软件开发效率的有效方式,本文提出一种实现SSH(Struts-Spring-Hibernate)框架集成源代码的自动生成的技术方案。该方案通过构建图形化的E-R(Entity-Rela-tion)图编辑器,实现E-R图绘制;然后基于该E-R图实现不同类型数据库源文件、以及SSH框架集成源代码、持久层代码自动生成,最终形成一个完整的J2EE项目开发环境。  相似文献   

8.
采用代码生成技术能大幅度提高软件开发的质量和生产率,降低软件开发的风险。文中讲解了基于C#的NHibemate代码生成器的设计与实现过程,并分析了常见的代码生成技术,同时结合实例说明核心源代码。  相似文献   

9.
采用代码生成技术能大幅提高软件开发的质量和生产率,降低软件开发的风险。本文将介绍了基于C#的NHibernate代码生成器的设计与实现过程,并分析了常见的代码生成技术,同时结合实例说明核心源代码。  相似文献   

10.
重构是当下软件工程领域研究的一个重要研究课题,在软件开发和软件维护的过程中,程序员逐渐认识到其重要性。本文先从重构的定义,重构的意义和重构的时机等几个方面系统地介代码件重构的相关内容,然后列举了重构所要解决的几种常见的代码坏味。最后后结合一个具体实例展示了重复代码这一常见坏味产生的原因以及重构过程。  相似文献   

11.
章晓芳  朱灿 《软件学报》2019,30(5):1422-1437
代码坏味是指程序设计中存在的不良设计模式或设计缺陷.坏味的存在,被认为会阻碍软件的演化与维护.近年来,研究人员致力于探究坏味产生的影响以及坏味与软件演化之间的关系.已有研究表明,代码坏味会随着软件的演化而不断发生变化.通常,软件的演化将涉及源文件的增加、修改与删除这3类具体操作,了解代码坏味与软件演化中源文件操作的关系,将有助于开发者更好地计划软件开发过程和重构软件代码.因此,针对13种常见的坏味,在8个Java项目共计104个版本中进行了系统的实证研究.研究发现,随着软件版本的演化,含代码坏味的文件在整个项目中的占比在不同的项目中呈现出不同的特征.另外,包含代码坏味的文件更倾向于被修改,而坏味本身与文件的添加或者删除并没有太大的关联.更进一步地,在探究的所有坏味中,有几种特定的坏味对文件的修改产生了显著的影响,且这些坏味文件间存在着明显的重叠.这些发现有助于开发人员更好地了解代码坏味,以便于更好地对软件进行维护.  相似文献   

12.
苏珊  张杨  张冬雯 《计算机应用》2022,42(6):1702-1707
基于启发式和机器学习的代码坏味检测方法已被证明具有一定的局限性,且现有的检测方法大多集中在较为常见的代码坏味上。针对这些问题,提出了一种深度学习方法来检测过紧的耦合、分散的耦合和散弹式修改这三种与耦合度相关检测较为少见的代码坏味。首先,提取三种代码坏味需要的度量并对得到的数据进行处理;之后,构建卷积神经网络(CNN)与注意力(Attention)机制相结合的深度学习模型,引入的注意力机制可以对输入的度量特征进行权重的分配。从21个开源项目中提取数据集,在10个开源项目中对检测方法进行了验证,并与CNN模型进行对比。实验结果表明:过紧的耦合和分散的耦合在所提模型中取得了更好的结果,相应代码坏味的查准率分别达到了93.61%和99.76%;而散弹式修改在CNN模型中有更好的结果,相应代码坏味查准率达到了98.59%。  相似文献   

13.
软件系统中的相似代码给软件维护带来很大困难,也是最易见的重构对象。如何有效地检测相似代码是软件工程领域的一个重要研究课题。本文介绍了常见的基于文本匹配的相似代码检测算法,尤其是检测源文件之间相似代码的动态文本匹配算法和源文件内部相似代码的后缀树算法,并将这两种算法结合起来,实现一个相似代码检测工具。该工具提供了时空代价平衡的相似代码检测能力,提供了精确有效的相似代码检测手段,帮助开发人员锁定相似代码,提高了重构活动的效率。本文介绍了该工具的架构和内部处理流程,并应用该工具搜索了若干实际应用系统的重复代码,检验了工具的可用性。还简单讨论了该工具和其他一些相似代码检测工具的优劣。  相似文献   

14.
在软件开发的过程中,开发人员通过复制粘贴式的开发方式或者模块化的开发方式来完成需求是十分常见的,这两种开发方式可以提高开发效率,但同时会导致软件系统中出现大量的相同代码或者相似代码,大量的相似代码会给软件维护等方面带来很大的困难,这也是最常见的重构对象。源代码相似性度量是指利用一定的检测方法分析程序源代码间的相似程度。该技术被应用于代码抄袭检测、代码克隆检测、软件知识产权保护、代码复用等多个领域。为了提高代码相似性度量的准确性,提出了一种基于多特征值的源代码相似性检测技术。构建了源代码注释、型构、代码文本语句与结构中特征提取的方法,并给出了源代码相似度检测的度量模型。通过与权威的代码相似检测系统Moss进行对比实验,结果表明该方法可以更准确地检测出相似代码。  相似文献   

15.
相对于单一类型的代码异味,代码异味共存现象更具危害性。已有实证研究大多聚焦于分析桌面应用程序中代码异味的共存现象,缺少对Android应用程序中代码异味共存现象的研究。为了研究Android应用程序中代码异味的共存现象,并与桌面应用程序中代码异味共存现象进行比较,分别对285个Android应用程序和30个桌面应用程序进行检测,对检测出来的10种异味进行分析。首先,根据检测结果计算受到多种异味影响的类的百分比。然后,使用公式计算代码异味共存的频率,最后,使用Spearman相关系数分析代码异味共存与应用程序规模的关系。结论如下:a)在Android应用程序中受到一种以上代码异味共同干扰的类占有异味的类的总数的31.04%;b)在两个平台的应用程序中,两对代码异味brain class—brain method和god class—brain method共存的频率较高;c)一种异味、两种异味共存、三种异味共存与Android应用程序的规模具有较强的相关性。  相似文献   

16.
ContextThe automated identification of code fragments characterized by common design flaws (or “code smells”) that can be handled through refactoring, fosters refactoring activities, especially in large code bases where multiple developers are engaged without a detailed view on the whole system. Automated refactoring to design patterns enables significant contributions to design quality even from developers with little experience on the use of the required patterns.ObjectiveThis work targets the automated identification of refactoring opportunities to the Strategy design pattern and the elimination through polymorphism of respective “code smells” that are related to extensive use of complex conditional statements.MethodAn algorithm is introduced for the automated identification of refactoring opportunities to the Strategy design pattern. Suggested refactorings comprise conditional statements that are characterized by analogies to the Strategy design pattern, in terms of the purpose and selection mode of strategies. Moreover, this work specifies the procedure for refactoring to Strategy the identified conditional statements. For special cases of these statements, a technique is proposed for total replacement of conditional logic with method calls of appropriate concrete Strategy instances. The identification algorithm and the refactoring procedure are implemented and integrated in the JDeodorant Eclipse plug-in. The method is evaluated on a set of Java projects, in terms of quality of the suggested refactorings and run-time efficiency. The relevance of the identified refactoring opportunities is verified by expert software engineers.ResultsThe identification algorithm recalled, from the projects used during evaluation, many of the refactoring candidates that were identified by the expert software engineers. Its execution time on projects of varying size confirmed the run-time efficiency of this method.ConclusionThe proposed method for automated refactoring to Strategy contributes to simplification of conditional statements. Moreover, it enhances system extensibility through the Strategy design pattern.  相似文献   

17.
Refactoring large systems involves several sources of uncertainty related to the severity levels of code smells to be corrected and the importance of the classes in which the smells are located. Both severity and importance of identified refactoring opportunities (e.g. code smells) are difficult to estimate. In fact, due to the dynamic nature of software development, these values cannot be accurately determined in practice, leading to refactoring sequences that lack robustness. In addition, some code fragments can contain severe quality issues but they are not playing an important role in the system. To address this problem, we introduced a multi-objective robust model, based on NSGA-II, for the software refactoring problem that tries to find the best trade-off between three objectives to maximize: quality improvements, severity and importance of refactoring opportunities to be fixed. We evaluated our approach using 8 open source systems and one industrial project, and demonstrated that it is significantly better than state-of-the-art refactoring approaches in terms of robustness in all the experiments based on a variety of real-world scenarios. Our suggested refactoring solutions were found to be comparable in terms of quality to those suggested by existing approaches, better prioritization of refactoring opportunities and to carry an acceptable robustness price.  相似文献   

18.
AADL构件到RTLinux平台C代码的转换方法研究*   总被引:1,自引:1,他引:0  
朱江  张茂林 《计算机应用研究》2011,28(12):4613-4615
为了提高嵌入式软件开发的自动化程度,代码自动生成是一种值得采用的有效方法.在研究体系结构分析与设计语言(AADL)和RTLinux(real-time Linux)平台C代码的特性的基础上,提出了AADL构件到RTLinux平台C代码的转换规则;然后用一个实例实现了代码自动生成,从而验证了转换规则的有效性.  相似文献   

19.
ContextClone detection tools provide an automated mechanism to discover clones in source code. On the other side, refactoring capabilities within integrated development environments provide the necessary functionality to assist programmers in refactoring. However, we have observed a gap between the processes of clone detection and refactoring.ObjectiveIn this paper, we describe our work on unifying the code clone maintenance process by bridging the gap between clone detection and refactoring.MethodThrough an Eclipse plug-in called CeDAR (Clone Detection, Analysis, and Refactoring), we forward clone detection results to the refactoring engine in Eclipse. In this case, the refactoring engine is supplied with information about the detected clones to which it can then determine those clones that can be refactored. We describe the extensions to Eclipse’s refactoring engine to allow clones with additional similarity properties to be refactored.ResultsOur evaluation of open source artifacts shows that this process yields considerable increases in the instances of clone groups that may be suggested to the programmer for refactoring within Eclipse.ConclusionBy unifying the processes of clone detection and refactoring, in addition to providing extensions to the refactoring engine of an IDE, the strengths of both processes (i.e., more significant detection capabilities and an established framework for refactoring) can be garnered.  相似文献   

20.
Software design problems are known and perceived under many different terms, such as code smells, flaws, non-compliance to design principles, violation of heuristics, excessive metric values and anti-patterns, signifying the importance of handling them in the construction and maintenance of software. Once a design problem is identified, it can be removed by applying an appropriate refactoring, improving in most cases several aspects of quality such as maintainability, comprehensibility and reusability. This paper, taking advantage of recent advances and tools in the identification of non-trivial code smells, explores the presence and evolution of such problems by analyzing past versions of code. Several interesting questions can be investigated such as whether the number of problems increases with the passage of software generations, whether problems vanish by time or only by targeted human intervention, whether code smells occur in the course of evolution of a module or exist right from the beginning and whether refactorings targeting at smell removal are frequent. In contrast to previous studies that investigate the application of refactorings in the history of a software project, we attempt to analyze the evolution from the point of view of the problems themselves. To this end, we classify smell evolution patterns distinguishing deliberate maintenance activities from the removal of design problems as a side effect of software evolution. Results are discussed for two open-source systems and four code smells.  相似文献   

设为首页 | 免责声明 | 关于勤云 | 加入收藏

Copyright©北京勤云科技发展有限公司  京ICP备09084417号