Представляя свойство аксессора C # в диаграмме классов UML?

Question

Как представить свойство C # (методы доступа для методов установки и получения) в диаграмме классов UML?

Вы просто пишете это как обычные методы установки и получения?

Или есть какой-то другой способ представить это?

Меня интересует, как средства доступа представлены в классе и интерфейсе на диаграмме классов UML.

Answer 1

Некоторые разработчики / аналитики:

(1) показывают свойства как очень концептуальную вещь и показывают только одну строку для каждого свойства.

(2) Другие, более конкретные, отображают 3 строки, свойство, функцию «getter», функцию «setter».

(3) И иногда, только показывают 2, для аксессоров.

(4) Некоторые приложения для рисования UML.позволяет выбрать, какой из предыдущих пунктов вы хотите отобразить.

И ...

... Насколько я исследовал, все варианты верны.Помните, что стереотипы ("<> ", разрешено помогать документировать класс.

(Примечание: я заменяю пробелы точками)

(1) Только простое свойство (C #, очень концептуально):

+================================================================+
|..........................MyClass...............................|
+----------------------------------------------------------------+
|..[+]..|..void....|..MyClass()...|..<<constructor>>.............|
|..[+]..|..void....|..~MyClass()..|..<<destructor>>..............|
+================================================================+
|..[+]..|..string..|..Text........|..<<property>>................|
+================================================================+

(2) Только «аксессоры», (C ++, Java, стиль):

+================================================================+
|..........................MyClass...............................|
+----------------------------------------------------------------+
|..[+]..|..void....|..MyClass()...|..<<constructor>>.............|
|..[+]..|..void....|..~MyClass()..|..<<destructor>>..............|
+================================================================+
|..[#]..|..string..|..FText.......|..<<field>>...................|
+================================================================+
|..[+]..|..string..|..getText()...|..<<function>>,..<<getter>>...|
+----------------------------------------------------------------+
|..[+]..|..string..|..setText()...|..<<procedure>>,..<<setter>>..|
+================================================================+

(2) Все (очень программист, стиль Object Pascal / Delphi):

+================================================================+
|..........................MyClass...............................|
+----------------------------------------------------------------+
|..[+]..|..void....|..MyClass()...|..<<constructor>>.............|
|..[+]..|..void....|..~MyClass()..|..<<destructor>>..............|
+================================================================+
|..[#]..|..string..|..FText.......|..<<field>>...................|
+================================================================+
|..[+]..|..string..|..Text........|..<<property>>................|
+----------------------------------------------------------------+
|..[+]..|..string..|..getText()...|..<<function>>,..<<getter>>...|
+----------------------------------------------------------------+
|..[+]..|..string..|..setText()...|..<<procedure>>,..<<setter>>..|
+================================================================+

Доставляете ли вы аналитикам? Знают ли ваши программисты на C ++ / Java, что если на диаграмме показаны только свойства, они должны кодировать аксессоры, или ваша компания требует, чтобы их объявили на диаграммах подробно?тот, который больше соответствует вашим потребностям. (удалить точки).

Answer 2

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

Извините, я понимаю, что это не совсем прямой ответ на ваш вопрос, но, тем не менее, это хорошая практика.

Answer 3

Должен быть установлен как атрибут.Если он имеет только геттер, установите его только для чтения.Не существует определенного UML для свойств C #.