Experiences and Lessons Learned with the Development of a Source Code Search Engine - Finding Source Code on the Web for Remix and Reuse - page 120

from many different repositories, avoiding the writing of brand new code every time,
because a similar solution could have been implemented by somebody else [ 24 ].
The reuse literature presents [ 10 , 15 , 22 ] several approaches and tools related
to source code search and retrieval, including a wide variety of mechanisms and
techniques, from keywords and facets to context awareness. In this chapter, I present
the experience at RiSE (Reuse in Software Engineering) Labs 1 along the years,
with the B.A.R.T. (Basic Asset Retrieval Tool) project, whose main goal was the
development of a search engine for software code.
The remainder of this chapter is organized as follows. Section 7.2 presents the
B.A.R.T project and its different versions. Section 7.3 discusses the lessons learned
and some insight thoughts in the area. Finally, Sect. 7.4 concludes this chapter.

7.2 The B.A.R.T Project

The B.A.R.T project, formerly called Maracatu [ 9 ], was created based on the fol-
lowing motivation: in order to start the formation of a reuse culture in organizations
and obtain its initial benefits, first it is necessary to provide subsidies and tools for
the reuse of source code that is already available in the organization itself, from
previous projects, or from repositories available on the Internet.
Based on an extensive literature review [ 15 ] and our industrial experience at Re-
cife Center for Advanced Studies and Systems (C.E.S.A.R), we defined the set of
requirements for B.A.R.T's first version [ 9 ]. The main design decision was that a
source code search engine should consider the evolving and dynamic environment
that surrounds many development organizations. Differently from black-box reuse,
where there is usually more time to encapsulate the components and provide well-
structured documentation that facilitates searching, in many development reposito-
ries documentation is usually minimal, and mostly not structured. Figure 7.1 shows
the version using the Folksonomy mechanism (Sect. 7.2.2 ).
In this sense, a search engine should support two basic processes: (i) to locate
all reusable software artifacts that are stored in project repositories and maintain an
index of them. The indexing process should be automatic, and should consider non-
structured (free text) documentation; and (ii) to allow the user to search and retrieve
these artifacts, taking advantage of the index created in process (i).
Since in this scenario the artifacts are constantly changing, the first process must
be automatically performed on the background, maintaining the indexes always up-
dated and optimized according to a prescribed way. On the other hand, the developer
is responsible for starting the second, requesting possible reusable artifacts that suits
his/her problem.
Thus, in order to execute these two basic processes, some macro requirements
were defined:
1. Artifacts filtering. Although ideally all kinds of artifacts should be considered
for reuse (requirements, design specification, source code, test cases, test scripts

1

http://labs.rise.com.br .