Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » UML-OCL ; specifying constraints in the context of an association / association class
UML-OCL ; specifying constraints in the context of an association / association class [message #1729223] Tue, 12 April 2016 09:32 Go to next message
German Vega is currently offline German VegaFriend
Messages: 44
Registered: December 2015
Member
Hello

I am not sure if this is a bug, a Request For Enhancement or a misinterpretation of the UML/OCL specifications, so please bear with me.

I am trying to specify an invariant in the context of an UML association (this seems to be allowed by both the UML and OCL specification 2.4, as they refer to invariants associated to a Classifier, and an Association is a Classifier).

I have managed to create a valid UML model with the associated OCL constraints (using Papyrus) as shown at the top in the figure below :

index.php/fa/25641/0/

However, There is an error telling me that there is no associated pivot element. To discard any Papyrus bug, I have written a standalone program to load the model, and get the parsed OCLExpressions. And I get the same error as Papyrus.

As a workaround, I tried to define the constraint in the context of an AssociationClass, as shown at the bottom of the figure. This time, I do get a pivot element created, but there is another problem as the pivot.Class created is not added to the corresponding package.

Then I told myself, maybe Associations/AssociationClasses are not supported in Essential OCl, so I defined all my constraints in a Complete OCL document (attached). But the xtext editor doesn't seem to be able to correctly parse the model. I have modified my standalone program to directly parse the complete OCL file and I get the same errors as the xtext editor.

I know I can rephrase my constraints in the context of one of the association ends, as shown in the left of the figure. But sometimes is far more intuitive to write the invariant in the context of the association.

By the way, I think there is another, unrelated, bug concerning association classes. If I try to navigate the member ends defined in the association class (as shown in the constraint at the bottom left of the figure) I get an "unresolved property" error both in essential and complete OCL.

The question is whether defining invariants in the context of association /association classes is something that is, or will be, supported by eclipse OCL. Or should I simply not keep trying to make this work.

My current need is only to be able to parse the OCL constraints. I can easily imagine that evaluation is a far more complex matter, specially because associations do not exists at the ecore level, even less association classes.

I attach my UML model and my program, so you can try to reproduce the problem.

Thanks.

German Vega

[Updated on: Wed, 13 April 2016 15:23]

Report message to a moderator

Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729253 is a reply to message #1729223] Tue, 12 April 2016 12:11 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

Thanks for the nice simple repro - UML examples are hard to come by and
artidficial ones never go far enough.

I presume you meant [0..1] rather than [0..*] on your association ends,
otherwise e.g.

self.b_ac.value < self.a_ac.value

is really

self.b_ac->collect(value) < self.a_ac->collect(value)

giving an unknown operator Bag::<

---

The easiest way to test in isolation of Papyrus is to load the UML model
in the UML model editor.

Then use Validate - tends to reproduce UML2 problems.

Then use OCL->Validate - tends to reproduce OCL problems.

For your example just loading test.ocl in the Complete OCL editor shows
many problems.

---

Association invariants are not supported by Complete OCL. OMG mention
only Class/Operation/Property. Other useful contexts such as State,
Activity fall into the chasm between UML and OCL specifications. Now
Association too can be found there.

(Using Association and AssociationClass as user-defined names for
instances of the same-named concepts risks causing many debugging
confusions.)

Arguably you should use a proper AssociationClass for a class-like
behavior, but the UML2AS conversion eliminates Associations unless they
are actually needed in which case they are concerted to
AssociationClass, so your invariant could be just another trigger to
create an AssociationClass. (just fixed it on branch ewillink/432905).

---

You are falling foul of limited Pivot OCL support for Association

- https://bugs.eclipse.org/bugs/show_bug.cgi?id=423905

but AssociationClassConstraintComplete, AssociationConstraintComplete
only need navigation from AssociationClass so that ought to work. (just
fixed it on branch ewillink/432905).

ClassConstraintComplete2 is more troublesome. Needs navigation to an
AssociationClass; that will have to wait.

Regards

Ed Willink


On 12/04/2016 10:32, German Vega wrote:
> Hello
>
> I am not sure if this is a bug, a Request For Enhancement or a misinterpretation of the UML/OCL specifications, so please bear with me.
>
> I am trying to specify an invariant in the context of an UML association (this seems to be allowed by both the UML and OCL specification 2.4, as they refer to invariants associated to a Classifier, and an Association is a Classifier).
>
> I have managed to create a valid UML model with the associated OCL constraints (using Papyrus) as shown at the top in the figure below :
>
>
>
> However, There is an error telling me that there is no associated pivot element. To discard any Papyrus bug, I have written a standalone program to load the model, and get the parsed OCLExpressions. And I get the same error as Papyrus.
>
> As a workaround, I tried to define the constraint in the context of an AssociationClass, as shown at the bottom of the figure. This time, I do get a pivot element created, but there is another problem as the pivot.Class created is not added to the corresponding package.
>
> Then I told myself, maybe Associations/AssociationClasses are not supported in Essential OCl, so I defined all my constraints in a Complete OCL document (attached). But the xtext editor doesn't seem to be able to correctly parse the model. I have modified my standalone program to directly parse the complete OCL file and I get the same errors as the xtext editor.
>
> I know I can rephrase my constraints in the context of one of the association ends, as shown in the left of the figure. But sometimes is far more intuitive to write the invariant in the context of the association.
>
> By the way, I think there is another, unrelated, bug concerning association classes. If I try to navigate the member ends defined in the association class (as shown in the constraint at the bottom left of the figure) I get an "unresolved property" error both in essential and complete OCL.
>
> The question is whether defining invariants in the context of association /association classes is something that is, or will be, supported by eclipse OCL. Or should I simply not keep trying to make this work.
>
> My current need is only to be able to parse the OCL constraints. I can easily imagine that evaluation is a far more complex matter, specially because associations do not exists at the ecore level, even less association classes.
>
> I attach my UML model and my program, so you can try to reproduce the problem.
>
> Thanks.
>
> German Vega
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729280 is a reply to message #1729253] Tue, 12 April 2016 14:17 Go to previous messageGo to next message
German Vega is currently offline German VegaFriend
Messages: 44
Registered: December 2015
Member
Hi

Thanks for the prompt answer.

Let me just dissect your answer point by point to be sure that I understand.

Point I)

