We have carried out a number of initial experiments to determine whether the approach of automated-adaptation is feasible and if it delivers significantly more results than test-driven search without adaptation. In Table 4.2 we present some examples that illustrate the improvement of test-driven search with adaptation to test-driven search without adaptation. The first column of the Table outlines the required interface of the desired component defined by a test case, while the second column (TD) shows the number of reusable software components returned for a plain test-driven search. The third column (TDA) contains the number of results returned for test-driven searches with automated result adaptation. For this purpose, we looked at the first fifty candidates returned by Merobase.
These example searches demonstrate the benefits of enhancing test-driven reuse with automated adaptation. While the search for a Calculator, Stack and Prime class could have been achieved by a simple test-driven search without adaptation, the slightly more complex search for a Document fails completely without adaptation. With adaptation it returns 14 results which pass the user’s test case. An efficient adaptation algorithm such as that implemented in Merobase therefore enables test-driven searches to return significantly more results in a given period of time.
Required Interface TD TDA CreditCard( validate(long):boolean; 0 / 50 2 / 50 ) Calculator( add(int,int):int; 3 / 50 6 / 50 subtract(int,int):int; ) Stack( pop():Object; push(Object):void; 7 / 50 11 / 50 isEmpty{}:boolean; ) Prime( isPrime(int):boolean; 1 / 50 3 / 50 ) Document( Document(String,String,int); getAuthor():String; 0 / 50 14 / 50 getTitle():String; getYear():int; )
Table 4.2.: Exemplary Searches With and Without Adaptation.
The execution of the examples from Table 4.2 could be performed in less than 10 seconds, making the overall process of code search by Merobase and re- sult presentation by Code Conjurer sufficiently fast for on-demand component recommendation.
4.4. Summary
Based on the ideas presented in the literature, we have developed and presented an enhanced system for the automated adaptation of software components.
In order to develop an efficient test-reuse environment, which returns result in a reasonable time, it was necessary to enhance the existing approaches for automated adaptation. We described the enhanced process and sketched the idea of distributed adaptation on multiple adaptation clients in Figure 4.1 on page 58. Finally, the result of our investigation was a system for automated com- ponent adaptation, which is significantly faster than the initial implementation in Merobase [Hum08].
In the following chapter, we will discuss possible approaches for improving the way software search is integrated into developers’ workflows. We will survey modern reuse-oriented code recommendation systems and distill the necessary properties for a recommendation system for software tests.
Contribution of this chapter
• In the context of the Merobase code search engine, we presented an im- proved approach for the automated adaptation of software components, which utilizes pre-adaptation filtering for efficiency improvement.
• We introduced a client-server architecture for automated adaptation that ensures high scalability for the automated adaptation of software compo- nent interfaces and supports better performance for test-driven searches.
“
a programmer with a soldering iron, a hardware type with a program patch and a user with an idea.”
The Wizardry Consulted Rick Cook, Sci-Fi author
5
Reuse-Oriented Code
Recommendation Systems
Most recommendation systems in software engineering aim to leverage data acquired by mining previous software projects and experience factories with a view to enhancing the decision making process of engineers and managers in new software projects. The decisions involved can include the creation of software implementations and tests, the development of requirements and designs, or indeed any other activity in software engineering. However, in most cases the artifacts from which the data were mined are not directly reused in new software projects, only the knowledge that was mined from them. Since we are going to develop a reuse-oriented recommendation system for software tests later in this thesis, this chapter presents the state of the art for reuse-oriented code recommendation (ROCR) systems [JHA14].
5.1. Recommendation Systems for Code Reuse
Reuse-oriented recommendation systems use data derived from the artifacts in software repositories and project archives with a view to pointing out opportuni- ties for reusing the original artifacts themselves. A subcategory of reuse-oriented recommendation systems focuses on suggesting opportunities for reusing exe- cutable code. In a sense, ROCR systems are a special case of the more general form of recommendation engines. Their “mined” data is executable software. However, the artifacts recommended by such systems need not just be func- tional production code. All kinds of executable software used in the lifecycle of a project such as tests, prototypes, frameworks, environments etc. can be reused. Moreover, reuse can take many forms ranging from the direct inclusion of the artifact in the new software product to the use of the artifact to test the software product or provide oracle data to drive the testing process.Before thinking of the creation of a recommendation system for test reuse, it is necessary to identify the requirements for such a system. Since the idea of test reuse represents a special case of software reuse in general, the same challenges and obstacles may apply to it and should be investigated in more detail. The development of an efficient test reuse and recommendation system thus needs to deal with the well-known challenges from traditional component reuse [HJA08; JHA14], which include
• the availability of a sufficiently large source of reusable artifacts (the so- called repository problem [FHR91; Sea99; Hum08]),
• the ability to effectively store and represent the reusable material (the so-called representation problem [FP94]),
• the ability to retrieve meaningful results from a repository of reusable artifacts (the so-called retrieval problem [MMM98; Hum08]),
• and the influence of the make-versus-reuse decision so that reuse is more cost-effective than the creation of artifacts from scratch.
A great deal of progress has been made in the mentioned areas over the last few years [HA06], and solutions to these problems have laid the foundation for the new generation of software search engines that appeared at the end of the first decade of the 2000s. However, while software search capabilities are an essential prerequisite for code recommendation tools, plain search engines cannot be regarded as code recommendation engines. They are necessary, but not sufficient. A true code recommendation system must also include a proactive agent that monitors the activities of a developer and unobtrusively issue queries in the background that can yield recommendations matching the context of the developer’s code. Ideally, a code recommendation engine should also automate the process of evaluating / testing reuse candidates and of including them into the developer’s new applications.
In this chapter we discuss the range of opportunities, challenges and techniques that reuse-oriented code recommendation engines can contribute to the software engineering process and survey the existing landscape of well-known academic tools. Building on the insights on software search technologies from Section 3 and the characteristics that state-of-the-art code search engines can provide today, we investigate how modern code recommendations systems are constructed. We continue by discussing the overall goal of code reuse in order to identify the requirements that a code recommendation tool should fulfill, which requirements have already been met, and which are yet to be considered. In the main part of the chapter we then discuss each of the existing research code recommendation tools in turn, describing their motivation, architecture and strengths / weaknesses. Finally, we conclude this chapter with a summary and some thoughts about where the future lies for the code recommendation technology.