VIATRA/Query/DeveloperDocumentation/LocalSearch/ConstraintApplicationCondition

Constraint application conditions in different modeling environments

The adornment of a search operation derived from a constraint is considered as the application condition of the operation. Based on the type system of the modeling environment and the state of the available indexes (both base and match index) different application conditions can be considered. This page is intended to give an overview of such scenarios under different circumstances.

General case (no base index, no match index)

This could be the general case for constraint application. Under such circumstances, allowed operation adornments are the following:

• Node constraint:
  • Unary constraint: F, B
• Edge constraint
  • Binary constraint (link between two elements): BF, BB
  • Ordered binary constraint (middle variable is the index of the target): BFF, BBF, BFB, BBB
  • Ternary constraint (Typically means a link of a given edge type that connects two elements): BFF, FBF, BBF, BBB
• Attribute constraint: this can be considered as a special case for edge constraint, where the attribute value is typically a constant of a given data type
• Other:
  • Generic n-ary constraints (e.g. pattern call): in this case we have no additional information about the constraint, so preferred variable binding is BB...B

Incremental indexing

In this case index is available for certain type of model elements (nodes, edges, attributes) and/or matches for certain patterns. Advantages:

• Indexed elements can easily be enumerated
• Inverse navigation along indexed edges is also possible, so that additional valid application conditions are the followings for edge constraints:
  • Binary constraint: FB, FF
  • Ordered binary constraint: FBB, FFB
  • Ternary constraint: FBB, FFB
• In case of positive pattern calls during local search-based pattern matching, the results of a previously initialized RETE pattern matcher can be used for a very low cost, if such matcher is available. (NOTE: however, if no such matcher exists, it is a nontrivial problem to determine whether it is worth initializing a RETE matcher for a sub-pattern or not.)

EMF specific assumptions

EMF provides some extra information about the object and relation types for model elements. This means that subtype-supertype relations as well as the objects . This information can mainly be used for two purposes:

• Infer the most specific type of a variable and then only consider model object of that type
• Obtain the inverse of a binary relation. In case of EMF, this means obtaining the eOpposite feature. Using this opportunity, for binary relations the adornment FB can also be an application condition, for it can be converted to a BF condition for the inverse of the feature.

VIATRA specializations, limitations

Additional assumptions In VIATRA, edge constraints involve type constraints for the associated model elements forming a link. Limitations In the current state of the VQL, position of an object in an ordered collection cannot be queried (ordered binary edge constraint). Also, ternary edge constraints cannot be expressed.