Quote:
I presume you meant [0..1] rather than [0..*] on your association ends,
otherwise e.g.

self.b_ac.value < self.a_ac.value

is really

self.b_ac->collect(value) < self.a_ac->collect(value)


Well, I really meant [0..*] . Precisely, navigating from an association class using the association ends always deliver a single object. Quoting from OCL specification 2.4 :

Quote:
7.5.5 Navigation from Association Classes

We can navigate from the association class itself to the objects that participate in the association. This is done using the dot-notation and the role-names at the association-ends.

context Job
inv: self.employer.numberOfEmployees >= 1
inv: self.employee.age > 21

Navigation from an association class to one of the objects on the association will always deliver exactly one object. This is a result of the definition of AssociationClass. Therefore, the result of this navigation is exactly one object, although it can be used as a Set using oclAsSet() or its "->" shorthand.


So I supposed it will be similar for navigating from an Association. As a matter of fact, I (mis)interpret navigating from an Association as equivalent to navigating from an AssociationClass that happen to have no declared properties (other than the association ends).

Point II)

Quote:
Arguably you should use a proper AssociationClass for a class-like
behavior, but the UML2AS conversion eliminates Associations unless they
are actually needed in which case they are concerted to AssociationClass, so your invariant could be just another trigger to create an AssociationClass. (just fixed it on branch ewillink/432905).


Yes, I agree. Where can I find branch ewillink/432905? do I need to checkout sources, or is it built somewhere ?

Point III)

Quote:
AssociationConstraintComplete only need navigation from AssociationClass so that ought to work. (just fixed it on branch ewillink/432905).


If this works, that will take care of many of my needs.

Just a question, in the bug report you write :

Quote:
Supporting Association constraints just needs an Association with a Constraint to be converted to a Pivot AssociationClass. Done.


Does this mean that my use case will work even if I do not explicitly define an UML AssociationClass but only an Association. It will implicitly create a pivot AssociationClass?

Point IV)

Quote:
ClassConstraintComplete2 is more troublesome. Needs navigation to an AssociationClass; that will have to wait.


No, ClassConstraintComplete2 is a normal association end navigation from class B to class A (same intent as ClassConstraintComplete). The only difference is that the association ends are owned by an AssociationClass and not by an Association. This is where I think there is another lurking bug.

Lastly,

I modified the attached model/ocl files in the original post, to rename the associations and avoid confusion during debugging Smile

thanks again

German
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729292 is a reply to message #1729280] Tue, 12 April 2016 15:28 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

I omit duplication of my comments on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=423905

On 12/04/2016 15:17, German Vega wrote:
> Hi
>
> Point I)
>
> Quote:
>> I presume you meant [0..1] rather than [0..*] on your association ends,
>> otherwise e.g.
>>
> Well, I really meant [0..*] .
>
> Quote:
>> 7.5.5 Navigation from Association Classes
>>
>> Navigation from an association class to one of the objects on the
>> association will always deliver exactly one object.
Well spotted.
> So I supposed it will be similar for navigating from an Association.
> As a matter of fact, I (mis)interpret navigating from an Association
> as equivalent to navigating from an AssociationClass that happen to
> have no declared properties (other than the association ends).
This is what I'm trying to achieve in the Pivot model. A Pivot
AssociationClass is just a Class that happens to acquire some
algorithmically derived properties from its UML AssociationClas
memberEnds. It may have ordinary properties too, although WFRs might
prohibit them. (Similarly Stereotypes induce algorithmically derved
'regular' properties.)

A UML Association is eliminated wherever possible by ensuring that all
Properties are Class-owned, albeit in a merged Class to avoid corrupting
the original. Only if the Association is actually needed is a Pivot
Association created. All Pivot navigation therefore uses 'regular'
properties.
> Point II)
>
> Yes, I agree. Where can I find branch ewillink/432905? do I need to
> checkout sources, or is it built somewhere ?

In GIT. https://git.eclipse.org/r/ocl/org.eclipse.ocl

I could do a branch build if you're going to use it, but you've just
given me some more work to do.

