Re: OCL 2.0 Type Inference

Date view Thread view Subject view Author view Attachment view

From: Frédéric FONDEMENT (
Date: Thu 22 Jan 2004 - 12:17:54 GMT


This is described page 2-12, chapter 2.5.3, § Navigation over Associations with multiplicity Zero or One. You seem right when saying this is not described a formal way... Abstract to concrete syntax does not care of type checking, so does mathematical semantics. Am I right ?

  ----- Original Message ----- 
  From: Steffen Zschaler 
  Sent: Tuesday, January 20, 2004 10:56 AM
  Subject: Re: OCL 2.0 Type Inference


  Can you point me to the part of the specification from which you infer any normative information on the type of a navigation via an association end (an AssociationEndCallExp)? I've browsed through the OCL 2.0 spec once more and there seems to be no formal definition of this. This is of course a problem in itself and it should be fixed, but this would also allow to define the type of 'myC1.c2' to be C2 regardless of whether or not an object was associated. If no object is associated the value of the expression would simply be OclUndefined.


  Frédéric FONDEMENT schrieb:

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


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 )


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,

To remove yourself from this list please mail
  with a message containing the word "unsubscribe".


To remove yourself from this list please mail
with a message containing the word "unsubscribe".


Dipl.-Inf. Steffen Zschaler
Research Assistant

Dresden University of Technology
Department of Computer Science

Phone +49 351 463 38555
Fax   +49 351 463 38459

Date view Thread view Subject view Author view Attachment view