Not quite an Attribute, not quite a Method. Stereotypes? <
<
?
I\'m retro-modelling an existin
Eh, I just throw it in as a method in my pseudo-UML diagrams. :-)
The problem with depicting a property as a single field is that for C# using the 2.0 framework and beyond the get and set can have different access modifiers.
I'd put them as public fields in UML, because that's what they are conceptually. UML is not a syntax for your programming language (although some tool vendors claim that it is).
The details on how your implementation language handles properties don't need to show in the UML. This would entirely defeat the point of using UML as a tool that abstracts away the implementation details and lets you focus on design.
If the property is special in some way, such that it is derived or read-only, you can mark that with a stereotype annotation.
I usually prepare my UML diagrams in Visio (I know, I know; but what're ya gonna do?).
When diagramming properties, they end up as so:
+------------------------+
| MyClass |
|------------------------|
| - _foo : int |
|------------------------|
| «property» + Foo : int |
+------------------------+
«property» being a custom stereotype derived from «operator».
Ugly, I know. But it works, and it's clear. I do constructors the same way.
In Visio you can create a <<readonly>> stereotype for Attribute and just use this stereotype for each read-only attributes. Same for write-only. It'll show you a good notation:
<<readonly>> +PropertyName : int
There is nothing ugly about it. The standard Visio's Changeable option is much more uglier in that it has no any visual representation and you actually need to open properties for each attribute in order to see it, no chances to see it on the printed diagram.
You could use a stereotype called "property"(eg. << Property >> PropertyName) for a field in your class diagram. Stereotypes are used to extend UML notation.