Eclipse Community Forums: VIATRA » Evolving Set of Model Invariants

Home » Modeling » VIATRA » Evolving Set of Model Invariants(What is the best way to deal an evolving set of model invariants?)

Show: Today's Messages :: Show Polls :: Message Navigator

Evolving Set of Model Invariants [message #1828022]

Fri, 29 May 2020 09:40

Hans van der Laan

Messages: 34
Registered: February 2020

Member

Hey,

I'm experimenting how one could use VIATRA to check an evolving set of invariants on a model, i.e. a set of constraints in which constraints get added, removed and modified during runtime.

How I see it, I have two options. However, I'm unsure which of the two options is the most appropriate. Furthermore, I'm not sure if I might have overlooked an option.

The two options I see are:

Translate the constraints into VQL patterns, write these to a file and load/remove them with the Query Generic API as shown in section 4 of the
Query API (https://www.eclipse.org/viatra/documentation/query-api.html) and as discussed in: https://www.eclipse.org/forums/index.php/t/1101236/
Incorporate the constraints somehow into the model, and have generic queries which can be "instantiated" through model elements.

To clarify the second option, consider the following model:

Here, we have meta-model of a policy in which users can be assigned roles.
Imagine that we want to check two constraints: mutual exclusivity of roles (only role A or role B should be assigned, not both) and
the dependency between roles (when role A is assigned, role B should also be assigned and vice versa). Given the presented metamodel,
these constraints could respectively be checked with the following patters:

pattern MutualExclusivity(constraint: MutualExclusivityConstraint, user: User, roleR: Role, roleL:Role) {
	MutualExclusivityConstraint.rightside(constraint, roleR);
	MutualExclusivityConstraint.leftside(constraint, roleL);
	Role.RU(roleR, user);
   	Role.RU(roleL, user);
}

pattern Dependency(constraint: DependencyConstraint, user: User, roleR: Role, roleL:Role) {
	DependencyConstraint.rightside(constraint, roleR);
	DependencyConstraint.leftside(constraint, roleL);
	Role.RU(roleR, user);
   	neg Role.RU(roleL, user);
} or {
	DependencyConstraint.rightside(constraint, roleR);
	DependencyConstraint.leftside(constraint, roleL);
	Role.RU(roleL, user);
   	neg Role.RU(roleR, user);
}

At the moment, I'm gravitating toward the second option because I think it will be much easier to implement, test, and keep track of the added/removed patterns.
Furthermore, as far as I can see, if I would want to change a constraint with option 1, I would have to completely remove the old version and add the new version.
However, I can image this might not be the most performant solution. Perhaps if I would add them directly as queries, the engine can do some (underwater) optimizations.
As I'm new to VIATRA, there might also be other aspects to the problem I'm not yet seeing.

As this will be quite a time investment, I'm wondering which option other people think is most appropriate. Any recommendations? :)

Report message to a moderator

Re: Evolving Set of Model Invariants [message #1828036 is a reply to message #1828022]

Fri, 29 May 2020 16:24

Zoltan Ujhelyi

Messages: 392
Registered: July 2015

Senior Member

Hi Hans,

this is an interesting problem that does not have a single appropriate solution, but there are be many approaches to be taken with different tradeoffs with regards to flexibility vs easy implementation.

1) One option would be to have a list of predetermined queries that you write and compile with your metamodel and provide a way to map them to various types (similar to what you have mentioned in your second option). This mapping could be done on the type-level in code, e.g. you maintain a static map that maps the `DependencyConstraint` type to the appropriate pre-compiled Query Specification instance. This approach is easy to implement and does not require anything special, and you can select the queries to be loaded based on the model contents and a static mapping (without relying on the pattern parsing infrastructure). However, the biggest drawback of this approach is that it is inflexible: to add new constraint types, you have to update your metamodels.

2) A more flexible way would be to add a string attribute to the constraint type that refers to a generated query by qualified name. The runtime can check the query specification registry to find the query specification instances (in an Eclipse environment this gets filled automatically using the extension mechanism, but it can be done programmatically as well). This is still quite simple to implement but already allows adding new constraint implementations without extending the metamodel.

3) The most elegant solution would be to store a textual representation of your patterns in the model, however, this would require to use the parsing infrastructure that is non-trivial, as it has to consider a lot of tricky corner cases, including but not limited to handling qualified name conflicts, the scope of pattern composition, handling incorrectly written patterns and an incremental way to reparse only patterns that might have been changed by an editing operation. A lot of these cases are already handled by our AdvancedPatternParser class (https://git.eclipse.org/c/viatra/org.eclipse.viatra.git/tree/query/plugins/org.eclipse.viatra.query.patternlanguage.emf/src/org/eclipse/viatra/query/patternlanguage/emf/util/AdvancedPatternParser.java), and if think such functionality is necessary, I strongly recommend relying on this implementation instead of rolling your own, as this problem domain gets complex very quickly. One further thing to note here is that relying on the pattern parser would cause your runtime to depend on the Xtext infrastructure.

Unless you really require the extra flexibility of parsing everything on-the-fly, I'd go with option 1) or 2) as they are much easier to implement, furthermore, you could still rely on the generated query code that is much easier to use than the generic pattern matcher and pattern parser implementations. But we have also implemented the third approach where it was essential to work with user-provided patterns, so I know it's doable even if it is complicated.

I hope I was clear and have answered your question. If not feel free to ask for clarifications.

Best regards,
Zoltán

Report message to a moderator

Re: Evolving Set of Model Invariants [message #1828134 is a reply to message #1828036]

Tue, 02 June 2020 09:11

Hans van der Laan

Messages: 34
Registered: February 2020

Member

Hey Zoltan,

Thank you for the extensive answer! I'm not working with user-provided patterns, so doing something like 3) won't be necessary.

The second solution sounds as the best option for my use-case. However, I don't see how I could do this yet implementation-wise.
Could you give me some pointers as to which methods I should take a look at? Do you perhaps have an small example where you show how
this can be done outside of an eclipse environment?

Kind regards,

Hans

Report message to a moderator

Re: Evolving Set of Model Invariants [message #1828151 is a reply to message #1828134]

Tue, 02 June 2020 17:08

Zoltan Ujhelyi

Messages: 392
Registered: July 2015

Senior Member

Hi Hans,

to be honest, we don't have an example for that but the documentation of VIATRA at least has some related entries in [1]. The implementation is a bit on the complex side, as the registry can rely on multiple query specification sources that might be dynamic (think of the query specifications defined in the workspace), but the documentation should be up-to-date. In case of issues, you can have a look at the class ExtensionBasedQuerySpecificationLoader [2].

Best regards,
Zoltán

[1] https://www.eclipse.org/viatra/documentation/query-api.html#_query_specification_registry
[2] https://git.eclipse.org/c/viatra/org.eclipse.viatra.git/tree/query/plugins/org.eclipse.viatra.query.runtime/src/org/eclipse/viatra/query/runtime/registry/ExtensionBasedQuerySpecificationLoader.java

Report message to a moderator