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

["James Bruck" <jbruck@xxxxxxxxxx>]

"James Bruck" <jbruck@xxxxxxxxxx> wrote in message 
news:elc23t$3op$2@xxxxxxxxxxxxxxxxxxxx
> 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
>> >>
>>
>
>