Are you using a milestone release at present?
> Point III)
>
> Does this mean that my use case will work even if I do not explicitly
> define an UML AssociationClass but only an Association. It will
> implicitly create a pivot AssociationClass?
Yes
>
> Point IV)
>
> Quote:
>> ClassConstraintComplete2 is more troublesome. Needs navigation to an
>> AssociationClass; that will have to wait.
>
> No, ClassConstraintComplete2 is a normal association end navigation
> from class B to class A (same intent as ClassConstraintComplete). The
> only difference is that the association ends are owned by an
> AssociationClass and not by an Association. This is where I think
> there is another lurking bug.
This should fix at the same time as the end multiplicity.

Regards

Ed
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729302 is a reply to message #1729292] Tue, 12 April 2016 17:46 Go to previous messageGo to next message
German Vega is currently offline German VegaFriend
Messages: 44
Registered: December 2015
Member
HI Ed,

I think I understand what you want to achieve, and it fits well my needs.

My own version of the pivot translation including multiplicities is

So an A::b[mult1] : B to B::a[mult2] : A mediated by AC is converted to:

A::b -> B[mult1] opposite B::a -> A[mult2]
A::AC -> AC[mult1] opposite AC::a -> A[1]
B::AC -> AC[mult2] opposite AC::b -> B[1]

with the additional constraints

Context A
inv : self.AC.b = self.b

Context B
inv : self.AC.a = self.a

But these constraints cannot be enforced by the OCL runtime, maybe it is more a problem for the UML to ecore translation.

No need to do a branch build, I can wait for an integration build.

The most important thing for me is to be sure that this will be eventually supported, and that I can count on it to be available for use in my future work.

Regards

German


Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729312 is a reply to message #1729302] Tue, 12 April 2016 19:09 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

I agree with your refined multiplicities.

I have the following working in my workspace:

context B
inv ClassConstraintComplete2:
self.AssociationClass->forAll(a | self.value < a.a_ac.value)

rather than your:

inv ClassConstraintComplete2:
self.a_c->forAll(a | self.value < a.value)

Overloading "a" as an AssociationClass is also confusing. Simpler to do
just:

inv ClassConstraintComplete2:
AssociationClass->forAll(self.value < a_ac.value)

------

The UML2Ecore translation is lossy. Some of the loss is mitigated by
EAnnotations. You won't get very far trying to make the UML2Ecore
translation better. It is not intended to be full UML in Ecore.

The UML2 stereotype support unhelpfully uses an embedded Ecore
representation of its profiles. The Pivot OCL does its best to ignore
the Ecore using only what is needed to re-locate the original UML and
OCL. This approach could be extended to load a richer OCL for your Ecore
model instances. This richer OCL could validate Association constraints
even if there are no Ecore Associations.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=491537 raised.

Regards

Ed Willink

On 12/04/2016 18:46, German Vega wrote:
> HI Ed,
>
> I think I understand what you want to achieve, and it fits well my needs.
>
> My own version of the pivot translation including multiplicities is
> So an A::b[mult1] : B to B::a[mult2] : A mediated by AC is converted to:
>
> A::b -> B[mult1] opposite B::a -> A[mult2]
> A::AC -> AC[mult1] opposite AC::a -> A[1]
> B::AC -> AC[mult2] opposite AC::b -> B[1]
>
> with the additional constraints
>
> Context A
> inv : self.AC.b = self.b
>
> Context B
> inv : self.AC.a = self.a
>
> But these constraints cannot be enforced by the OCL runtime, maybe it
> is more a problem for the UML to ecore translation.
>
> No need to do a branch build, I can wait for an integration build.
> The most important thing for me is to be sure that this will be
> eventually supported, and that I can count on it to be available for
> use in my future work.
> Regards
> German
>
>
>
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729333 is a reply to message #1729312] Wed, 13 April 2016 07:44 Go to previous messageGo to next message
German Vega is currently offline German VegaFriend
Messages: 44
Registered: December 2015
Member
Hi Ed

Concerning my example, there was an error in ClassConstraintComplete2 in my original post, so I think that get you confused. My intent was not to navigate to the association class, but to the other end of the association. The correct invariants (updated in the attached files of the original post), with the iteration variables and types expanded, are:

context B

inv ClassConstraintComplete:
self.a->forAll(a: A | self.value < a.value)

inv ClassConstraintComplete2:
self.a_ac->forAll(a : A | self.value < a.value)


The first invariant, ClassConstraintComplete, navigates from B to A using B::a that is a property owned by the Association. It works as expected and I have no errors in the complete OCL editor.

The second invariant, ClassConstraintComplete2, also navigates from B to A but using B::a_ac that is a property owned by the AssociationClass, and in this case I do have an error in the complete OCL editor : "Unresolved property B::a_ac".

Probably this error is already corrected in your branch, as the modifications that you have made ensure that all properties are Class-owned in the pivot. But better to check up.

Your version of ClassConstraintComplete2, on the other hand, is a good test case for navigation from B to the association class and then to A.

Concerning UML2Ecore, I am very aware that this is a lossy translation, my comment was just a small wandering Wink. Actually, the tool I am working on is an semi-automatic transformation from UML to a formal language (Z notation or B-method) and my current objective is to translate the OLC constraints (invariants, pre/post conditions), so I have very similar "lost in translation" problems.

Anyway, my present need is just to be able to parse the OCL constraints and get an easily manipulable abstract syntax representation. So I much appreciate the time you spend correcting and implementing the missing features.

Any idea when your modifications will make it to a nightly build, so I can test it?

Regards

