UML Properties - quo vadis Attributes?

[Paolo F Cantoni]

In my posting When is a Property not a Property?  I observed that coding language Properties and UML Properties are not the same thing.

I asserted that coding language Properties are just Operations masquerading as Attributes.

More precisely I meant to say:  coding language Properties are just UML Operations masquerading as UML Attributes.

Well, I wasn't exactly correct.  You see, there are NO LONGER (as of the [size=13]UML 2.1 Superstructure (interim)[/size] Specification and the [size=13]UML 2.0 Superstructure (formal)[/size] Specification) UML Attributes - that is UML Elements whose name is Attribute (with a capital A).  UML 2 renamed Attribute to Property!  There are attributes, but they are now Properties of Classes - specifically ownedAttribute..

Now, I (and obviously all the other readers of that posting) missed that until now - otherwise some one would have taken great glee in correcting me!

Within that thread, the posting: Property Redux describes my views on modelling coding language properties and how I believe they could be modelled.

So it seems that what we previously called Attribute we now need to call Property.

Thus, a coding language Property is now a UML Property with accessors.

What does this mean for UML modelling of such coding language Property constructs?

It seems to me that in order to correctly round-trip such constructs the coding language Property must ostensibly appear to be an EA Attribute (thus an UML Property).  Fortunately, EA seems to agree thus far.  You can designate an EA Attribute as a coding language Property.

Secondly, the coding language Property must specify where it has read or write accessors.  EA also concurs.

The visibility of the coding language Property defines that of the accessors.  EA (incorrectly in my view) allows this to be variable.  However proper modelling discipline will solve that.

The name of the accessors must be the same as the coding language Property  (if exposed - such as with some forms of Basic).  EA allows separate naming, discipline will help. By setting the Language type corectly you can get EA to force the accessor Operations to have this constraint for the language.

The coding language Property must allow the definition of the appropriate accessor bodies.  EA supports this, however, from a modeling perspective, these accessors are normally one 'level below' the coding language Property.  Fortunately, EA allow the suppression of Property methods via the Hide Property methods checkbox in the Diagram properties dialog.  This allows only the coding language Property to be visible in the Class structural compartment.

Where a coding language Property actually interacts with one or more other UML Properties, it would be nice to be able to record this dependency.  In particular, where a coding language Property is simply used to set and get another UML Property, one could have a checkbox so indicating that and a link to the bound UML Property.  The accessor bodies could then be generated without further input.

[sargasso]

Hmmmm.

UML 2 renamed Attribute to Property!  There are attributes, but they are now Properties of Classes - specifically ownedAttribute..

In the Infrastructure, at 10.2 the opposite seems to be being said.  i.e. Classes have attributes, attributes are properties.

To simplify (haha) Infra figure 66 (section 10.2) ...


Where in the superstructure did you get your viewpoint?


bruce

p.s. some food for thought - a property in a specialized class that modifies an attribute of the base class ...

p.p.s. I'm having trouble finding anything about the behvioural aspects of UML features - structural or otherwise??? AHA! 7.3.5

Operations of a class can be invoked on an object, given a particular set of substitutions for the parameters of the operation. An operation invocation may cause changes to the values of the attributes of that object. It may also return a value as a result, where a result type for the operation has been defined. Operation invocations may also cause changes in
value to the attributes of other objects that can be  navigated to, directly or indirectly, from the object on which the operation is invoked, to its output parameters, to objects navigable from its parameters, or to other objects in the scope of the operation’s execution. Operation invocations may also cause the creation and deletion of objects.

 Ergo : UML attributes are structural not behvioural, so exhibit no behaviour, even if they are (UML) Properties.  So much for theory.  

[Paolo F Cantoni]

bruce,

I'll again answer your excellent posting in a number of bits.  [BTW: if you want to reply to this post (and retain the name) use quote instead of reply, then retain or discard the quoted text as you will]

In my posting
Well, I wasn't exactly correct.  You see, there are NO LONGER (as of the [url=http://www.omg.org/cgi-bin/doc?ptc/2006-04-02][size=13]UML 2.1 Superstructure (interim)[/size] Specification and the [size=13]UML 2.0 Superstructure (formal)[/size] Specification) UML Attributes - that is UML Elements whose name is Attribute (with a capital A).  UML 2 renamed Attribute to Property!  There are attributes, but they are now Properties of Classes - specifically ownedAttribute..

