Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » VIATRA » Evolving Set of Model Invariants(What is the best way to deal an evolving set of model invariants?)
Evolving Set of Model Invariants [message #1828022] Fri, 29 May 2020 09:40 Go to next message
Hans van der Laan is currently offline Hans van der LaanFriend
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:

  1. 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/
  2. 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:

https://i.imgur.com/7wGRe7C.png

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? :)
Re: Evolving Set of Model Invariants [message #1828036 is a reply to message #1828022] Fri, 29 May 2020 16:24 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 379
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
Re: Evolving Set of Model Invariants [message #1828134 is a reply to message #1828036] Tue, 02 June 2020 09:11 Go to previous messageGo to next message
Hans van der Laan is currently offline Hans van der LaanFriend
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
Re: Evolving Set of Model Invariants [message #1828151 is a reply to message #1828134] Tue, 02 June 2020 17:08 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
Messages: 379
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
Re: Evolving Set of Model Invariants [message #1828273 is a reply to message #1828151] Fri, 05 June 2020 11:00 Go to previous message
Hans van der Laan is currently offline Hans van der LaanFriend
Messages: 34
Registered: February 2020
Member
Hey Zoltán

Thank you for the pointers. When I'll have it working I will try to publish a small minimal example in this thread.

Kind regards,

Hans
Previous Topic:Consistency Checking - Viatra
Next Topic:Rete Visualizer Node Explanations
Goto Forum:
  


Current Time: Wed Nov 25 00:59:25 GMT 2020

Powered by FUDForum. Page generated in 0.01792 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top