G. Vega
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729350 is a reply to message #1729333] Wed, 13 April 2016 09:51 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

A branch build is available now at

https://hudson.eclipse.org/ocl/job/buckminster-ocl-branch-tests/1006/artifact/MDT-OCL.downloads/mdt-ocl-Update-201604121617.zip

It should support the (binary) Association/AssociationClass navigation.

----

Your observation:

/with the additional constraints //
////
//Context A //
//inv : self.AC.b = self.b //
////
//Context B //
//inv : self.AC.a = self.a /

can be extended mindlessly to N-ary associations and also ordered/unique
leaving relatively few options for the UML
(Class+Property+Association+AssociationClass) to Pivot (Class+Property)
normalization so I'm inclined to do the mindless extension.

----

This has demonstrated that the unimplemented AssociationClassCallExp is
redundant in the Pivot model where the source syntax complexities are
normalized away. Qualified navigation (7.5.4) is suddenly easy too. In
self.EmployeeRanking[bosses], self.EmployeeRanking is an ambiguous
lookup for which [bosses] indexes/selects to eliminate the ambiguity and
enable a 'regular' OppositePropertyCallExp to be created.

Similarly qualified associations are much easier. The unused
NavigationCallExp.qualifiers just needs populating with the arguments of
self.customer[8764423].

Might as well do these too so that Pivot OCL parsing is complete
Association-wise, for users such as you who want the AS for other
purposes. Evaluation of qualified associations is a different matter
perhaps requiring a new instance representation.

Regards

Ed Willink


On 13/04/2016 08:44, German Vega wrote:
> Hi Ed
>
> Concerning my example, there was an error in ClassConstraintComplete2
> in my original post, so I think that get you confused. My intent was
> not to navigate to the association class, but to the other end of the
> association. The correct invariants (updated in the attached files of
> the original post), with the iteration variables and types expanded, are:
>
> context B
>
> inv ClassConstraintComplete:
> self.a->forAll(a: A | self.value < a.value)
> inv ClassConstraintComplete2:
> self.a_ac->forAll(a : A | self.value < a.value)
>
>
> The first invariant, ClassConstraintComplete, navigates from B to A
> using B::a that is a property owned by the Association. It works as
> expected and I have no errors in the complete OCL editor.
>
> The second invariant, ClassConstraintComplete2, also navigates from B
> to A but using B::a_ac that is a property owned by the
> AssociationClass, and in this case I do have an error in the complete
> OCL editor : "Unresolved property B::a_ac".
>
> Probably this error is already corrected in your branch, as the
> modifications that you have made ensure that all properties are
> Class-owned in the pivot. But better to check up.
>
> Your version of ClassConstraintComplete2, on the other hand, is a good
> test case for navigation from B to the association class and then to A.
>
> Concerning UML2Ecore, I am very aware that this is a lossy
> translation, my comment was just a small wandering ;). Actually, the
> tool I am working on is an semi-automatic transformation from UML to a
> formal language (Z notation or B-method) and my current objective is
> to translate the OLC constraints (invariants, pre/post conditions), so
> I have very similar "lost in translation" problems.
> Anyway, my present need is just to be able to parse the OCL
> constraints and get an easily manipulable abstract syntax
> representation. So I much appreciate the time you spend correcting and
> implementing the missing features.
>
> Any idea when your modifications will make it to a nightly build, so I
> can test it?
>
> Regards
>
> G. Vega
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729392 is a reply to message #1729350] Wed, 13 April 2016 16:26 Go to previous messageGo to next message
German Vega is currently offline German VegaFriend
Messages: 44
Registered: December 2015
Member
Hi Ed,

I have just downloaded the branch build and made some tests.

For Complete OCL, every thing is working perfectly. I have no errors in the xtext editor, the outiline shows the AS, and I get the parsed expression in my standalone program.

For Essential OCL, there is still a little bug. The constraints owned by the Association do not have a corresponding pivot element associated, so I have errors both in Papyrus and in my standalone program. In my test program I do the following to get the pivot corresponding to a given UML constraint :

org.eclipse.ocl.pivot.Constraint oclConstraint = 
ocl.getMetamodelManager().getASOf(org.eclipse.ocl.pivot.Constraint.class, constraint);


For constraints owned by Classes and Association Classes it works ok, but for constraint owned by by an Association I get null.

I have spent some time debugging and, although I am not familiar with your code, I have noticed the following trace leading to the problem:

1) In the first pass, UML2ASDeclarationSwitch.caseAssociation notice that there are owned rules declared and creates the association class and copy the association ends. But it never invokes copyNamedElement, so converter.copyNamedElement is not invoked, and so converter.setOriginalMapping is never invoked.

