Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different Answers for Cyclic Recursive Patterns using DRED and DDF #127

Open
eclipse-viatra-bot opened this issue Mar 12, 2024 · 2 comments
Labels
bug Something isn't working bugzilla Issues migrated from Eclipse bugzilla. Query Issues related to the query component of VIATRA, including runtime or pattern language issues.

Comments

@eclipse-viatra-bot
Copy link

| --- | --- |
| Bugzilla Link | 567352 |
| Status | UNCONFIRMED |
| Importance | P3 normal |
| Reported | Sep 25, 2020 08:11 EDT |
| Modified | Oct 12, 2020 08:08 EDT |
| Version | 2.3.2 |
| Reporter | Hans van der Laan |

Description

Hey,

I have a cyclic recursive pattern and I get different results using DRED and DDF. I get a correct results with DRED and an incorrect result using DDF.
I'm not sure if it's a bug, a property of the algorithm or if I forgot to set a specific flag.

The pattern where it goes wrong deals with reachability. Specifically, with a pattern which tries to capture accessibility of security zones. We say a security zone is accessible for a given user during a given scenario if:
-case 1: the security zone is connected to the outside world and unlocked,
-case 2: the security zone connected to the outside world, protected with access control (1) and the user has the permission to access it,
-case 3: the security zone can be reached from another security zone which is accessible for this user during the given scenario and it is unlocked,
-case 4: the security zone can be reached from another security zone which is accessible for this user during the given scenario, it is protected with access control and the user has the permission to access it.

pattern SecurityZoneAccessible(user: User, scenario: java Scenario, zone: SecurityZone) {
SecurityZone.public(zone, true); // case 1
find SecurityZoneAccessStatus(scenario, zone, 0); // 0 == unlocked
User(user);
} or {
SecurityZone.public(zone, true); // case 2
find SecurityZoneAccessStatus(scenario, zone, 1); // 1 == protected with access control measures.
find USO(user, scenario, zone);
} or {
find SecurityZoneAccessStatus(scenario, zone, 0); // case 3
SecurityZone.reachable(prev,zone);
find SecurityZoneAccessible(user, scenario, prev);
} or {
find SecurityZoneAccessStatus(scenario, zone, 1); // case 4
SecurityZone.reachable(prev,zone);
find SecurityZoneAccessible(user, scenario, prev);
find USO(user, scenario, zone);
}

If we take a simple a building:

-> lobby <-> open office <-> break room

where the lobby is connected to the outside world and the open office, the open office is connected to the breakroom and the lobby and the breakroom is only connected to the open office.

If I initially say the lobby is unlocked and both the open office and the breakroom are protected with access control measures, I get the correct result when I initially compute reachability. However, if I subsequently lock the lobby DRED converges to the correct answer while DDF does not. Namely, with DRED I correctly obtain no security zone is accessible while with DDF I get that the open office and the breakroom are (still) reachable.

This reminds me of the discussion we had when I started with VIATRA about recursive patterns, the (minimal) fixed points of queries (and the happy Martians). I though DDF should be able to deal with these kinds of cases.

I create the engines as follows:

DRED:
ViatraQueryEngineOptions options = ViatraQueryEngineOptions.defineOptions()
.withDefaultBackend(DRedReteBackendFactory.INSTANCE)
.withDefaultCachingBackend(DRedReteBackendFactory.INSTANCE)
.build();

DDF:
ViatraQueryEngineOptions options = ViatraQueryEngineOptions.defineOptions()
.withDefaultBackend(TimelyReteBackendFactory.INSTANCE)
.withDefaultCachingBackend(TimelyReteBackendFactory.INSTANCE)
.build();

@eclipse-viatra-bot eclipse-viatra-bot added bugzilla Issues migrated from Eclipse bugzilla. legacy Query Issues related to the query component of VIATRA, including runtime or pattern language issues. labels Mar 12, 2024
@eclipse-viatra-bot
Copy link
Author

By Hans van der Laan on Oct 12, 2020 08:00

Can anyone confirm if this is a bug or intended behaviour?

@eclipse-viatra-bot
Copy link
Author

By Zoltan Ujhelyi on Oct 12, 2020 08:08

(In reply to Hans van der Laan from comment #1)

Can anyone confirm if this is a bug or intended behaviour?

Sorry for the late response. Gábor Bergmann was on vacation, and with regards these deep algorithmic question he would be the best person to answer. There are some corner cases that some algorithm supports but the other not. My expectation would be that the result should not depend on the algorithms, but I am not entirely sure about that.

@ujhelyiz ujhelyiz removed the legacy label Mar 25, 2024
@ujhelyiz ujhelyiz added the bug Something isn't working label Apr 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working bugzilla Issues migrated from Eclipse bugzilla. Query Issues related to the query component of VIATRA, including runtime or pattern language issues.
Projects
None yet
Development

No branches or pull requests

2 participants