Brief Description of Matching
Data Format
<rulebasematching>: Includes forward rules and backward
rules.
<forwardRule> : Forward
rules are inferred change-rules from the old version to the new version
usually.
<backwardRule>: Backward
rules are inferred change-rules from the new version to the old
version.
<transformation_rule> has a unique rule id,
“ruleID.id.” Each rule
has the following children nodes:
<scopedisjunction> list a set of <scope>
nodes.
<scope>: Each
<scope> is a set of method-headers in the domain (the old
version in forward matching, and the new version in backward matching).
Scope is expressed as a wild-card expression of
“packageS:classS-procedureS.__[parameterS]->returnS.”
Each rule
has a set of positive matches and a set of negative matches. Please
read my ICSE 2007 paper for the definition of positive matches and
negative matches.
<positiveMatches> has a <listpairs> child,
which lists a set of method-header level pairs from the domain to
co-domain.
<exceptionMatches> has a <listpairs> child,
which lists a set of method-header level pairs.
<forwardMatches> has a
<setpairs> child, which describes a set of method-header
level matches from the old version to the new verison.
<backwardMatches> has a
<setpairs> child, which describe a set of method-header
level matches from the new version to the old version.
<left> node is a
method-header in the old version. Its attribute describe which
change-rules explain that particular method-header’s
transformation.
<right> node is a
method-header in the new version.
Frequently Asked Questions
> I have three questions regarding the format of your data.
>
> In your jFreeChart results, what is the difference between
matching.xml,
> earlyExitmatching.xml and seedXsmatching.xml (I figured out
the remaining
> parts of the naming convention).
matching.xml - this matching result is generated by a seed
generation method described in the paper.
earlyExistmatching.xml - this matching result is generated by a
different seed generation method.
seedXsmatching.xml - this matching result is generated by
using Xing and Stroulia's results as seed matches.
> Regarding the XML format, what is the meaning of SQ71% in:
> <listpairs>
> <pair>
>
SQ71%{org.jfree.chart.demo:Pie3DChartDemo2-Pie3DChartDemo2__[String]->void
>
org.jfree.chart.demo:BarChartDemo2-BarChartDemo2__[String]->void}
> </pair>
> <pair>
>
SQ81%{org.jfree.chart.demo:Pie3DChartDemo2-main__[String[]]->void
>
org.jfree.chart.demo:BarChartDemo2-main__[String[]]->void}
> </pair>
> </listpairs>
>
SQ means Seed Quality. It is a basically seed similarity measure.
> Finally, what is the meaning of the <left> and
<right> tags at the end of
> the XML files? My understanding is that the first part of the
XML file
> describes your change rules along with the matches, then you
have all the
> matches (forwardMatches and backwardMatches), and then?
The ***matching.xml file has some redundant information for displaying
of matching results quickly.
<forwardRule> and <backwardRule> are
respectively rules from the old
version to the new version and rules from the new version to the old
version. In other words, we list matches from a rule perspective.
<forwardMatches> and <backwardMatches> are
respectively directional
matches from the old version to the new version and backward matches
from the new version to the old version respectively. In other words,
we list total matches.
Then, for each code element in the domain and codomain, we list
relevant rules.
For example,
<left id_0="forward_134" id_1="forward_147"
size="2">com.jrefinery.chart:ValueAxis-getCrosshairValue__[]->double</left>
means that the
"com.jrefinery.chart:ValueAxis-getCrosshairValue..."
code element in
the left (i.e., domain in the forward matching or a
set of method headers in the old version) are both explained by
forward rules 134 and 147.
Vice versa, code elements in the right (domain in the backward
matching or a set of method-headers in the new version) are explained
by one or more backward rules.
Hope this helps!