Re: OCL 2.0 Type Inference

Date view Thread view Subject view Author view Attachment view

From: Frédéric FONDEMENT (
Date: Thu 08 Jan 2004 - 14:53:02 GMT

Dear all,

As far as I understand the problem, the collection should be not of one but
of multi-types. Ideally, the resulting Set{c,d} complies with types Set(A),
Set(B), Set(OclAny). What seems strange here is A does not conforms to B,
so, the Class of the resulting CollectionLiteralExp should be both Set(A)
and Set(B). But this problem is almost the same in 0..1 association
navigation. Imagine the system

Class C1;
Class C2;
Association c1c2 {
        c1 : C1 [*];
        c2 : C2 [0..1];

The OCL expression myC1.c2 (assuming myC1 is an object of type C1) may
result both on a C1 and on a Set(C1), that are types that does not conform
to each other (worse : they have no common supertype !). All the same for
any 0..1 multiplicities (attributes, parameters, return types,...).

I can see two solutions for this problem:
    * make the association end of multilicity * in association from
OclExpression to Classifier, but this requires to change lots of things in
the OCL specification, for instance in abstract to concrete syntax (rem: in
UML, an instance has the possibility to have several types).
    * subclass Classifier or a composite referencing all directly compatible
types with specific compatibility rules, this requires to change less
In both solution, operation commonSuperType has to be changed.

This way, all expressions Set{c, d}.a and Set{c, d}.b are valid at
typechecking as they intuitively should.

----- Original Message ----- 
From: <>
To: <>
Sent: Monday, December 22, 2003 6:52 AM
Subject: OCL 2.0 Type Inference

> Hi,
> I have some questions about type inference in OCL 2.0. If possible, please
> me to the relevent part of the specification (PTC/03-10-14 or a later
> Consider these classes:
>      Class A { a : Integer }
>      Class B { b : Integer }
>      Class C subclasses A, B
>      Class D subclasses A, B {
>          cd(c : C, d : D) : Sequence(Integer)
>      }
> And this set of postconditions (please ignore the fact that they are
> inconsistent with each other):
>     context D::cd(c : C, d : D):
>     post A: result = Sequence { c, d }.collect( v | v.b }
>     post B: result = Sequence { c, d }.collect( v | v.a }
>     post C: result = Sequence { c, d }.collect( v | v.a + v.b )
> Questions:
> 1. What is the type of the subexpression Sequence { c, d }? The most
> common supertype of C and D is OclAny, so is it Sequence(OclAny)?
> 2. Are postconditions A and B well-typed and well-defined? If the answer
> question #1 is Sequence(OclAny) then the answer is "no" and "no," right?
> 3. Is postcondition C well-typed and well-defined? I am going to say "no"
> "no" because there seems to be no way to type the iteration variable.
> 4. I assume it is the case that expressions that are not well-typed are
> undefined; i.e. an OCL expression evaluator is not required to accept any
> expression that it cannot statically typecheck before attempting any
> Is that correct?
> Thank you,
> Brian
> To remove yourself from this list please mail
> with a message containing the word "unsubscribe".

Date view Thread view Subject view Author view Attachment view