In the literature, there are numerous publications dealing with software reuse, its foundations and possible improvements. Almeida et al. [Alm+04], for instance, defined a comprehensive framework for software reuse, which cleanly described its key ingredients. Besides the need for a repository and search infrastructure,
they describe a generic software reuse process and various best practices for effective software reuse. The main obstacle to software reuse today is no longer the lack of components to reuse or the ability to retrieve them efficiently. The main obstacle is the balance between the effort needed to evaluate and incor- porate components into new applications and the likely benefit (including the risk that a reuse candidate will turn out not to be suitable). This is where code recommendation tools come in. Their role is to non-intrusively and reliably find quality reusable code artifacts and to help developers integrate them into their systems with minimal effort.
Based on the lessons learned from the typical code search use cases described in the previous chapter, we can identify the most important characteristics that reuse-oriented code recommendation systems should provide and distinguish them from traditional code search engines. One of the major problems with code search engines is that developers have to leave their normal working environment to issue searches, which interrupts their development workflow. Moreover, since queries have to be executed in a different application (i.e., the web-browser) to the one where the system is developed (i.e., the developer’s IDE) there is also the problem of media change.
Without access to the immediate context of the code under development, it is a demanding task for a developer to formulate queries that define his/her goal and find reusable assets that fit into the new application. In addition, developers have to fully understand how the search engines work to be able to formulate adequate queries that will deliver precise results. And, last but not least, developers have to invest a significant amount of effort to manually evaluate and integrate reusable assets into their new applications. To try out any of the recommendations, they have to switch between at least two windows, and may even lose track of their original work and ideas during the search process.
All of the aforementioned issues related to code reuse need to be reflected within a reuse-oriented code recommendation system, which ideally supports the full automation of the reuse process as well as the responses to developers’ inputs.
decision to search description of request search recommendation selection reuse & maintain
Figure 5.1.: Overview of the Micro-Process of Software Reuse [JHA14].
A simplified visualization of the process of software reuse is sketched in Figure 5.1. The process itself is generic and applies to manual as well as tool-supported software search and reuse. It comprises five major steps, each of which will be elaborated in more detail in the following description:
decision During a software project it is advisable to reuse existing software assets in order to save effort. As we already know from Section 3.1, there is a wide variety of potentially reusable artifacts and this list will be enhanced in Section 5.4. Hence, if the general decision for reuse has been made, it is necessary to decide in particular what kind of assets can actually be reused. Based on these general decisions, software engineers can decide during the development lifecycle to search for reusable existing artifacts.
description Once there was the decision to look for reusable software artifacts, an abstract description of what should be reused needs to be created. This specification should ideally comprise all required information that is necessary to find useful reusable assets.
search The description serves as the query to a search engine. Sophisticated algorithms should be able to automatically refine and adapt queries in order to filter out all useless artifacts and ensure that all useful ones are included.
This is almost impossible without tool support, as it would consume a lot of time to create a query, inspect the results, refine and re-issue the query ...This cycle may have to be repeated several times and is obviously not very efficient when done manually.
selection From the “raw” set of search results, the developer needs to choose whether any of the results are useful and if there are any candidates that fulfill the given criteria. If there is more than one, the developer has to select the best match which can be a very tedious task since it may involve the trial use of a large number of possible candidates. If this is carried out manually, it involves the copying of the code from the search engine, looking for necessary dependencies, possibly adapting the provided interface of a reused class and finally trying it out. This must be performed for every candidate in order to find the most suitable candidate.
reuse and maintain Once a candidate has been selected for reuse and inte- grated into the developer’s system, the micro-process of code reuse is completed. Nevertheless, the reused candidates are now part of the devel- oper’s project development lifecycle and should be subject to all the same policies and processes as the other parts of the system like testing and maintenance.
Although the micro-process of reuse is complete, Figure 5.1 shows that reuse should not be a one-off event, in accordance with the ideas expressed in the literature (e.g., Krueger’s seminal work on software reuse [Kru92]). It should rather be continuously applied throughout the project development.
The following subsection provides an overview of state-of-the art recommen- dation systems for reusable code. In order to develop a reuse-oriented recom- mendation system for software tests, we will review them in the context of the aforementioned micro-process and identify their most outstanding characteris- tics. This will help us identify a general set of requirements for reuse-oriented code and test recommendation systems in software engineering.