

User Tools

Site Tools

The JTransformer Fact Generation Process

The following Classes and Interfaces play a role in the Fact generation process:

The following implementations should be mentioned seperatly for their importance in the current Implementation:

The intermediate form of a Fact that is passed to the Prolog System does not yet contain globally valid IDs, instead it uses IDs local to the current file, encapsulated by the lId(X) term. These are generated by the localidgenerator, a class that returns a new ID with each call to getID(). Thus, all non-interface Elements of the Java file will be assigned such lId()-Terms.

In the case if interface elements, which may be referenced in other classes, first we generate an fqn()-term that fully qualifies the Interface Element. These terms are rather large, however, and so we add aliases in the form of lId()-Terms. This translation is done by the localidfqntranslator Object, which maps the fqn-terms to local IDs.

Local2FQN facts are added to the source file, showing which local IDs are actually aliases for fully qualified names (which need to be saved by the Prolog system, so external references get linked to the correct facts).

factgenerator: This is the core of the Translation engine. This class visits the Eclipse-Generated abstract syntax tree, and generates facts from it.

IDGenerator: This interface provides “fresh” ids, each call to getID() is guaranteed to create an ID this object never before returned. This is useful and necessary because several classes (FQNTranslator implementations and IDResolver, and so on) need to generate fresh IDs.

IDResolver: This class provides the mapping of AST nodes to IDs, producing fqn()-terms in the case of interface Elements, passing them through the FQNTranslator instance that was used to initialize the particular IDResolver.

typeresolver: Generates type(…) terms that are used to specifiy the types of variable declarations, parameters and so on.

FQNTranslator: Instances are used to transform the internal fqn()-terms into a particular form (like local IDs), that are shorter and/or more accessable then the raw fully qualified names.

prologwriter: Provides helper Methods to write Prolog Facts

prependableprologwriter: Using local IDs for fully qualified names makes it necessary to prepend a table of these Aliases. The prependableprologwriter makes that possible.

localidgenerator: generates lId()-Terms

localidfqntranslator: Translates an fqn()-term into a local ID, saving the mapping that it can later be extracted.

Example of node translation

class bar {
  abstract public void foo(int bar);

Let us assume the Method Declaration is visited by the factgenerator. This means the node is passed to the IDResolver, which in our case does not know the Method's ID yet. Since a method is an interface element, an fqn()-term is generated by the IDResolver. In our case, this would be: fqn('bar', 'foo', [int]). This FQN is then passed to translateFQN() in the FQNTranslator. Assume we are using a localidfqntranslator. Then the translator checks if it already knows this fqn. It does not, and thus uses an IDGenerator object to create a new local ID for the fqn term, saving the relationship. In this case, the term is lId(1). It returns the local ID as a String. Once the class has been completely translated, the mapping can be extracted. In this case, a Local2FQN term would be added to the factfile: local2FQN(lId(1), fqn('bar', 'foo', [int]).

Finally, the actual fact (a methodDefT fact) is wrapped in an inTe, which causes the Prolog System to interpret it as soon as it is loaded into the factbase, and posted as a query.

research/jtransformer/jtransformerfactgeneration.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019