Menu ▾ ▴

EMFQueryProcessor

Radu Comaneci

EMFQueryProcessor maps an EMFTrace rule to a query which can be run against the models from an EMFStore repository.

If you take a look at the Rule meta model definition which can be found in the RuleModel package, in the MetaModel plugin, you will see that the following fields need to be mandatory filled when a new rule is created:

  1. Elements - which are represented as a list of ElementDefinition objects
  2. Actions - which are represented as a list of ActionDefinition objects
  3. Conditions - which are represented as a LogicCondition object

However, EFMQueryProcessor doesn't crash and works even if the rule that is received doesn't contain all of this fields. But for getting the desired results you should specify all of these three fields.

Requirements and restrictions:

  1. An ElementDefinition object should always have a Type and an Alias. You can see the structure of this element by searching for it in the RuleModel package from the MetaModel plugin. EMFQueryProcessor doesn't assure that an ElementDefinition object has always a Type and an Alias that's why the client that is using it has to assure that these requirements are fulfilled. Of course this prerequisite needs to be fulfilled for each ElementDefinition object that appears in a Rule object.
  2. An ActionDefinition object should have always an ActionType. Now regarding to the ActionType object two different cases can be met:
    • The ActionType is TraceLink. In this case the ActionDefinition object needs to provide the ResultType, SourceElement and TargetElement.
    • The ActionType is ImpactReport. In this case the ActionDefinition object need to provide the ResultType, SourceElement and ImpactedElement. The TargetElement is optional and can be also provided or not. As above, EMFQueryProcessor doesn't take care of fulfilling this requirements which regard the ActionDefinition object, so the client that is using it has to take care of them.
  3. The LogicCondition object has to contain at least one BaseCondition object. If this requirement is not fulfilled, EMFQueryProcessor runs the query, but the output will be the same as the input since the condition that is applied returns true for every object (is the standard condition that is applied in case no LogicCondition is defined in the rule).

Instantiating EMFQueryProcessor and retrieving the results:

In order to be able to use EMFQueryProcessor you should instantiate it, send the accesslayer, the current project that you are working in and the desired rule. The accesslayer represents the connection between EMFTrace and the EMFStore repository database where the meta models are stored. The project variable represents the EMFStore project which is stored in the EMFStore repository and where the user is currently working in. The following code lines show you how to instantiate the EMFQueryProcessor and how to run a rule:

EMFQueryProcessor queryProcessor = new EMFQueryProcessor(accessLayer, project); 
List<EMFQueryElement> results = new ArrayList<EMFQueryElement>();
results = queryProcessor.run(rule);

After the run method was executed successfully the results of the query are available in the results list as EMFQueryElement objects. An EMFQueryElement is a tuple (since the results are represented as tuples) which is represented as a list of TupleElement objects (take a look at the QueryModel package from the MetaModel plugin to see the complete description of these classes). The following code lines show you how to access the elements from the results:

results.get(0);    //returns the first tuple of elements
results.get(0).getElements();    //returns the list of elements which represents the tuple
results.get(0).getElements().get(0);    //returns the first element from the first tuple
results.get(0).getElements().get(0).getName();    //returns the name of the first element as specified in the rule
results.get(0).getElements().get(0).getAlias();    //returns the alias of the first element as specified in the rule
results.get(0).getElements().get(0).getContent();    //returns the EObject which is stored in the first element of the first tuple

TuplesProcessor

An important component of EMFQueryProcessor is TuplesProcessor. This is responsible for generating the tuples which are sent as input to the query. The query iterates over these tuples, aplies the condition and reveals the results.
Normally, a TuplesProcessor object cannot be instantiated manually. It is part of the EMFQueryProcessor. However, if you really need to generate tuples based on a rule definition you can instantiate it using the following commands:

List<EMFQueryElement> tuples;
TuplesProcessor tuplesProcessor = new TuplesProcessor(accessLayer, project);
tuples = tuplesProcessor.run(elementsFromRepository);

The tuples processor returns a list of EMFQueryElement objects which represents the tuples of meta models from the EMFStore repository. The elements from this list can be accessed the same as the elements from the list of results since the structure of lists is the same (see the above section).
For the following ElementDefinition objects from a rule:

<Rule RuleID="RULE001">
  <Element Type="Class" Alias="e1"/>
  <Element Type="Parameter" Alias="e2"/>
  <Element Type="Function" Alias="e3"/>

the TupleProcesor would generate a list of EMFQueryElement objects with the following structure:

results = [Class, Parameter, Function]

where Class, Parameter and Function are all possible combinations of meta models from the EMFStore repository.

ConditionsProcessor

ConditionsProcessor is another component which is part of EMFQueryProcessor. It is responsible for generating the EObjectCondition based on the LogicCondition object from the rule definition.

MongoDB Logo MongoDB