2) In the second pass, UML2ASUseSwitch.caseAssociation

	@Override
	public Object caseAssociation(org.eclipse.uml2.uml.Association umlAssociation) {
		assert umlAssociation != null;
		AssociationClass asAssociationClass = converter.getCreated(AssociationClass.class, umlAssociation);
		if (asAssociationClass == null) {
			org.eclipse.uml2.uml.Element owner = umlAssociation.getOwner();
			if (owner != null) {
				org.eclipse.ocl.pivot.Package asPackage = converter.getCreated(org.eclipse.ocl.pivot.Package.class, owner);
				if (asPackage != null) {
					asAssociationClass = PivotFactory.eINSTANCE.createAssociationClass();
					asAssociationClass.setName(umlAssociation.getName());
					org.eclipse.ocl.pivot.Class oclElementType = standardLibrary.getOclElementType();
					asAssociationClass.getSuperClasses().add(oclElementType);
					asPackage.getOwnedClasses().add(asAssociationClass);
				}
			}
		}
		else {
			List<org.eclipse.uml2.uml.Constraint> invariants = umlAssociation.getOwnedRules();
			doSwitchAll(Constraint.class, ClassUtil.nullFree(asAssociationClass.getOwnedInvariants()), invariants);
			copyConstraints(asAssociationClass, umlAssociation, invariants);
		}
		if (asAssociationClass != null) {
			createAssociationClassProperties(asAssociationClass, umlAssociation);
		}
		return asAssociationClass;
	}


the call to converter.getCreated returns null (which is normal because converter.setOriginalMapping was not called). It enters the "then" part of the if and creates the association class in the owner pivot package. Then it creates the association class properties.

Notice that copyConstraints is never invoked, it is only invoked in the "else" part of the if, that is not executed in this scenario.

I don't fully understand the subtleties of the code to propose a realiable fix, but I hope my debugging session helps you track the problem

Regards

G. Vega
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729393 is a reply to message #1729350] Wed, 13 April 2016 17:07 Go to previous messageGo to next message
German Vega is currently offline German VegaFriend
Messages: 44
Registered: December 2015
Member
Hi Ed

Concerning your other remarks:

Quote:
This has demonstrated that the unimplemented AssociationClassCallExp is
redundant in the Pivot model where the source syntax complexities are
normalized away. Qualified navigation (7.5.4) is suddenly easy too. In
self.EmployeeRanking[bosses], self.EmployeeRanking is an ambiguous
lookup for which [bosses] indexes/selects to eliminate the ambiguity and
enable a 'regular' OppositePropertyCallExp to be created.

Similarly qualified associations are much easier. The unused
NavigationCallExp.qualifiers just needs populating with the arguments of
self.customer[8764423].


I do not know how you perform disambiguation of the concrete syntax, but I agree that at the AS level something like self.EmployeeRanking[bosses] can be represented as an OppositePropertyCallExp using the properties created in the pivot model to enable navigation to/from the Association Class; and on the other hand, something like self.customer[8764423] can be simply represented by a NavigationCallExp with the corresponding qualifiers.

And you are right, I think this seems to cover all the parsing for association navigation.

Reagrding your other comment :

Quote:
Your observation:

/with the additional constraints //
////
//Context A //
//inv : self.AC.b = self.b //
////
//Context B //
//inv : self.AC.a = self.a /

can be extended mindlessly to N-ary associations and also ordered/unique
leaving relatively few options for the UML
(Class+Property+Association+AssociationClass) to Pivot (Class+Property)
normalization so I'm inclined to do the mindless extension.


I am not sure to understand this. In principle, navigating from an Association Class (binary or n-ary) is always possible, without ambiguity.

On the other hand, I don't know what it means navigating from a class end to an n-ary association class. In principle, you need a (n-1)-tuple to start navigating an n-ary association. I do not even know what is the concrete OCL syntax to do this. So, I do not know what it means something like self.AC for an n-ary association.

Regards

G. vega
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729450 is a reply to message #1729350] Thu, 14 April 2016 09:17 Go to previous messageGo to next message
German Vega is currently offline German VegaFriend
Messages: 44
Registered: December 2015
Member
Hi Ed,

I have been thinking overnight about n-ary associations, and I think now I can follow your reasoning.

Suppose we have three UML classes A,B,C joined by an ternary association class AC with owned ends a : A[mul1], b:B[mul2],c;C[mul3]

This can be represented at pivot level by 4 classes with the following properties :

1) AC::a:A[1], AC::b:B[1], AC::c:C[1] This allows navigating from the association class to the ends. This is ok for me. If we consider a link (instance of the association class) as a tuple of references, evaluation simply return the value of the property.

2) A::AC:AC[*], A::AC:AC[*], A::AC:AC[*] This allows navigating from an end to the Association Class. This is ok for me. Additionally we have A::AC opposite AC::a , B::AC opposite AC::b, C::AC opposite AC::c. For evaluation, at the instance level, creating a link (initializing AC::a, AC::b, CA::c) will automatically value the opposite reference, and self.AC can be evaluated as a normal property access.

3) A::b:B[*], A::c:C[*], B::a:A[*], B::c:C[*], C::b:B[*], C::a:A[*] This allows navigation from one end to another end of the association. This is where my observation can be "mindlessly" extended if we consider

Context A inv: self.b = self.AC.b and self.c = self.AC.c
Context B inv: self.a = self.AC.a and self.c = self.AC.c
Context C inv: self.b = self.AC.b and self.a = self.AC.a

This is the point that troubles me. I agree that the invariant gives meaning to these properties, but I think these do not faithfully represent an UML association end.

In particular, notice that we lost the UML association end multiplicities in the translation. This is because the UML semantics of the multiplicities for a n-ary association is specified by fixing (n-1) source objects. Quoting from UML 2.4 infrastructure:

