Как представить свойство C # в UML?

Question

Не совсем Атрибут, не совсем Метод. Стереотипы? <<get>> <<set>>?

---

Я ретро-моделирую существующую систему, поэтому мне нужно четко отразить, что это не то же самое, что поле только для чтения или пара методов (независимо от того, что говорит IL), поэтому я думаю, что « Я буду придерживаться стереотипа, но я приму независимый от языка get_ set_ в качестве общего решения. Спасибо всем за здравомыслие.

Answer 1

Я обычно готовлю свои UML-диаграммы в Visio (знаю, знаю; но что ты собираешься делать?).

При составлении схемы свойств они в конечном итоге выглядят так:

+------------------------+
| MyClass                |
|------------------------|
| - _foo : int           |
|------------------------|
| «property» + Foo : int |
+------------------------+

«свойство» - это пользовательский стереотип, производный от «оператора».

Гадкий, я знаю. Но это работает, и это понятно. Я делаю конструкторы одинаково.

Answer 2

Свойства - это просто удобный способ записи get_MyValue() и set_MyValue(value), позволяющий присваивать, а не вызывать обычный метод (используя круглые скобки).

То, к чему вы обращаетесь, на самом деле является свойством .NET, C # имеет собственный синтаксис для доступа к ним. Поскольку под оболочкой созданы настоящие методы get_ и set_, вы можете просто показать эти методы (чтобы сделать ваш язык UML независимым - например, сделать ваш UML в равной степени применимым к разработчику VB.NET)

... или, как вы предложили, представьте свой собственный стереотип!

Answer 3

Вы можете представлять свойства так же, как поля. Чтобы указать дополнительную информацию, например, только для чтения или только для записи, вы можете использовать

+ Имя: строка {READONLY}

Answer 4

Я использовал стереотипы <<get>> и <<set>> рядом с именами свойств, поэтому они выглядят как поля, но позволяют различать модификаторы доступа для get или set:

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

В качестве альтернативы, если вы не хотите более одного вхождения свойства, это также может сработать:

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

И чтобы уменьшить беспорядок, если get и set имеют одинаковый модификатор доступа:

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

Это ясно показывает, есть ли у свойства значение get или set, и доступно ли оно только для чтения (из-за отсутствия <<set>> в диаграмме классов). Так что в основном то, что вы сказали в своем вопросе.

Хотя свойства являются синтаксическим сахаром для методов получения и установки, они должны восприниматься как поля, и я считаю, что диаграмма UML должна отражать этот факт и в то же время сообщать, что является общедоступным, а что - частным, а также существует ли сеттер или нет.

Answer 5

Я бы поставил их как открытые поля в UML, потому что это концептуально. UML не является синтаксисом для вашего языка программирования (хотя некоторые поставщики инструментов утверждают, что это так).

Сведения о том, как ваш язык реализации обрабатывает свойства, не должны отображаться в UML. Это полностью устранило бы смысл использования UML в качестве инструмента, который абстрагирует детали реализации и позволяет сосредоточиться на дизайне.

Если свойство каким-то образом особенное, например, оно является производным или доступно только для чтения, вы можете пометить это аннотацией стереотипа.

Answer 6

свойства - это методы Get / Set, заключенные в более приятный синтаксис. Просто вставьте их как методы или создайте для них новый синтаксис UML:)

Answer 7

Эх, я просто добавляю это как метод в мои псевдо-UML-диаграммы. : -)

Answer 8

Я согласен с workmad3. Свойства - всего лишь хитрость, делающая методы get / set немного более приятными. По этой причине я думаю, что это должно быть сохранено как два разных метода. Более того, в этом случае вы можете установить для них разные права доступа

Answer 9

Проблема с изображением свойства в виде единого поля заключается в том, что для C #, использующего инфраструктуру 2.0 и более, чем get и set, могут иметь разные модификаторы доступа.

Answer 10

Вы можете использовать стереотип под названием «свойство» (например, << Property >> PropertyName) для поля в диаграмме вашего класса. Стереотипы используются для расширения нотации UML.