Databases Reference
In-Depth Information
The remarks for
DayOfWeek
and
MultiMap
in Table
12.3
were Merobase could
not find results within the first 500 candidates mean that it was able to discover
three working version in a larger set of candidates (5,000 resp. 10,000). However,
the expressiveness of this comparison is unfortunately still somewhat limited since
Reiss has used different search engines with different retrieval algorithms that finally
delivered different candidates. It nevertheless demonstrates that Merobase achieves
a similar performance as another contemporary tool and is also able to deal with
completely unbiased reuse challenges independently specified by someone else so
that the technical feasibility of test-driven reuse has been illustrated one more time.
12.5 Related Work
After some years of relative silence around the turn of the millennium, a new mo-
mentum has become visible in the software retrieval community in recent years and
other approaches implementing a test-driven reuse approach have been presented by
other researchers. To our knowledge, two research groups have been developing and
experimenting with appropriate tools. As already mentioned, Reiss has developed
S6 [
33
], a web-based search tool where a user can list search keywords, specify
the declaration of one or more method headers and add test samples that describe
the semantics of the desired operation. According to Reiss's publication, S6 is also
able to “adapt” retrieved candidates by carrying out various internal program trans-
formations based on the abstract syntax tree of the potential result and to retrieve
numerous operations within one Java class. S6 is able to use its own search en-
gine called Labrador or a number of other code search engines such as Koders or
Sourcerer.
Sourcerer itself, which was developed by Bajracharya et al. [
37
] at the University
of California in Irvine implements a ranking approach similar to ComponentRank
[
22
] and is the foundation for another test-driven reuse tool called CodeGenie [
39
].
In contrast to S6, and similar to Code Conjurer, CodeGenie is fully integrated into
the Eclipse IDE and able to directly use JUnit test cases to drive a search for a miss-
ing Java method. In order to do so, CodeGenie analyses Eclipse's compiler errors
and tries to find missing classes respectively their methods via the Sourcerer search
engine. The user can inspect the candidates delivered by Sourcerer and can request
from CodeGenie to “weave” them into his project where they can be tested as usual
with the help of JUnit. One of the main contributions of Sourcerer and CodeGenie is
probably their ability to work even with declaratively incomplete program files (so-
called slices) that can also be woven into the project under development. In contrast
to Code Conjurer that always integrates complete files and tries to resolve missing
dependencies also on a per file basis, CodeGenie thus seems to be more flexible,
as far as this can be determined without a direct comparison on the same data set.
Clearly, it would be interesting to see such a comparison (of course also including
the capabilities of S6) to better understand the advantages and disadvantages of all
three tools, however, this is yet to be done.
Search WWH ::
Custom Search