How to represent a C# property in UML?

问题:

Not quite an Attribute, not quite a Method. Stereotypes? <<get>> <<set>>?

---

I'm retro-modelling an existing system, so I need to clearly reflect that this is not the same as a readonly field or a methods pair (regardless of what the IL says), so I think I'll go with the stereotype, but I'll accept the language independant get_ set_ as a general solution. Thanks all for the sanity test.

回答1:

Properties are just a convenient way of writing get_MyValue() and set_MyValue(value) allowing assignment rather than the normal method calling (using parenthesis).

What you are accessing is actually a .NET property, C# has its own syntax for accessing these. Since under the skin the real get_ and set_ methods are created, so you could simply show those methods (to make your UML language independent - e.g. make your UML equally applicable to a VB.NET developer)

... or as you have suggested, introduce your own stereotype!

回答2:

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.

回答3:

You can represent properties the same way as fields. To specify additional info like readonly or writeonly you can use

+Name:string {READONLY}

回答4:

I've been using <<get>> and <<set>> stereotypes next to property names so they look like fields, yet allows you to differentiate the access modifiers for the get or set:

+=============================+
| ClassName                   |
+-----------------------------+
| +<<get>> Id : int           |
| -<<set>> Id : int           |
| +<<get>> IsSomething : bool |
+-----------------------------+
| + Method1(arg1 : string)    |
+=============================+

Alternatively, if you don't want more than one occurrence of a property, this could work as well:

+=============================+
| ClassName                   |
+-----------------------------+
| +<<get>> -<<set>> Id : int  |

And to reduce clutter, if the get and set have the same access modifier:

+====================================+
| ClassName                          |
+------------------------------------+
| +<<get, set>> Description : string |
| +<<get>> -<<set>> Id : int         |

This clearly communicates whether a property has a get or set, and if it is readonly (by way of no <<set>> existing in the class diagram). So basically what you said in your question.

While properties are syntactic sugar for getter and setter methods, they are supposed to feel like fields, and I believe the UML diagram should reflect that fact, and at the same time also communicate what is public and what is private, and also whether a setter exists or not.

回答5:

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.

回答6:

Eh, I just throw it in as a method in my pseudo-UML diagrams. :-)

回答7:

properties are Get/Set methods wrapped up in some nicer syntax. Just put them in as methods, or create some new UML syntax for them :)

回答8:

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.

回答9:

I agree with workmad3. Properties are just a trick make a get/set methods a little bi nicer. For that reason I think it should be saved as a two different methods. What is more in this case you can set a different access permissions for them

回答10:

I use like this

-memberThePropertyWillExpose
+memberThePropertyIsExposing

Well, comments on this are welcome if this is a right way !!

回答11:

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.

回答12:

You could use a stereotype called "property"(eg. << Property >> PropertyName) for a field in your class diagram. Stereotypes are used to extend UML notation.