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

[Andreas Maier <maiera@xxxxxxxxxx>]

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

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.

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