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

specific project belong to the query space, while the assets available in a repository
belong to the search space. The proposed metric was defined in terms of the set of
queries extracted from the query space and, from this set, the number of successful
queries against the search space.
The new search and retrieval process designed for B.A.R.T was composed of a
set of phases. The legacy content retrieval phase consisted on continuously monitor-
ing the produced assets and passing them for indexing. An asset evaluation policy
was necessary for determining whether a specific set of assets is proper for future
indexing. This policy was responsible for filtering low quality assets that would
negatively impact retrieval performance or cause problems if reused. It was also
responsible for determining when the index should be updated.
Once the assets were retrieved, the indexing phase took place. During this phase,
performed by B.A.R.T's Indexer module, the artifacts' contents were parsed and
analyzed before being actually indexed. The contents of the available artifacts were
converted to a common representation. This common representation was then inter-
preted during analysis and indexed, if considered relevant. The ubiquity requirement
wassatisfiedmainlybythe Listener module, which monitored and interpreted user
activities, like adding a method to a Java source file. From this interpretation, queries
were formulated and executed against the repository and reuse candidates could be
suggested to the user. This consisted on the active information delivery mechanism
of B.A.R.T. The queries were formulated by the query formulation agent, contained
in the Searcher module. The formulation was based on the contents of the artifacts
being edited by the developer in a similar approach to the repository indexing phase,
although the actual analysis performed could differ due to the distinct nature of de-
velopment for and with reuse.
The results evaluation and presentation phase was composed by the result eval-
uator agent, contained in the Searcher module, responsible for detecting candidates
that should not be presented to the user, based on the feedback provided from previ-
ous interactions or on information that was not available in the index and therefore
could not be taken into account during search time. The remaining results from the
analysis were then manipulated and finally presented to the user by the Presenter
module. This module was responsible for determining how and when these candi-
dates were presented to the user. Cognitive issues like the level of intrusiveness of
the delivery were also taken into account when making these decisions.
The search results were presented to the user by the Presenter module. The next
step was the indexed contents retrieval phase, performed by the Searcher module,
initiated upon user request. This phase was responsible for providing the system
with user feedback (which assets were considered relevant to his context) and re-
trieving the actual asset from the repository system. The phases presented so far
corresponded to the active information delivery cycle . Complementarily to this cy-
cle, the metrics extraction phase took a more general look at the produced artifacts
from the organizational perspective. All previous phases, except the legacy contents
retrieval and repository indexing phases, were focused on reuse from the individual
perspective, aiming at helping developers in achieving a higher reuse activity. This
phase, performed by the Extractor module, was responsible for ensuring that given