Quote:
11.3.1 Association, section Semantics
For an association with N ends, choose any N-1 ends and associate specific instances with those ends. Then the collection of links of the association that refer to these specific instances will identify a collection of instances at the other end. The
multiplicity of the association end constrains the size of this collection.


And this is without considering complex concepts like subsetting, specialization, redefinition.

I do agree that this may suffice for parsing purposes, and will extend all association navigation expressions to n-ary associations. But I fear this will give the impression that we can deal with n-ary associations while in reality there is a gigantic void in the UML-OCL integration specification.

Voila my thoughts

Regards

G. Vega
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729463 is a reply to message #1729450] Thu, 14 April 2016 10:18 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

It's your turn to neglect the original multiplicities...

On 14/04/2016 10:17, German Vega wrote:
> 1) AC::a:A[1], AC::b:B[1], AC::c:C[1]
Yes
> 2) A::AC:AC[*], A::AC:AC[*], A::AC:AC[*]
No. It's not necessarily *, it is the original multiplicity+ordered+unique.
> 3) A::b:B[*], A::c:C[*], B::a:A[*], B::c:C[*], C::b:B[*], C::a:A[*]
No, again. It's not necessarily *, it is the original
multiplicity+ordered+unique.
> This is the point that troubles me. I agree that the invariant gives
> meaning to these properties, but I think these do not faithfully
> represent an UML association end.
Indeed, which is why the original multiplicities must be kept.
> In particular, notice that we lost the UML association end
> multiplicities in the translation. This is because the UML semantics
> of the multiplicities for a n-ary association is specified by fixing
> (n-1) source objects. Quoting from UML 2.4 infrastructure:
>
> Quote:
>> 11.3.1 Association, section Semantics
>> For an association with N ends, choose any N-1 ends and associate
>> specific instances with those ends. Then the collection of links of
>> the association that refer to these specific instances will identify
>> a collection of instances at the other end. The
>> multiplicity of the association end constrains the size of this
>> collection.
So long as we only use the multiplicities 0, 1, ?, +, *, I think it's
ok. As soon as we start to use the OCL support for bounded collections
we have to work harder

UML: AC::a:A[1], AC::b:B[2], AC::c:C[4]

Pivot:

A::AC:AC[1], B::AC:AC[2], C::AC:AC[4]
A::b:B[8], A::c:C[2], B::a:A[4], B::c:C[2], C::b:B[8], C::a:A[4]

"ordered" must be anded too, since while A.c can only be ordered if both
AC.b and AC.c are ordered. Presumably ordered multi-dimensionally
first-memberEnd-first ...

Of course fuller OCL support for a ternary navigation would treat the
memberEnds as association qualifiers allowing

anA.AC[anA,aB,aC]

as a shorthand for

anA.AC->select(a=anA and b=aB and c=aC)
> And this is without considering complex concepts like subsetting,
> specialization, redefinition.
Redefinition got lost in my initial re-implementation. I'm fixing it now.

The Pivot OCL policy is that ALL declarations exist in the metamodel.
(Attempting to prune ambiguities leads to loss of diagnosis and
inconsistency in derivations of the pruning.) With all declarations
available, a lookup returns the ambiguities at which point an extensible
bank of disambiguators prunes the lookup wrt to the lookup requirement,
rather than using globally pruned declarations.
> I do agree that this may suffice for parsing purposes, and will extend
> all association navigation expressions to n-ary associations. But I
> fear this will give the impression that we can deal with n-ary
> associations while in reality there is a gigantic void in the UML-OCL
> integration specification.
It's certainly a risk, but the 'mindless' equivalences seem to support
parsing. I'm hoping that practical limitations are therefore just WFRs
diagnosing stupid combinations of multiplicity. Today there is zero
AssociationClass support - useless. The 'mindless' equivalent is at
least a potentially useful candidate that can be analyzed for flaws.

Implementation representations and evaluation over them is a different
issue.

Regards

Ed Willink
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729474 is a reply to message #1729463] Thu, 14 April 2016 12:42 Go to previous messageGo to next message
German Vega is currently offline German VegaFriend
Messages: 44
Registered: December 2015
Member
Hi Ed,

Regarding the n-ary associations. I purposely neglected the original multiplicities because I thing they do not have the same meaning in UML as in the pivot model.

Consider the ternary example with some concrete UML multiplicities:
AC with owned ends a:A[0..1], b:B[0..1], c:C[0..1]

What should be the multiplicity of C::AC, A::c, B::c ?

Imagine I have the following links (instances of) AC :

AC1 = {a1,b1,c1}
AC2 = {a1,b2,c2}
AC3 = {a2,b1,c3}
AC4 = {a3,b3,c1}

From an UML point of view, this satisfies all the constrains of the multiplicities. As a UML user, I expect the following evaluations in the example

c1.AC = {AC1,AC4}
a1.c = {c1,c2}
b1.c = {c1,c3}

so the multiplicities should be C::AC[*], A::c[*], B::c[*], How can I infer this from the original multiplicities?

