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

7. Search results presentation. The search result must be presented in the devel-
oper's environment, so he/she can more easily reuse the artifacts into the project
he/she is currently working on.
B.A.R.T's architecture was based on the client-server model, and used Web Ser-
vices technology for message exchange among the subsystems. This implementa-
tion strategy allowed B.A.R.T to be available anywhere on the Internet, or even on a
corporate Intranet, in scenarios where the components are proprietary. B.A.R.T was
composed of two subsystems:
1. B.A.R.T Service: This subsystem is a Web Service, responsible for indexing
the components, in background, and responding to user queries. It is composed
of the following modules: the CVS module , which accesses the repositories in
the search for reusable components; the Analyzer , responsible for analyzing the
code in order to determine if it is suitable for indexing; the Indexer , responsible
for indexing the Java files that passed through the Analyzer, also rebuilding the
indexes when components are modified or inserted; the Download module, which
helps the download (check-out) process, when the source code is transferred to
the developer machine, after a request; and the Search module, which receives the
parameters of a query, interprets it (for example, “AND” and “OR” operators),
searches the index, and returns a set of index entries.
2. Eclipse plug-in: This subsystem is the visual interface the developer sees. It acts
as a Web Service client to access the B.A.R.T Service.
7.2.1 The Active Search Mechanism
B.A.R.T's first version performed search and retrieval essentially based on keywords
and facets. Moreover, the search mechanism was based on passive search, often used
in search engines, i.e. the mechanism waits passively until the user defines a set of
keywords and requests a search operation. For these reasons, much of the reuse
potential of the repositories being searched was being ignored, because in many
situations the developer does not have enough knowledge of the available assets
to start looking for them. Even with proper knowledge regarding the repositories,
the developer could simply fail to recognize a situation where a search could be
performed. In other words, the tool was lacking context awareness and a more active
behavior, in order to anticipate the developer's needs [ 30 ].
In this context, a second version of the tool was proposed [ 6 , 20 , 27 ] to con-
sider these and other issues. The following requirements were elicited for this new
version:
1. Extensibility: Software development involves a large number of steps and dif-
ferent intermediate types of asset are produced along the path. There are usu-
ally multiple alternative formats to build each type of asset and on top of that,
the information contained in the assets may be encoded in different languages.