Home » Modeling » OCL » Type Checking: Union Operation
|
| Re: Type Checking: Union Operation [message #1070517 is a reply to message #1070363] |
Thu, 18 July 2013 06:20   |
 Ed Willink
Messages: 7655
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 |
Ed Willink
Messages: 7655
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
>
|
|
|
Goto Forum:
Current Time: Sat Apr 20 08:00:42 GMT 2024
Powered by FUDForum. Page generated in 0.03842 seconds |
] 
Search
Help
Register
Login
Home
