Re: OCL 2.0 Type Inference



Date view Thread view Subject view Author view Attachment view

From: Steffen Zschaler (sz9@inf.tu-dresden.de)
Date: Tue 20 Jan 2004 - 09:56:33 GMT


Hi,

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.

Steffen

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 {
>    ends:
>        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
>things.
>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: <brian-l-smith@uiowa.edu>
>To: <puml-list@cs.york.ac.uk>
>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
>>    
>>
>point
>  
>
>>me to the relevent part of the specification (PTC/03-10-14 or a later
>>    
>>
>version).
>  
>
>>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
>>    
>>
>specific
>  
>
>>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
>>    
>>
>to
>  
>
>>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"
>>    
>>
>and
>  
>
>>"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
>>    
>>
>evaluation.
>  
>
>>Is that correct?
>>
>>Thank you,
>>Brian
>>
>>
>>
>>
>>
>>To remove yourself from this list please mail
>>    
>>
>puml-list-request@cs.york.ac.uk
>  
>
>>with a message containing the word "unsubscribe".
>>
>>    
>>
>
>
>
>
>To remove yourself from this list please mail puml-list-request@cs.york.ac.uk
>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
Email Steffen.Zschaler@inf.tu-dresden.de

Date view Thread view Subject view Author view Attachment view