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

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

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

Ответы

Ответ 1

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

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

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

Ответ 2

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

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

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

"свойство" является обычным стереотипом, полученным из "оператора".

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

Ответ 9

Я использовал стереотипы <<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, и если он является readonly (через no <<set>>, существующий на диаграмме классов). Так что в основном то, что вы сказали в своем вопросе.

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

Ответ 10

Я так использую

-memberThePropertyWillExpose
+memberThePropertyIsExposing

Хорошо, комментарии к этому приветствуются, если это правильный путь!

Ответ 11

В Visio вы можете создать < <readonly → > стереотип для атрибута и просто используйте этот стереотип для каждого атрибута только для чтения. То же самое для записи только. Он покажет вам хорошую нотацию:

<<readonly>> +PropertyName : int

В этом нет ничего уродливого. Стандартный параметр Visio Changeable гораздо более уродливый, поскольку он не имеет никакого визуального представления, и вам действительно нужно открывать свойства для каждого атрибута, чтобы увидеть его, нет шансов увидеть его на напечатанной диаграмме.

Ответ 12

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