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: Thu 22 Jan 2004 - 12:53:52 GMT


I believe yes. The place where one would expect such a definition would 
be in the WFRs for AssociationEndCallExp in the abstract syntax chapter. 
But there are none defined atm.

Steffen

Frédéric FONDEMENT schrieb:

> Hi,
>  
> 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 ?
>  
> Frederic
>
>     ----- Original Message -----
>     From: Steffen Zschaler <mailto:sz9@inf.tu-dresden.de>
>     To: puml-list@cs.york.ac.uk <mailto:puml-list@cs.york.ac.uk>
>     Sent: Tuesday, January 20, 2004 10:56 AM
>     Subject: Re: OCL 2.0 Type Inference
>
>     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
>
>

-- 
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