UML multiplicities for n-ary associations are at best unintuitive , and at worst flawed (see for example paper [1] for an interesting discussion). So I am afraid there is no easy translation to pivot, other that not constraining anything (that's why I set the multiplicities to *), and losing the original information. Similar concerns apply to ordered or unique.

Anyway, I agree with you, better to have something working, that allows parsing, than no support at all.

Did you see my other message 1729392 concerning the bug for essential OCL ?

Regards

G. Vega


[1] The meaning of multiplicity of n-ary associations in UML
Gonzalo Genova, Juan Llorens, Paloma Martınez
Software and Systems Modeling
December 2002, Volume 1, Issue 2, pp 86-97
http://dx.doi.org/10.1007/s10270-002-0009-3
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729485 is a reply to message #1729474] Thu, 14 April 2016 14:45 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

I only partially recall a conversation with Martin Gogolla last year.
The USE tool developed by his team is probably the only OCL tool that
supports N-ary associations. I think we agreed that N-ary associations
are asymmetric, requiring you to focus on the "1" multiplicity, but I
think I was getting confused about the opposites.

However for your example rephrasing to avoid typos and other confusion:

The UML ternary AorB::c:C[0..1], BorC::a:[0..1], CorA::b:B[0..1] may
be mediated by explicit/implicit AC::a:A[0..1], AC::b:B[0..1], AC::c:C[0..1]

I could interpret this pair-wise as meaning that for a given A,
AorB::c:C[0..1] => there are 0/1 Cs
CorA::b:B[0..1] => there are 0/1 Bs
so 0/1 ACs with optional B and C. However an AC with only one end is not
well-formed so wrt to a given non-null a1 the possibilities are

{a1,null,c1} or {a1,b1,c1} or {a1,b1,null}

This is easily 'parsed' but no doubt more troubling to implement accurately.

{{a1,b1,c1} , {a1,b2,c2}}

is not well-formed since for a given A there are multiple Bs and Cs.

For

The UML ternary AorB::c:C[0..4], BorC::a:[0..1], CorA::b:B[0..2]
mediated by AC::a:A[0..1], AC::b:B[0..1], AC::c:C[0..1]

for a given A , there are 0/1/2 Bs and 0/1/2/3/4 Cs giving more than the
eight (2*4) that I suggested earlier.

The opposites are therefore: A::AC:AC[0..X], B::AC:AC[0..Y],
C::AC:AC[0..Z] where X,Y,Z involve some non-trivial combinatoral
calculations that I would need to refresh my math on before giving the
equations. * will do for many purposes, but practical applications may
benefit from being able to allocate a fixed size buffer.

My interpretation works for 2-ary, yours fails.

For the UML binary A::b:B[0..1] <=> B::a:A[0..1] mediated by the AC with
owned ends AC::a:A[0..1], AC::b:B[0..1]B::a:A[0..1]
you consider that the AC Tuple set

{{a1,b1} , {a1,b2}}

is well-formed, I consider it ill-formed since when we look in the a1.b
EList, we find two entries violating the multiplicity.

Regards

Ed Willink

On 14/04/2016 13:42, German Vega wrote:
> Hi Ed,
>
> Regarding the n-ary associations. I purposely neglected the original
> multiplicities because I thing they do not have the same meaning in
> UML as in the pivot model.
>
> Consider the ternary example with some concrete UML multiplicities:
> AC with owned ends a:A[0..1], b:B[0..1], c:C[0..1]
>
> What should be the multiplicity of C::AC, A::c, B::c ?
> Imagine I have the following links (instances of) AC :
>
> AC1 = {a1,b1,c1}
> AC2 = {a1,b2,c2}
> AC3 = {a2,b1,c3}
> AC4 = {a3,b3,c1}
>
> From an UML point of view, this satisfies all the constrains of the
> multiplicities. As a UML user, I expect the following evaluations in
> the example
>
> c1.AC = {AC1,AC4}
> a1.c = {c1,c2}
> b1.c = {c1,c3}
>
> so the multiplicities should be C::AC[*], A::c[*], B::c[*], How can I
> infer this from the original multiplicities?
>
> UML multiplicities for n-ary associations are at best unintuitive ,
> and at worst flawed (see for example paper [1] for an interesting
> discussion). So I am afraid there is no easy translation to pivot,
> other that not constraining anything (that's why I set the
> multiplicities to *), and losing the original information. Similar
> concerns apply to ordered or unique.
>
> Anyway, I agree with you, better to have something working, that
> allows parsing, than no support at all.
>
> Did you see
> https://www.eclipse.org/forums/index.php?t=msg&th=1076487&goto=1729392&#msg_1729392
> concerning the bug for essential OCL ?
>
> Regards
>
> G. Vega
>
>
> [1] The meaning of multiplicity of n-ary associations in UML
> Gonzalo Genova, Juan Llorens, Paloma Martınez
> Software and Systems Modeling
> December 2002, Volume 1, Issue 2, pp 86-97
> http://dx.doi.org/10.1007/s10270-002-0009-3
>
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729505 is a reply to message #1729474] Thu, 14 April 2016 19:59 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

On 14/04/2016 13:42, German Vega wrote:
> Did you see
> https://www.eclipse.org/forums/index.php?t=msg&th=1076487&goto=1729392&#msg_1729392
> concerning the bug for essential OCL ?
This and other fixes regarding Accociation(Class) parsing should be
available now in:

http://www.eclipse.org/modeling/download.php?file=/modeling/mdt/ocl/downloads/drops/6.1.0/N201604141527/mdt-ocl-Update-N201604141527.zip

Regards

Ed Willink
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729586 is a reply to message #1729505] Fri, 15 April 2016 16:27 Go to previous messageGo to next message
German Vega is currently offline German VegaFriend
Messages: 44
Registered: December 2015
Member
Hi Ed,

I just downloaded the nightly build, and everything is working perfectly. Both for essential and complete OCL. Both with Papyrus and my standalone program.

I have just one last question. In my tool, I have some constraints defined in the UML model, and other constraints in several different complete OCL documents (to allow handling different concerns independently) that I load in the resource set. I would like to have access to the merged complete class with all its constraints, irrespective of the source. I have tried the following in my program :

		/*
		 * Traverse complete model (not sure how this API works, just trying it out !)
		 */
		CompleteModel completeModel = ocl.getCompleteEnvironment().getOwnedCompleteModel();
		for (org.eclipse.ocl.pivot.Element element : completeModel.allOwnedElements()) {
			if (element instanceof org.eclipse.ocl.pivot.CompleteClass) {
				org.eclipse.ocl.pivot.CompleteClass completeClass = (org.eclipse.ocl.pivot.CompleteClass) element;
				System.out.println("iterating complete class "+completeClass.getName()+" in package "+completeClass.getOwningCompletePackage().getName());
				for (org.eclipse.ocl.pivot.Class partialClass : completeClass.getPartialClasses()) {
					for (org.eclipse.ocl.pivot.Constraint oclConstraint : partialClass.getOwnedConstraints()) {
						System.out.println(" constraint "+oclConstraint.getName());
						show(ocl,oclConstraint);
					}
				}
			}
		}


But it doesn't seems to work. Is this the correct way? is there another API? I didn't find a tutorial or example showing this. Besides, the iteration returns me all the classes, including the UML metamodel and standard profiles, is there any API to only get the pivot classes for my UML model?

Concerning our discussion about n-ary associations. I have to admit that I got completely lost in the last messages. I Think we were not talking about the same thing.

To clarify my mind I wrote a small document with my understanding of UML n-ary associations. I attached it, in case you have some time to take a look. But it is not urgent. As I told you before, the tool I work in transforms from UML to a formal language. It currently doesn't support n-ary associations. So our discussion has been very enlightening for me. I Think I can have minimal support using a similar transformation as the one you proposed to pivot.

In all cases, thank you very much for your time and your reactivity

Regards

G. Vega
Re: UML-OCL ; specifying constraints in the context of an association / association class [message #1729589 is a reply to message #1729586] Fri, 15 April 2016 16:34 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

CompleteModel::allOwnedElements() looks like an unwated inheritance
waiting to be removed / implemented.

From a CompleteModel descend through the CompletePackages to the
CompleteClasses in each of which you can naigate the PartialPackages /
PartialClasses to the per-Model Packages / Classes. In many cases more
functionality is available by casting to ...Internal.

The API is not written up and is inadequate. If you care to contribute
some helper functions...

The API should be helpful and obvious for users like you.

Regards

Ed Willink

On 15/04/2016 17:27, German Vega wrote:
> Hi Ed,
>
> I just downloaded the nightly build, and everything is working perfectly. Both for essential and complete OCL. Both with Papyrus and my standalone program.
>
> I have just one last question. In my tool, I have some constraints defined in the UML model, and other constraints in several different complete OCL documents (to allow handling different concerns independently) that I load in the resource set. I would like to have access to the merged complete class with all its constraints, irrespective of the source. I have tried the following in my program :
>
>
> /*
> * Traverse complete model (not sure how this API works, just trying it out !)
> */
> CompleteModel completeModel = ocl.getCompleteEnvironment().getOwnedCompleteModel();
> for (org.eclipse.ocl.pivot.Element element : completeModel.allOwnedElements()) {
> if (element instanceof org.eclipse.ocl.pivot.CompleteClass) {
> org.eclipse.ocl.pivot.CompleteClass completeClass = (org.eclipse.ocl.pivot.CompleteClass) element;
> System.out.println("iterating complete class "+completeClass.getName()+" in package "+completeClass.getOwningCompletePackage().getName());
> for (org.eclipse.ocl.pivot.Class partialClass : completeClass.getPartialClasses()) {
> for (org.eclipse.ocl.pivot.Constraint oclConstraint : partialClass.getOwnedConstraints()) {
> System.out.println(" constraint "+oclConstraint.getName());
> show(ocl,oclConstraint);
> }
> }
> }
> }
>
>
> But it doesn't seems to work. Is this the correct way? is there another API? I didn't find a tutorial or example showing this. Besides, the iteration returns me all the classes, including the UML metamodel and standard profiles, is there any API to only get the pivot classes for my UML model?
>
> Concerning our discussion about n-ary associations. I have to admit that I got completely lost in the last messages. I Think we were not talking about the same thing.
>
> To clarify my mind I wrote a small document with my understanding of UML n-ary associations. I attached it, in case you have some time to take a look. But it is not urgent. As I told you before, the tool I work in transforms from UML to a formal language. It currently doesn't support n-ary associations. So our discussion has been very enlightening for me. I Think I can have minimal support using a similar transformation as the one you proposed to pivot.
>
> In all cases, thank you very much for your time and your reactivity
>
> Regards
>
> G. Vega
Previous Topic:Global operation for oclAny
Next Topic:OCL git repository
Goto Forum:
  


Current Time: Fri Dec 15 23:47:26 GMT 2017

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

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