Не совсем атрибут, не совсем метод. Стереотипы? <<get>> <<set>>?
Я ретро-моделирование существующей системы, поэтому мне нужно четко отразить, что это не то же самое, что поле readonly или пара методов (независимо от того, что говорит IL), поэтому я думаю, что я пойду с стереотип, но я соглашусь с независимым языком get_ set_ как общим решением. Спасибо всем за тест на здравомыслие.
Свойства - это просто удобный способ записи get_MyValue() и set_MyValue(value), позволяющий назначать, а не вызов нормального метода (используя скобки).
То, к чему вы обращаетесь, на самом деле является свойством .NET, С# имеет свой собственный синтаксис для доступа к ним. Поскольку под кожей создаются реальные методы get_ и set_, поэтому вы можете просто показать эти методы (чтобы сделать ваш язык UML независимым - например, сделать ваш UML одинаково применимым к разработчику VB.NET)
... или, как вы предложили, введите свой собственный стереотип!
Я обычно готовлю свои UML-диаграммы в Visio (знаю, я знаю, но что вы собираетесь делать?).
При построении диаграммных свойств они заканчиваются так:
+------------------------+
| MyClass |
|------------------------|
| - _foo : int |
|------------------------|
| «property» + Foo : int |
+------------------------+
"свойство" является обычным стереотипом, полученным из "оператора".
Уродливо, я знаю. Но это работает, и это понятно. Я также создаю конструкторы.
Вы можете представлять свойства так же, как поля. Чтобы указать дополнительную информацию, такую как readonly или writeonly, вы можете использовать
+ Имя: строка {READONLY}
свойства - это методы Get/Set, завершенные в некотором более сильном синтаксисе. Просто поместите их как методы или создайте для них новый синтаксис UML:)
Я бы поместил их как публичные поля в UML, потому что это то, что они концептуально. UML не является синтаксисом для вашего языка программирования (хотя некоторые поставщики инструмента утверждают, что это так).
Подробности о том, как ваш язык реализации обрабатывает свойства, не нужно показывать в UML. Это полностью превзойдет смысл использования UML в качестве инструмента, который абстрагирует детали реализации и позволяет сосредоточиться на дизайне.
Если свойство какое-то особенное, так что оно выводится или доступно только для чтения, вы можете отметить это с помощью аннотации стереотипа.
Eh, я просто бросаю его как метод в своих псевдо-UML-диаграммах.: -)
Проблема с изображением свойства как отдельного поля заключается в том, что для С# с использованием фреймворка 2.0 и за пределами get и set могут быть разные модификаторы доступа.
Я согласен с workmad3. Свойства - всего лишь трюк, которые делают методы get/set немного более приятными. По этой причине я думаю, что это нужно сохранить как два разных метода. Более того, в этом случае вы можете установить для них разные права доступа
Я использовал стереотипы <<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 должна отражать этот факт и в то же время сообщать то, что является общедоступным, а также частным, а также существует ли сеттер или нет.
Я так использую
-memberThePropertyWillExpose
+memberThePropertyIsExposing
Хорошо, комментарии к этому приветствуются, если это правильный путь!
В Visio вы можете создать < <readonly → > стереотип для атрибута и просто используйте этот стереотип для каждого атрибута только для чтения. То же самое для записи только. Он покажет вам хорошую нотацию:
<<readonly>> +PropertyName : int
В этом нет ничего уродливого. Стандартный параметр Visio Changeable гораздо более уродливый, поскольку он не имеет никакого визуального представления, и вам действительно нужно открывать свойства для каждого атрибута, чтобы увидеть его, нет шансов увидеть его на напечатанной диаграмме.
Вы можете использовать стереотип под названием "свойство" (например, < < Property → PropertyName) для поля в диаграмме классов. Стереотипы используются для расширения нотации UML.