Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Type Checking: Union Operation
Type Checking: Union Operation [message #1070363] Wed, 17 July 2013 20:18 Go to next message
John Guerson is currently offline John Guerson
Messages: 51
Registered: August 2011
Member
Hi guys,

The OCL union operation requires collections(sets) of the same type?
To illustrate my point:

Assuming, for instance, a class Person and three subtypes Child, Teenager and Adult. Al these three subclasses have an association with a class School.

context School inv: self.child->union(self.teenager)->union(self.adult)->isUnique(x.address)

(Just for exemplifying my point). The classes Child and Teenager have the same supertype. By I'm getting a type check error on the OCL union operation.

I'm using UML's implementation of OCL (Juno) with Complete OCL documents. How Kepler's implementation of OCL deal with this? Is there a way of getting out of this issue?

Regards,

John
Re: Type Checking: Union Operation [message #1070517 is a reply to message #1070363] Thu, 18 July 2013 06:20 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4046
Registered: July 2009
Senior Member
Hi

The OCL specification is not clear about operation inheritance and so
the classic implementation of Eclipse OCL takes the rather strict and
unhelpful view that the left hand type is 'correct'.

The new Pivot-based Eclipse OCL has the library defined by a model that
you can replace/customize. T and T1 are no longer magic under-specified
types, they are template parameters. The intended implementation is that
all type conformant operations are available and that the unique most
derived signature is selected. There is also some collection
conformance, so Set is a specialization of Bag, UniqueCollection and
OrderedSet is a specialization of Sequence, UniqueCollection.

When you say UML's implementation of OCL, I cannot tell what you mean
The classic Eclipse OCL had distinct org.eclipse.iocl.uml plugins. The
new Pivot-based OCL is neutral. If you're using Papyrus or an OCL editor
then you are using the Pivot-based OCL. At the Java level it depends on
your package imports. You can choose between classic and new (Xtext)
consoles. You can choose classic(LPG) or new (Pivot) evaluation in the
OCL preferences.

If you have a peroblem with the new Pivot OCL please post a Bugzilla.

Regards

Ed Willink

On 17/07/2013 21:18, John Guerson wrote:
> Hi guys,
>
> The OCL union operation requires collections(sets) of the same type?
> To illustrate my point:
>
> Assuming, for instance, a class Person and three subtypes Child,
> Teenager and Adult. Al these three subclasses have an association with
> a class School.
>
> context School inv:
> self.child->union(self.teenager)->union(self.adult)->isUnique(x.address)
>
> (Just for exemplifying my point). The classes Child and Teenager have
> the same supertype. By I'm getting a type check error on the OCL union
> operation.
> I'm using UML's implementation of OCL (Juno) with Complete OCL
> documents. How Kepler's implementation of OCL deal with this? Is there
> a way of getting out of this issue?
> Regards,
>
> John
Re: Type Checking: Union Operation [message #1070584 is a reply to message #1070517] Thu, 18 July 2013 09:01 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4046
Registered: July 2009
Senior Member
Hi

I just wrote a couple of JUnit tests

PASS: let reals : Set(Real) = Set{1.0,2.0,3.0}, nats :
Set(UnlimitedNatural) = Set{2,3,4} in reals->union(nats)
FAIL: let reals : Set(Real) = Set{1.0,2.0,3.0}, nats :
Set(UnlimitedNatural) = Set{2,3,4} in nats->union(reals)

Caused by: org.eclipse.ocl.examples.pivot.SemanticException: Errors in
'let reals : Set(Real) = Set{1.0,2.0,3.0}, nats : Set(UnlimitedNatural)
= Set{2,3,4} in nats->union(reals)'
1: Unresolved Operation 'Set(UnlimitedNatural)::union(Set(Real))'

This is actually the oldest outstanding bug for Eclipse OCL that I
raised long before OCL became my responsibility.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=184329#c3

I can't really argue with my final comment 2:

"Fundamentally there is a collection operation for which the expression
is valid, ..."

In OCL, collection operations appear to produce new collections so there
is no need to treat the left hand operand type as special. The 'grey'
area should be resolved towards safe utility.

I'll fix this for the pivot analyzer.

Regards

Ed Willink

On 18/07/2013 07:20, Ed Willink wrote:
> Hi
>
> The OCL specification is not clear about operation inheritance and so
> the classic implementation of Eclipse OCL takes the rather strict and
> unhelpful view that the left hand type is 'correct'.
>
> The new Pivot-based Eclipse OCL has the library defined by a model
> that you can replace/customize. T and T1 are no longer magic
> under-specified types, they are template parameters. The intended
> implementation is that all type conformant operations are available
> and that the unique most derived signature is selected. There is also
> some collection conformance, so Set is a specialization of Bag,
> UniqueCollection and OrderedSet is a specialization of Sequence,
> UniqueCollection.
>
> When you say UML's implementation of OCL, I cannot tell what you mean
> The classic Eclipse OCL had distinct org.eclipse.iocl.uml plugins. The
> new Pivot-based OCL is neutral. If you're using Papyrus or an OCL
> editor then you are using the Pivot-based OCL. At the Java level it
> depends on your package imports. You can choose between classic and
> new (Xtext) consoles. You can choose classic(LPG) or new (Pivot)
> evaluation in the OCL preferences.
>
> If you have a peroblem with the new Pivot OCL please post a Bugzilla.
>
> Regards
>
> Ed Willink
>
> On 17/07/2013 21:18, John Guerson wrote:
>> Hi guys,
>>
>> The OCL union operation requires collections(sets) of the same type?
>> To illustrate my point:
>>
>> Assuming, for instance, a class Person and three subtypes Child,
>> Teenager and Adult. Al these three subclasses have an association
>> with a class School.
>>
>> context School inv:
>> self.child->union(self.teenager)->union(self.adult)->isUnique(x.address)
>>
>> (Just for exemplifying my point). The classes Child and Teenager have
>> the same supertype. By I'm getting a type check error on the OCL
>> union operation.
>> I'm using UML's implementation of OCL (Juno) with Complete OCL
>> documents. How Kepler's implementation of OCL deal with this? Is
>> there a way of getting out of this issue?
>> Regards,
>>
>> John
>
Previous Topic:Problem when opening Ecore file with OCLInEcore using Juno
Next Topic:error when resolving the type of a variable
Goto Forum:
  


Current Time: Mon Sep 22 12:33:35 GMT 2014

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

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