Static API Specification Mining: Exploiting Source Code Model Checking - Mining Software Specifications: Methodologies and Applications - page 116

detect violations, without requiring any user input. Finally, Section 5.4 con-
cludes this chapter.
5.2 Static Trace Generation for Mining Specifications
In this section, we describe our framework [8] for mining specifications
automatically by analyzing the API client code. To mine specifications, the
framework presented in this section generates static traces related to APIs of
interest, directly from source code (API client code). Frequent API patterns
are then mined from the generated static traces. We identify two types of
API patterns { patterns that are specications and patterns that are usage
scenarios (see Section 5.2.1 for the definition of a scenario). Unlike specifica-
tions (such as \the bind API should be preceded by the socket API"), which
have to be satisfied by a program to be free from violations, usage scenarios
are API patterns specic to a given programming task (such as \refreshing a
user-interface window" or \displaying a drop-down menu"); usage scenarios
are not programming rules.
API patterns are often not documented by the API developers. Hence,
it is dicult for the system developers to effectively or correctly reuse these
APIs during system development or verify the correct usage of these APIs
after the system has been built, necessitating automated specification mining.
Our framework mines API patterns from static traces as partial orders (see
Section 5.2.2). We adapt a model checker to generate inter-procedural control-
flow-sensitive static traces related to the APIs of interest. In Section 5.3, we
show how our framework is adapted for mining API error-handling specifica-
tions. Next, we describe the motivation for mining API patterns as partial
orders.
Previous approaches have mined likely API patterns from software sys-
tems that reuse APIs. Some approaches [39{41, 43, 60, 62] exploit the static
program information extracted from system source code, whereas other ap-
proaches [11, 12, 64] exploit the dynamic program information extracted from
system executions, which require setup of runtime environments and availabil-
ity of sucient system tests. API patterns mined by most of these previous
approaches are in the form of frequent association rules, itemsets, or subse-
quences. Association rules [9, 41, 43] characterize pairs of API calls that are
often used together without considering their orders. Frequent itemsets [30,39]
characterize sets of API calls that are often used together without consider-
ing their orders. Frequent subsequences [58, 63] characterize sequences of API
calls that are often used together while considering their orders. Although
these mined API patterns have been shown to be useful to some extent, they