Test-Driven Development of Relational Databases

In test-first development, developers formulate and implement a detailed design iteratively, one test at a time. Test-driven development (also called test-driven design) combines TFD with refactoring, wherein developers make small changes (refactorings) to improve code design without changing the code's semantics. When developers decide to use TDD to implement a new feature, they must first ask whether the current design is the easiest possible design to enable the feature's addition. Implementing test-driven database design involves database refactoring, regression testing, and continuous integration. TDDD is an integrated part of the overall development process, not a standalone activity that data professionals perform in parallel with application TDD. Although from a technical view point, TDDD is relatively straightforward, we must overcome several challenges to its whole sale adoption throughout the IT community     

Automated refactoring to the Strategy design pattern

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.     

How changes affect software entropy: an empirical study

Context Software systems continuously change for various reasons, such as adding new features, fixing bugs, or refactoring. Changes may either increase the source code complexity and disorganization, or help to reducing it. Aim This paper empirically investigates the relationship of source code complexity and disorganization—measured using source code change entropy—with four factors, namely the presence of refactoring activities, the number of developers working on a source code file, the participation of classes in design patterns, and the different kinds of changes occurring on the system, classified in terms of their topics extracted from commit notes. Method We carried out an exploratory study on an interval of the life-time span of four open source systems, namely ArgoUML, Eclipse-JDT, Mozilla, and Samba, with the aim of analyzing the relationship between the source code change entropy and four factors: refactoring activities, number of contributors for a file, participation of classes in design patterns, and change topics. Results The study shows that (i) the change entropy decreases after refactoring, (ii) files changed by a higher number of developers tend to exhibit a higher change entropy than others, (iii) classes participating in certain design patterns exhibit a higher change entropy than others, and (iv) changes related to different topics exhibit different change entropy, for example bug fixings exhibit a limited change entropy while changes introducing new features exhibit a high change entropy. Conclusions Results provided in this paper indicate that the nature of changes (in particular changes related to refactorings), the software design, and the number of active developers are factors related to change entropy. Our findings contribute to understand the software aging phenomenon and are preliminary to identifying better ways to contrast it.     

质量驱动的用例模型重构

用例模型的质量对基于用例的软件开发至关重要。文章在分析用例模型的结构特点及质量需求的基础上,引入代码重构技术整理用例模型,构建了用例的换名、提炼和内联三类重构,在不改变参与者与系统间的交互信息之下,通过重新组织用例模型来提高用例模型的稳定性、简洁性及内聚性等语用质量。最后,给出了实现用例模型重构工具的设计方案。     

代码变更中抽取类重构模式的识别

在现代软件开发和维护中,重构是提高软件可维护性和软件质量的常用手段.而大量重构模式掺杂在日常的bug修复、功能增加等代码变更中,使得变更理解变得非常复杂.识别重构模式可以将重构与其它类型的代码变更隔离,利于变更理解.目前在识别重构模式的相关研究中,并没有结合变更类型和相似性比较的识别重构模式的方法及工具.为此,提出了一种基于细粒度变更类型和文本相似性比较识别重构模式的方法.将该方法应用于抽取类重构模式,并在4个开源项目中进行了实验,其平均准确率在82.6%左右.     

代码缺陷与代码味道的自动探测与优化研究

为了实现代码缺陷与代码味道的自动探测与优化, 提升优化与重构的效率, 设计并开发了一套名为SCORT的源代码优化与重构工具。SCORT将源代码解析为抽象语法树, 再探测其中存在的代码缺陷和代码味道, 最后对缺陷和味道进行自动优化和重构。在SCORT中已经实现了对15种常见代码缺陷和六种常见代码味道的检测以及自动优化与重构, 提供了多种代码味道的自动重构算法, 且具有良好的可扩展性。通过对三个待测项目的探测和优化实验结果表明, 对于常见代码缺陷的探测和优化, SCORT的精确率、召回率和准确率均可达100%; 对于部分常见的代码味道, SCORT尚需进一步完善。SCORT有助于开发人员提高代码质量, 减少源代码中存在的缺陷和味道。     

On the role of tests in test-driven development: a differentiated and partial replication

