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

["James Bruck" <jbruck@xxxxxxxxxx>]

Andy,

Just wanted to point out that the latest version of UML has separated the
concepts of navigability from association end ownership.  In UML 2.1, a new
"black dot" notation has been introduced where it is desired to make
ownership explicit.
In some cases an association between two classes could mean that at runtime,
there exists some "lookup table" that defines a relationship between two
instances of classes.

Have a look at the spec and
http://www.eclipse.org/modeling/mdt/uml2-uml/docs/guides/UML2_2.0_Migration_Guide/guide.html
for a brief explanation.

( I hope that helps in some way ;)  )

Regards,

- James.

"Christian W. Damus" <cdamus@xxxxxxxxxx> wrote in message
news:elbsn2$2m1$1@xxxxxxxxxxxxxxxxxxxx
>
> 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
> >>
>