I've started using the last release of USE USE 3.0.0RC2 (Release Candidate 2), but there are some questions regarding your support of the constraint redefinition.
I've created the following example:
class C < A
class D < B
association ab between
A role a
B role b
association cd between
C role c redefines a
D role d redefines b
Scenario 1: I created two objects c1 and d1 of the classes C and D respectively, after that I tried to add a link between the two objects via the ab association. After checking the command "check structure now" I found that it yields true. However, I think the redefinition constraint forbids such instances since the name and type has been redefined. Actually I'm not sure if the quarry c1.b is legal since b is not a property of c1 due to the redefinition. I think that the only legal instance is to link c1 and d1 through the cd association.
Scenario 2: If we change the * multiplicities to one, then according to the current implementation we need to add two links of the two associations.
Scenario 3: Furthermore, if we create an object b1, and add a link of ab between c1 and b1, this instance is still considered legal; although it violates the redefinition constraint (c1 can be linked only to objects of D).
The version USE 2.6.0 forbids some of the situations (Sc1). But in the case of Scenario 2, the current implementation will be in some kind of deadlock: it forbids adding links of ab (which means that we can only add one link between c1 and d1) but when we check the instance it returns false.
I think (I'm not sure, the semantics of redefinition is still not entirely clear to me) output should be:
Scenario 1, 3: Return the same message of USE 2.6.0.
Scenario 2: Only one link is allowed - a link of cd association.
Thanks for your detailed post. The redfinition part in USE is not completed, yet. But we hope to finish it to the final 3.0.0 release.
I think the current problem is that USE does not forbid the creation of a links between objects of class C via the association CD and does not consider the redefiniton correctly while calculating the result of navigation expressions. I try to fix this as soon as possible.
I think for the query c1.b there are two possible implementations:
c1.b is not allowed (your suggestion)
c1.b results in a Set(D) instead of Set(B) (current implementation)
I prefer the second option, because it is more natural to me. When using a Set of A's (which may contain B's) you can navigate to b. This should still be possible when using a Set of C's because C's are A's.