[news.eclipse.modeling.mdt.uml2.ocl] Re: Built-in validation for read-on

["Christian W. Damus" <cdamus@xxxxxxxxxx>]

Hi, Andy,

I think my understanding of what the spec intends to mean by some of these
concepts is probably incomplete and/or inaccurate, so I'm copying the UML
newsgroup in case Kenn or James (or anyone there) can provide better
answers.

I'll try to respond with my own interpretations, in-line.

Cheers,

Christian


Andreas Maier wrote:

> Christian,
> I think I do not understand what "writing" or "updating" means from a
> UML spec perspective.
> 
> To put this into perspective, here is what "writing" means in CIM. In
> CIM, the server side instrumentation is in control of the property
> values. These values can change on behalf of the resources that are
> instrumented (this is what we call "volatile" properties because from a
> client application's perspective they may change even though the client
> application did not cause the change), and they can in addition be
> changed by client applications. In the first case, no client application
> is involved in the change. In the second case, the property needs to be
> qualified as writeable (by means of the Write qualifier which we map to
> UML isReadOnly) for the client application to actually do the change.
> 
> But what does "writing" mean in a UML model ? The modeler must not
> modify the value after it initially was defined ? Or is it something
> that is meant to apply to the run-time of an implementation of the
> modeled system ? And if so, is a change that happens on behalf of the
> implementation itself (i.e. the volatile case from above) considered a
> "change" ?

The isReadOnly attribute constrains the behaviour of the run-time system
that is being modeled.  I think that what the spec intends is that, for a
property that is read-only, the value of that property for a given object
cannot be modified by other objects (by behaviors modeled via
WriteStructuralFeatureActions).  I think it does not mean that the value
cannot change (in a way that appears spontaneous to an observer), only that
other objects cannot implement that change.


> My second question is why non-navigable properties cannot be written.
> They are properties that are owned by an association, but otherwise they
> are just normal properties. I don't see a reason why they need to be
> read-only any more than navigable properties or any old non-endpoint
> property.

I'm only just guessing, here.  As far as I understand, non-navigable
properties exist to provide names for association ends in the model (as
documentation of the system) but that, in the run-time system, these
properties don't really exist in the classifiers at the ends of the
association.  I don't know what the spec intends for programming languages
to do with non-navigable association ends (or even associations in which
all ends are non-navigable), whether associations are really meant to be
instantiated in any way as classifiers.  Perhaps the UML newsgroup can be
of more help in answering this one ...

> 
> Andy
> 
> 
> Christian W. Damus wrote:
>> Interestingly, the spec also has this to say (p. 129) on the subject of
>> read-only properties:
>> 
>>     If a navigable property is marked as readOnly, then it
>>     cannot be updated once it has been assigned an initial
>>     value.
>> 
>> This allows the possibility of non-derived read-only properties.  These
>> would usually be initialized, I except, by an "init:" expression
>> specified in OCL.
>> 
>> Cheers,
>> 
>> Christian
>> 
>> 
>> Christian W. Damus wrote:
>> 
>>> Hi, Andy,
>>>
>>> This is Property constraint [6] on p. 127 of the UML2 2.1 specification.
>>>
>>> The specification doesn't discuss the reason for this at all, but I
>>> would guess that the reason is that it isn't possible to read a
>>> non-navigable property (that is why it isn't navigable), so it would not
>>> make sense to
>>> indicate that it can only be read.  A non-navigable property wouldn't be
>>> writable, either.
>>>
>>> isReadOnly in UML means that the property "may only be read, not
>>> written"
>>> (p. 125).  It does not necessarily indicate that the value is derived
>>> (which I think is what you mean by volatile).
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>>
>>> Andreas Maier wrote:
>>>
>>>> Hi,
>>>> in our CIM mapping to UML, we are mapping the Write qualifier in CIM to
>>>> the isReadOnly UML attribute. In CIM, associations have ends that do
>>>> not have the Write qualifier set. This consequently results in UML
>>>> association ends that have isReadOnly set to true.
>>>>
>>>> When I run model validation, the following built-in validation rule
>>>> pops up due to this:
>>>>
>>>> Non-navigable property '<<property_Constraints, cIM_Reference>>
>>>> <Property> UserOfService : CIM_LogicalFile [0..*]' is marked as
>>>> read-only.
>>>>
>>>> It may be that the semantics of writeability is slightly different
>>>> between CIM and UML. In CIM, it means that a client application should
>>>> expect to be able to modify the property value.
>>>>
>>>> My questions are:
>>>>
>>>> - What is the purpose of this built-in validation rule ?
>>>>
>>>> - What is the exact semantics of isReadOnly in UML ? (i.e. unmodifiable
>>>>    vs. not volatile)
>>>>
>>>> Andy
>>