| Can OCL initialization constraints modify the system ? [message #18736] |
Wed, 18 April 2007 17:07  |
Eclipse User |
|
|
|
Originally posted by: maiera.de.ibm.com
Hi,
One thought that came up in our CIM mapping to UML is to use OCL
initialization constraints not only to test the initial value of a
property against the constraint, but instead to consider the OCL
constraint to be the rule by which the initial value is set.
However, that seems to be in conflict with the general OCL statement
that OCL constraints never change the system.
On the other hand, one could argue that the precise statement made in
the OCL spec is that the evaluation of the OCL statement must not have
any side effects that change the system, and when the result of an init
constraint is used to set the initial value of a property, then it is
not the evaluation of the constraint that had this side effect, instead
it was the usage of the result of the evaluation that did.
I am seeking for guidance as to whether such usage (setting the initial
value of a property in an instance to the value to which an init
constraint evaluates) is in sync or in conflict with OCL (the spec, the
spirit, whatever)
Andy
|
|
|
| Re: Can OCL initialization constraints modify the system ? [message #18760 is a reply to message #18736] |
Wed, 18 April 2007 17:24  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Andy,
My own interpretation is that the initial-value constraint is just a
constraint. It constrains the property, requiring its initial value to be
whatever the OCL evaluates to. It differs from a derivation constraint
inasmuch as it only applies to the *initial* value. If that value is ever
changed (for a writable property) or recomputed (for a derived property),
then the initial-value constraint ceases to apply.
If an implementation of your system chooses to use the constraint in setting
the initial value of a property, I don't see any problem in that. The OCL
Specification doesn't prescribe (even in spirit, IMO) how a system is to
set the initial state of anything. Consider that the constraint might be
an input to a code generator that transforms the initial-value expression
to the target programming language in a property/field/whatever
initializer. In that case, there needn't even be any manifestation of the
OCL expression as a "constraint" at run-time.
Of course, this is all my own (not always well-informed) opinion and is in
no way authoritative. For that, the OMG would be your source.
HTH,
Christian
Andreas Maier wrote:
> Hi,
> One thought that came up in our CIM mapping to UML is to use OCL
> initialization constraints not only to test the initial value of a
> property against the constraint, but instead to consider the OCL
> constraint to be the rule by which the initial value is set.
>
> However, that seems to be in conflict with the general OCL statement
> that OCL constraints never change the system.
>
> On the other hand, one could argue that the precise statement made in
> the OCL spec is that the evaluation of the OCL statement must not have
> any side effects that change the system, and when the result of an init
> constraint is used to set the initial value of a property, then it is
> not the evaluation of the constraint that had this side effect, instead
> it was the usage of the result of the evaluation that did.
>
> I am seeking for guidance as to whether such usage (setting the initial
> value of a property in an instance to the value to which an init
> constraint evaluates) is in sync or in conflict with OCL (the spec, the
> spirit, whatever)
>
> Andy
|
|
|
|
Powered by
FUDForum. Page generated in 0.04541 seconds
Home