Background: Test-Driven Development (TDD) is claimed to have positive effects on external code quality and programmers’ productivity. The main driver for these possible improvements is the tests enforced by the test-first nature of TDD as previously investigated in a controlled experiment (i.e. the original study). Aim: Our goal is to examine the nature of the relationship between tests and external code quality as well as programmers’ productivity in order to verify/ refute the results of the original study. Method: We conducted a differentiated and partial replication of the original setting and the related analyses, with a focus on the role of tests. Specifically, while the original study compared test-first vs. test-last, our replication employed the test-first treatment only. The replication involved 30 students, working in pairs or as individuals, in the context of a graduate course, and resulted in 16 software artifacts developed. We performed linear regression to test the original study’s hypotheses, and analyses of covariance to test the additional hypotheses imposed by the changes in the replication settings. Results: We found significant correlation (Spearman coefficient = 0.66, with p-value = 0.004) between the number of tests and productivity, and a positive regression coefficient (p-value = 0.011). We found no significant correlation (Spearman coefficient = 0.41 with p-value = 0.11) between the number of tests and external code quality (regression coefficient p-value = 0.0513). For both cases we observed no statistically significant interaction caused by the subject units being individuals or pairs. Further, our results are consistent with the original study although there were changes in the timing constraints for finishing the task and the enforced development processes. Conclusions: This replication study confirms the results of the original study concerning the relationship between the number of tests vs. external code quality and programmer productivity. Moreover, this replication allows us to identify additional context variables, for which the original results still hold; namely the subject unit, timing constraint and isolation of test-first process. Based on our findings, we recommend practitioners to implement as many tests as possible in order to achieve higher baselines for quality and productivity.     

On the effectiveness of the test-first approach to programming

Test-driven development (TDD) is based on formalizing a piece of functionality as a test, implementing the functionality such that the test passes, and iterating the process. This paper describes a controlled experiment for evaluating an important aspect of TDD: in TDD, programmers write functional tests before the corresponding implementation code. The experiment was conducted with undergraduate students. While the experiment group applied a test-first strategy, the control group applied a more conventional development technique, writing tests after the implementation. Both groups followed an incremental process, adding new features one at a time and regression testing them. We found that test-first students on average wrote more tests and, in turn, students who wrote more tests tended to be more productive. We also observed that the minimum quality increased linearly with the number of programmer tests, independent of the development strategy employed.     

A test driven approach for aspectualizing legacy software using mock systems

Aspect-based refactoring, called aspectualization, involves moving program code that implements cross-cutting concerns into aspects. Such refactoring can improve the maintainability of legacy systems. Long compilation and weave times, and the lack of an appropriate testing methodology are two challenges to the aspectualization of large legacy systems. We propose an iterative test driven approach for creating and introducing aspects. The approach uses mock systems that enable aspect developers to quickly experiment with different pointcuts and advice, and reduce the compile and weave times. The approach also uses weave analysis, regression testing, and code coverage analysis to test the aspects. We developed several tools for unit and integration testing. We demonstrate the test driven approach in the context of large industrial C++ systems, and we provide guidelines for mock system creation.     

Test-driven modeling for model-driven development

