GT: Democles errors when just one negative invocation

[patrickrobrecht]

When having just one negative invocation on a pattern and all nodes of the invoked pattern are mapped, there is a "No valid search plan is available" exception in Democles:

java.lang.RuntimeException: No valid search plan is available
    at org.gervarro.plan.dynprog.Algorithm.generatePlan(Algorithm.java:78)
    at org.gervarro.democles.plan.incremental.leaf.ReteSearchPlanAlgorithmSession.run(ReteSearchPlanAlgorithmSession.java:58)
    at org.gervarro.democles.interpreter.incremental.rete.RetePatternMatcherModule.getSession(RetePatternMatcherModule.java:104)
    at org.emoflon.ibex.gt.democles.runtime.DemoclesGTEngine.createAndRegisterPatterns(DemoclesGTEngine.java:158)
...

(The reddish background stands for a negative pattern invocation.)

When I add some senseless positive invocation as shown in the following picture, it works:

As I expected that the added positive pattern invocation does not make any difference, I'd like to know whether the version with just the negative invocation is problematic somehow. Is there any constraint in the Democles pattern specification violated or maybe a bug in the Democles execution?

[patrickrobrecht]

I just noticed that this is working:

Note that the node family in the negatively invoked pattern "findSon-CONDITION-member") is local in this setting.

[patrickrobrecht]

Up to now the case above is the only one causing errors. May the mapping of all signature nodes in the negatively invoked pattern cause the issue?

[anthonyanjorin]

Hi - another interesting example that also produces a no search plan (specification and pattern network):

In this case not all nodes in the NAC are mapped and it still doesn't work. I'm guessing it has something to do with an edge in the NAC between two mapped nodes :)

[anthonyanjorin]

Btw: it works if a vorgemerkt edge between u:Umsatz and a:Ausfuehrung is added to the root pattern.

[gervarro]

Hi, do you have an existing example or a test for the above-mentioned erroneous cases? Bests, Greg

[anthonyanjorin]

@patrickrobrecht Could you please establish a JUnit test for Greg that fails? You can @Ignore it and check it in to master so Greg just has to install IBeX, check out the test workspace, and run the test. In fact you could provide a PSF for just the required projects.

[patrickrobrecht]

@gervarro You can find the specification for Tony's example here: https://github.com/mde-lab-sessions/running-example-for-lecture/blob/democles-error/de.upb.mbse.taxcalculationexample.businessrules/src/de/upb/mbse/taxcalculationexample/businessrules/operationalsemantics/Error.gt

Check out the repo at branch democles-error, import the project into an eMoflon::IBeX Eclipse, build the project and run it as JUnit test. You will see some tests failing with error during the Democles initialization which is not present without the rules from Error.gt.

[anthonyanjorin]

Hi Greg,

Not absolutely sure, but I probably have to deploy IBeX first. I’ll do this first thing tomorrow.

Cheers, Tony

[anthonyanjorin]

@gervarro I just deployed IBeX.

[gervarro]

Hi Patrick,

could you please fix the test case in the branch to avoid Java compilation errors? The superclass OperationalsemanticsApp of the test classes might have recently changed.

Many thanks and bests, Greg

[patrickrobrecht]

Hi Greg, the branch is a lot of commits behind master - I need to update that, otherwise the error case is not compatible with the latest IBeX version anymore.

[patrickrobrecht]

Hi Greg, the branch was a lot of commits behind master - I replaced the branch with an updated version. I've also added an output of the transformed Democles patterns to /debug/democles-patterns.xmi, the IBeX pattern structure can be found in src-gen/de.upb.mbse.operationalsemantics.api/ibex-patterns.xmi. The problematic rules are placed in src/de.upb.mbse.operationalsemantics/Error.gt. If you delete this file, all tests will be green. What's the problem that no search plan can is available?.

[anthonyanjorin]

Hi Greg,

any update on the cause of this problem?

Cheers and thanks, Tony

[gervarro]

Hi Tony,

the problem is that the positive patterns (e.g., ausfuehren, findMemberExceptSonWithCondition) are disjoint as invocation of negative patterns does not count when pattern connectivity is checked. NACs can only be checked during the pattern matching process when all of its parameters are bound in the (invoking) positive pattern, which is never fulfilled if these parameters are from disjoint components in the positive pattern.

To be honest, I do not really understand what you would like to express with the ausfuehren, ausfuehrung pattern combination. How should a in the ausfuehren pattern (i.e., the unconnected node) be matched? Or do you want to assign all objects of type Ausfuehrung to a? What does the positive set of matches look like that has to be filtered by using the NAC pattern?

Bests, Greg

[anthonyanjorin]

Hi Greg,

Let's go back to the simplest example:

All I want to do here is find all families and members, such that the member is not a son in the family. Both nodes are signature nodes in findMembersExceptSonInCondition so I don't understand why they are not bound in the NAC.

BTW: This is equivalent to a crossed out link in a simple Fujaba NAC. How else should we express a forbidden link using Democles? Note that the leaf pattern (positively invoked by the NAC) can be removed (integrated into the NAC) and it still won't work.

Cheers, Tony

[gervarro]

Hi Tony,

do I understand correctly that you would really like to find/filter the Cartesian product (cross-join) of all families and members (i.e., all combinations of families and members even unrelated ones)? Note that Rete networks that calculate (and then filter) Cartesian products are the most expensive cases for an incremental pattern matcher. If you can find conditions that already filter the positive parts (e.g., a corresponding edge (e.g., a containment edge, or a daughter edge (i.e., not son)) between family and member, then it helps the pattern matcher.

The connectivity analysis might be buggy (negative pattern invocations should be excluded from the connectivity analysis) if you really want to have the Cartesian product case. I have fixed this case, which will be available together with the other fixes.

Both nodes are signature nodes in findMembersExceptSonInCondition so I don't understand why they are not bound in the NAC.

It is not the NAC that is problematic, but the variables are not bound in the findMembersExceptSonInCondition pattern. This pattern has to explicitly list all pairs of families and members and then filter the match set based on the invoked NAC. Note that the NAC invocation is different from a positive pattern invocation as the former is more like a filter operation (like equals) that can only be checked if all its input parameters (family and member in the findMembersExceptSonInCondition pattern) are bound. Matches (match set deltas) cannot be incrementally propagated from a negatively invoked pattern to the invoking pattern, but the invoking pattern has to produce all combinations (i.e., the Cartesian product) that can be filtered by the negatively invoked pattern (NAC).

Btw. the findMembersExceptSonInCondition pattern could directly (negatively) invoke the edge-Family-sons-FamilyMember pattern without the need to use the findSon pattern. Democles handles NACs on the pattern invocation and not on the pattern level. (There is no negative pattern concept, but a pattern can be invoked either positively or negatively.)

Bests, Greg

[anthonyanjorin]

Hi Greg,

Yes, the Cartesian product is what is wanted here.

Thanks for the fix! I guess what we also need is some report on which patterns were most costly for a transformation. This information can then be used for optimising the specification.

Cheers, Tony

[gervarro]

Hi Tony,

the fix is available on the Democles update sites.

Bests, Greg