Automated Formal Static Analysis and Retrieval of Source Code - JKU

3.2. INTEGRATION OF MINDBREEZE CODE SEARCH INTO MINDBREEZE ENTERPRISE SEARCH41
We created tables for each CodeSearch artifact, for some of their metadata and the relations
that were established between the hit-types of the artifacts. For instance, the table callables
refers to the callables artifacts, the table returns refers to its return value, the table is descendant
refers to the artifact one level up in the hierarchy.
The client application that connects to the SQLite database engine uses a generic database
access class for this purpose.
More details about the integration can be found in [Luk08].
3.2.2 Query Service Context Provider Interface Enhancements
Scenarios like 3.2.1.6, involving relations between the hit-types, are not possible with simple text
and faceted search using the existing Mindbreeze Query Language.
How the services and interfaces interact as well as where is necessary an enhancement of the
infrastructure or interfaces involved is depicted in the Figure 3.5.
Figure 3.5: Scenario requiring Query Service Context Provider Interface Enhancements
What components of the MCS architecture interact and how is explained as follows.
Step 1. A query is introduced in the client interface by the user. The query is taken over by
the Query Service which creates a Query object, an instance of the IQueryFactory interface and
of Constraint class.
Step 2. The query might be performed into the index. In this case the user is querying static
information about a hit-type. This kind of query is done by simple and faceted text searching,
when the central role is played by the query language.
We assume the structure of the index like in Table 3.3.
Step 3. The hit types fulfilling the query are a subset of the hit types stored into the index
Table 3.3.