A new software development process called test-driven modeling applies the Extreme Programming test-driven paradigm in a model-driven development environment. (The basis of this article is a project in Motorola's iDEN division that is extending and migrating a large legacy telecommunication system to new platforms using TDM.) This process involves automatic testing through simulation and using executable models as living software system architecture documents. In TDM, we use the same message sequence charts (MSCs) for both system analysis (or design documents) and unit test cases. Similarly, we use the same high-level modeling diagrams for both automatic code generation and living software architecture documents to guide the system's detailed implementation in later phases. Practical results show that developers can effectively apply TDM to large projects with high productivity and quality in terms of the number of code defects.     

An empirical study of relationships among extreme programming engineering activities

Extreme programming (XP) is an agile software process that promotes early and quick production of working code. In this paper, we investigated the relationship among three XP engineering activities: new design, refactoring, and error fix. We found that the more the new design performed to the system the less refactoring and error fix were performed. However, the refactoring and error fix efforts did not seem to be related. We also found that the error fix effort is related to number of days spent on each story, while new design is not. The relationship between the refactoring effort and number of days spent on each story was not conclusive.     

Supporting requirements to code traceability through refactoring

In this paper, we hypothesize that the distorted traceability tracks of a software system can be systematically re-established through refactoring, a set of behavior-preserving transformations for keeping the system quality under control during evolution. To test our hypothesis, we conduct an experimental analysis using three requirements-to-code datasets from various application domains. Our objective is to assess the impact of various refactoring methods on the performance of automated tracing tools based on information retrieval. Results show that renaming inconsistently named code identifiers, using Rename Identifier refactoring, often leads to improvements in traceability. In contrast, removing code clones, using eXtract Method (XM) refactoring, is found to be detrimental. In addition, results show that moving misplaced code fragments, using Move Method refactoring, has no significant impact on trace link retrieval. We further evaluate Rename Identifier refactoring by comparing its performance with other strategies often used to overcome the vocabulary mismatch problem in software artifacts. In addition, we propose and evaluate various techniques to mitigate the negative impact of XM refactoring. An effective traceability sign analysis is also conducted to quantify the effect of these refactoring methods on the vocabulary structure of software systems.     

A metamodeling approach to pattern-based model refactoring

Design patterns capture development solutions to design problems in forms that make the designs more modular, modifiable, reusable, and understandable. This metamodeling approach to pattern-based refactoring of design models incorporates the precise specification of design patterns and transformation rules.     

Assessing the capability of code smells to explain maintenance problems: an empirical study combining quantitative and qualitative data

Code smells are indicators of deeper design problems that may cause difficulties in the evolution of a software system. This paper investigates the capability of twelve code smells to reflect actual maintenance problems. Four medium-sized systems with equivalent functionality but dissimilar design were examined for code smells. Three change requests were implemented on the systems by six software developers, each of them working for up to four weeks. During that period, we recorded problems faced by developers and the associated Java files on a daily basis. We developed a binary logistic regression model, with “problematic file” as the dependent variable. Twelve code smells, file size, and churn constituted the independent variables. We found that violation of the Interface Segregation Principle (a.k.a. ISP violation) displayed the strongest connection with maintenance problems. Analysis of the nature of the problems, as reported by the developers in daily interviews and think-aloud sessions, strengthened our view about the relevance of this code smell. We observed, for example, that severe instances of problems relating to change propagation were associated with ISP violation. Based on our results, we recommend that code with ISP violation should be considered potentially problematic and be prioritized for refactoring.     

Increasing clone maintenance support by unifying clone detection and refactoring activities

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.     

Prioritizing test cases for early detection of refactoring faults

Refactoring edits are error‐prone, requiring cost‐effective testing. Regression test suites are often used as a safety net for decreasing the chances of behavioural changes. Because of the high costs related to handling massive test suites, prioritization techniques can be applied to reorder test case execution, fostering early fault detection. However, traditional prioritization techniques are not specifically designed for detecting refactoring‐related faults. This article proposes refactoring‐based approach (RBA), a refactoring‐aware strategy for prioritizing regression test cases. RBA reorders an existing test sequence, using a set of proposed refactoring fault models that define the refactoring's impact on program methods. Refactoring‐based approach's evaluation shows that it promotes early detection of refactoring faults and outperforms well‐known prioritization techniques in 71% of the cases. Moreover, it prioritizes fault‐revealing test cases close to one another in 73% of the cases, which can be useful for fault localization. Those findings show that RBA can considerably improve prioritization of test cases during perfective evolution, both by increasing fault‐detection rates as well as by helping to pinpoint defects introduced by an incorrect refactoring. Copyright © 2016 John Wiley & Sons, Ltd.     

Using model transformation to refactor use case models based on antipatterns

Use Case modeling is a popular technique for documenting functional requirements of software systems. Refactoring is the process of enhancing the structure of a software artifact without changing its intended behavior. Refactoring, which was first introduced for source code, has been extended for use case models. Antipatterns are low quality solutions to commonly occurring design problems. The presence of antipatterns in a use case model is likely to propagate defects to other software artifacts. Therefore, detection and refactoring of antipatterns in use case models is crucial for ensuring the overall quality of a software system. Model transformation can greatly ease several software development activities including model refactoring. In this paper, a model transformation approach is proposed for improving the quality of use case models. Model transformations which can detect antipattern instances in a given use case model, and refactor them appropriately are defined and implemented. The practicability of the approach is demonstrated by applying it on a case study that pertains to biodiversity database system. The results show that model transformations can efficiently improve quality of use case models by saving time and effort.     

代码坏味对软件演化影响的实证研究

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

Pattern-based framework for modularized software development and evolution robustness

Context

Software development is now facing much more challenges than ever before due to the intrinsic high complexity and the increasing demands of the quick-service-ready paradigm.

Objective

As the developers are now called for more quality software systems from the industries, there is insufficient guidance from the methodologies and standards of software engineering that can provide assistance to the rapid development of qualified business software.

Method

In this work, we discuss the advantages of the pattern-based software development. We verify the benefits using a pattern-based software framework called OS2F, and a corresponding system design architecture that is intended for the rapid development of web applications.

Results

The objective of the framework/architecture is that, through software patterns, developers should be able to separate the work of system development from the business rules so as to reduce the problems caused by a developer’s lack of business experiences.

Conclusion

Through a suitable pattern-based software framework, the quality of the product can thus be enhanced, software development time and cost decreased, and software evolution robustness improved.     

Web应用测试用例生成研究

随着Internet的高速发展,Web应用成为软件的主流之一,Web应用程序也变得越来越复杂,从多方面着手提高Web应用的质量是Web应用开发者的必然选择.Web应用测试是保证Web应用程序质量的重要手段,测试的核心工作是生成测试用例.把现有的Web测试用例生成方法归结为4类:Capture/Replay方法、HTML分析法、源代码分析法、User-Session分析法,随后对这4类方法进行详细讨论,并归纳出这4类方法生成测试用例的一般步骤.最后总结了这4种方法的优缺点,从方法实现的难易程度、覆盖率等方面比较了它们的性能.