DynaMine: Finding Usage Patterns and Their Violations by Mining Software Repositories - Mining Software Specifications: Methodologies and Applications - page 222

Tables 7.5 and 7.6 also summarize dynamic results for matching pairs. The
tables provide dynamic and static counts of validated and violated patterns
as well as a classification into usage, error, and unlikely patterns. Below we
summarize some observations about the data. About a half of all method pair
patterns that we selected from the filtered mined results were confirmed as
likely patterns, out of those 10 were usage patterns and 8 were error pat-
terns. Many more potentially interesting matching pairs become available if
we consider lower support counts; for the experiments we have only considered
patterns with a support of four or more.
Several characteristic pairs are described below. Both locking pairs in
jEdit h writeLock , writeUnlock i and h readLock , readUnlock i are excellent
usage patterns with no violations. h contentInserted , contentRemoved i is
not a good pattern despite the method names: The first method is triggered
when text is added in an editor window; the second when text is removed.
Clearly, there is no reason why these two methods have to match. Method pair
h addNotify , removeNotify i is perfectly matched, however, its support is not
sucient to declare it a usage pattern. A somewhat unusual kind of matching
methods that at first we thought was caused by noise in the data consists of
a constructor call followed by a method call, such as the pair h OpenEvent ,
fireOpen i. This sort of pattern indicates that all objects of type OpenEvent
should be \consumed" by passing them into method fireOpen . Violations of
this pattern may lead to resource and memory leaks, a serious problem in long-
running Java programs such as Eclipse, which may be open at a developer's
desktop for days.
Overall, corrective ranking was significantly more effective than regular
ranking schemes that are based on the product of confidence values. The top
half of the table that addresses patterns obtained with corrective ranking con-
tains 24 matching method pairs; the second half that deals with the patterns
obtained with regular ranking contains 28 pairs. Looking at the subtotals for
each ranking scheme reveals 241 static validating instances versus only 104 for
regular ranking; 222 static error instances are found versus only 32 for regu-
lar ranking. Finally, 11 pairs found with corrective ranking were dynamically
confirmed as either error or usage patterns versus 7 for regular ranking. This
confirms our belief that corrective ranking is more effective.

7.5.2.2 State Machines

In many of cases, the order in which methods are supposed to be called on a
given object can easily be captured with a finite state machine. Typically, such
state machines must be followed precisely; omitting or repeating a method call
is a sign of error. The fact that state machines are encountered often is not
surprising; state machines are the simplest formalism for describing the object
life-cycle [40]. Matching method pairs are a specific case of state machines, but
there are other prominent cases that involve more that two methods, which
are the focus of this section.