If you search the the [size=13]UML 1.42 Infrastructure (formal)[/size] Specification for the word Attribute (case sensitive, whole word) you'll find 60 references, including:

4.5.2.6 Attribute
An attribute is a named slot within a classifier that describes a range of values that instances of the classifier may hold.
In the metamodel, an Attribute is a named piece of the declared state of a Classifier, particularly the range of values that
Instances of the Classifier may hold.

If you do the same for the the [size=13]UML 2.1 Superstructure (interim)[/size] Specification, you find exactly 9 references - not one of which defines what an Attribute is.
You will find:

7.3.44 Property (from Kernel, AssociationClasses)
A property is a structural feature.
A property related to a Classifier by ownedAttribute represents an attribute, and it may also represent an association end.  It relates an instance of the class to a value or collection of values of the type of the attribute.
A property related to an Association by memberEnd or its specializations represents an end of the association. The type of property is the type of the end of the association.

I think you'll agree that the definition of Property under UML2 is essentially that of Attribute under UML 1.x

Similarly with AssociationEnd (84 references in UML 1.42, 11 references in UML 2.1)  One of which says:

AssociationEnd was a metaclass in prior UML, now demoted to a member of Association.

It looks to me as thought the same thing has happened to Attribute.  The metaclass is now Property and Attribute is just a member of Class.

It's interesting to note that the specific phrasing "a named, navigable AssociationEnd is an Attribute" which I quoted from a previous UML 1.x specification is no longer explicitly found in UML 2.  However, it is still implied in the above definition of Property.

So, the upshot for me is:
Classifiers have Properties.  If the Classifier is a Class then some Properties are Attributes, some are AssociationEnds (and some, in my view, if named and navigable, are both).

Using this ontology, I can now fit coding language Properties into this model fairly easily.  All Properties have accessors.  Some, local attributes, are set and retrieved by direct access.  Others, coding language properties, use accessor methods. Yet others, association ends, are set/retrieved by  the type of the end.

That is, a coding language Property is an Attribute with accessor methods (under the covers).  Since the accessor methods are not directly visible, such a Property still exhibits the only required semantics for a StructuralFeature: A structural feature specifies that instances of the featuring classifier have a slot whose value or values are of a specified type.

Thoughts?
Paolo

[Paolo F Cantoni]

p.s. some food for thought - a property in a specialized class that modifies an attribute of the base class ...

bruce,

I'm not sure what you were getting at here.  Do you think it's good or bad that one can do this?

FWIW, I think it's neat  It's actually how I managed to implement Inheritance in Embarcadero Sax Basic - which has "Classes" but no Inheritance!

I also think it allows controlled semantically correct access, to possibly overloaded, attributes.

Another place I use it is in interfacing to external artifacts.  I may have an internal code and a UI caption and an export mnemonic.  If I set the code, I want the caption and the mnemonic to be set accordingly.  Similarly, if the caption is selected in the UI, I want the code and mnemonic to be set.  If I import the mnemonic, I want the code and caption to be set - you get the picture.  This is a neat little pattern with three coding language Properties.  The setters of each Property automatically cause the others' vale to be set.

Ergo : UML attributes are structural not behavioural, so exhibit no behaviour, even if they are (UML) Properties.  So much for theory.  

Again, not sure what you're criticising.  The Infrastructure and the Superstructure, to my view, seem to agree that attribute is now a member of Class and not a metaclass in and of itself.  Whereas Property is now the metaclass.

In the other reply I mentioned that the only semantic requirement of the StructuralFeature was that it specifies that instances of the featuring classifier have a slot whose value or values are of a specified type.   It doesn't, in my view, actually exclude behavioural aspects.  In particular, since the accessors for a coding language property are under the covers, to the outside world it mainly behaves like a structural feature.

Admittedly, I think I'd like more explicit support for coding language Properties in the UML but I guess we'll have to wait.

Paolo

BTW: I note you're using the operations compartment for properties.  The kinds of coding language Properties I'm talking about would really appear in the Attributes compartment since their accessors are not directly visible externally.