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

[cdamus@xxxxxxxxxx (Christian W. Damus)]

Hi, Andy,

I was thinking again about this, and I think that perhaps we need to 
consider instances of Associations as more like tuples (values) than like 
objects.  If we think of an instance of an association as a tuple whose 
parts are the associated objects, then writing one of the association 
member ends amounts to creating a different tuple.  IOW, association 
instances are immutable values.  It also doesn't make sense to create the 
same association twice with the same objects at the same ends.

A navigable association end is a property of the classifier at that end, 
so reading and writing it makes sense from the perspective of an instance 
of that classifier.  When this property is changed, then the instance is 
put into a different association, but it remains the same instance.

Perhaps the analogy is clearer in the case of n-ary associations (n > 2), 
in which by definition none of the member ends is navigable.  This really 
does have the look and feel of a tuple.

Does that make any sense?

Cheers,

Christian

Andreas Maier wrote:

<snip>

> 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