Re: InOut Variables (Operations' Semantics)



Date view Thread view Subject view Author view Attachment view

From: Steffen Zschaler (sz9@inf.tu-dresden.de)
Date: Fri 28 Jan 2005 - 08:33:47 GMT


Dear Percy,

No, you cannot assume that s1=s1@pre. There is no way to say 'and 
nothing else changes' in OCL, so if this is important to your 
specification, you must explicitly mention it. Alternatively, if your 
operation does not effect any changes to the system state, you can mark 
it as an observer. However, although this attribute is respected by OCL 
(observer operations are the only ones that can be invoked from an OCL 
expression), I am not currently sure, how you can set the marking. I 
think it should be somewhere in the UML spec, but cannot recall where at 
the moment.

Best wishes,

Steffen

Percy Pari Salas schrieb:

> Hello all,
>
>>
>> What Percy meant is probably: "attributes can be read and modified in 
>> an OCL expression"?
>> If that is what he meant, the answer could be complemented with "No, 
>> because OCL expressions may not alter an objects state. They would be 
>> of kind 'in', if the kind would apply to attributes.".
>>
>> Kind regards,
>> Andreas
>>
> Andreas is almost right, but what I exactly mean is the following:  
> suppose we have a Class Triangle with integer attributes s1,s2,s3 
> (representing the sides of the triangle). I model an operation 
> triangleKind as
>
> context Triangle::triangleKind():String
> Post: if s1=s2 and s2=s3 then result = "equilateral" else (result = 
> "isosceles" or result = "scalene")
>  (I'm just simplifying the specification)
>
> Well, look that I am not saying anything about the pre-state, I am 
> just restricting the output (result) by evaluating the values of the 
> post-state. The question is... it can be safely assumed that this 
> specification ensures (for example) that s1=s1@pre ???  Moreover, if I 
> have an IMPLEMENTATION of triangleKind that before evaluating the 
> values and deciding the output assigns new (random) values to s1,s2,s3 
> and after that satisfies the postcondition; this implementation still 
> conforms the OCL specification (even when   NOT s1=s1@pre  or   NOT 
> s2=s2@pre  ... )
>
> Thanks for your answers,
>
>  Percy Pari Salas
> UNU-IIST Fellow
> Macau SAR - China
>
>>
>> -- 
>> Andreas Awenius
>> EmPowerTec AG
>> Taubenweg 20
>> 85238 Petershausen
>> Fon: +49 8137 80 98 81
>> Fax: +49 8137 80 98 82
>>
>>
>>
>>
>> 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

Technische Universitšt Dresden
Department of Computer Science

Phone +49 351 463 38555
Fax   +49 351 463 38459
Email Steffen.Zschaler@inf.tu-dresden.de
WWW   http://www.inf.tu-dresden.de/~sz9

Date view Thread view Subject view Author view Attachment view