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

["Antonio Carrasco" <carrasco@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Christian,
your reflections about association and tuples
not only make very good sense:
I have heard various teams working with semantic web,
ontologies, RDF & OWL, in similar terms.
  - I?d say their concept of property matches your statements pretty well.
They seem to obtain numerous benefits from using a RDF-OWL core,
rathern than MOFish/EMF (what remains a dashboard instrumentation 
mechanism).




"Christian W. Damus" <cdamus@xxxxxxxxxx> wrote in message 
news:d23b7132d16a0f22d6e68d8c94e60db1$1@xxxxxxxxxxxxxxxxxx
>
> 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
>>>
>