Functionally, there is no difference between invocation of an attribute and
a parameterless operation, except the syntactic difference of parentheses.
In particular, both

- "." notation to invoke features of the value
- "->" notation for collection values
- support the @pre notation for precondition-time values

Note that OCL provides no means to define qualifiers for additional
attributes, so the [...] qualifier notation isn't applicable.

It's interesting to note that some languages, such as Eiffel and even BASIC,
subscribe to a principle of "uniform access" in which the parentheses are
not applied to operations that have no parameters, thus making them
indistinguishable from (and sometimes actually interchangeable with)
attributes.

I didn't understand what you meant by splitting an attribute at
implementation.

There is no population of additional attributes. They are, by definition
(pun intended) derived properties. So, in that respect, they can be
considered as being computed values in the same way as operations are. Of
course, this reflects the MDT OCL implementation. A different
implementation may be able to pre-compute values, cache them, or somehow
make attributes more efficient than operations.

HTH,

Christian

Mark Melia wrote:

> Hi everyone,
>
> I have a question more about the fundamentals of the OCL language, this
> probably not the right place for it, but I have always found here a useful
> place for some insights.
>
> I am trying to figure out is there any fundamental difference between OCL
> defined attributes and operations without parameters (i.e. using the def
> in OCL).
>
> Both require a definition in OCL of how they are defined. I presume this
> means that as attribute will have to be split into an attribute and
> operation at implementation - is this the only difference?
>
> If i define an attribute in OCL is that populated when the context is
> instantiated, whereas an operation is only called when used - so is a
> performance thing?
>
> Ideas/Comments/clarification requests most welcome.
> Mark