Databases Reference
In-Depth Information
are as follows: li has role fiterator()g, iter has role fhasNext();next()g, and
b1 and b2 each have role fm()g.
Based on the role r of an object o, we compute its best-fitting type by
considering all supertypes of o's dynamic type that fullls r (that is, that
provides all methods of r). For each such supertype t, we compute the ratio
of the number of methods in r and the number of methods in t:
fit(r;t) =
jmethods(r)j
jmethods(t)j
For each object, we choose the type that maximizes fit, or in other words, that
minimizes the number of methods provided by the type that is not required
in the collaboration.
For the above example, li 's best-tting type is Iterable, where fit = 1 since
Iterable provides exactly the methods required by li 's role. Generalizing types
transforms one collaboration into another one.
4.2.3.2
Merging Objects
Another way to make collaborations more suitable for inferring API usage
protocols is to remove objects and method calls that do not add additional
information. For instance, the number of elements in the list li in Figure 4.3(a)
is not relevant for the way the API is used and may vary from one execution
of callM() to another. Considering all elements of li individually would give a
different usage protocol for each list with a different length.
Such a situation occurs whenever a program iterates over a collection and
calls the same methods on each element. To avoid polluting protocols with
incidental method calls, we merge all objects that have exactly the same role
into one artificial object. In the example, the analysis merges all instances of
B into one artificial instance that receives all calls to instances of B. Merging
objects transforms one collaboration into another one.
4.2.3.3
Package-Based Filtering
Most recurring API usage patterns are specific to a particular package. By
focusing on one package in each collaboration, our analysis can automatically
remove irrelevant method calls from the inferred protocols. For example, Fig-
ure 4.3(a) contains several calls related to java.util and a call to m(), which
seems irrelevant for a specification describing iterator usage.
To filter a collaboration for a package p, we remove all calls that do not
relate to p. A method call is said to relate to a package p if its callee, its
return value, or one of its parameters is an instance of a class in p. This
approach generalizes ideas from Weimer et al. [40], where two method calls
can only be part of the same specification if they are declared in the same
package. In contrast, we also consider calls that are in a direct dataflow rela-
tion to a particular package. Filtering the collaboration created by callM() in
Search WWH ::
Custom Search