Последствия неверной диагностики / ложного определения типов отношений на диаграмме классов

Question

Я читал много документов об отношениях на диаграмме классов, но я все еще сомневаюсь в некоторых отношениях.

1. Мой первый вопрос - определить тип ниже отношения:

as you could see in the above image I have NetworkAgent class which includes NetworkUDPReceiver for listening and receiving and NetworkUDPSender for sending packets.

I know Aggregation is a whole-part structure as parts could be shareable and Association used when a class has a reference to another class as a member in the non-whole-part structure.

in the above example, I see a whole-part structure and shareable parts. does my opinion is right? do you see Aggregation?

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

Например, если правильный ответ - «Ассоциация», что произойдет или каковы будут последствия, если я неправильно выберу «Агрегирование»? (и наоборот)

обновить вопрос : Бруно правильно сообщает мне, что положение знака агрегации <> на приведенном выше изображении неверно и должно быть перевернуто.

Answer 1

Эта диаграмма вводит в заблуждение

К счастью, NetworkAgent имеет встроенную подсказку, которая помогает нам разобраться: два свойства, receiverAgent и senderAgent, которые имеют тип NetworkUDPReceiver и * 1007. * соответственно:

• Это эквивалентно наличию двух ассоциаций, одной с классом NetworkUDPReceiver с именем receiverAgent на его стороне и одной с NetworkUDPSender с имя senderAgent на его стороне.
• Чтобы быть более точным, это должно быть представлено пунктирным концом на стороне получателя и отправителя.
• Поскольку такая конструкция, очевидно, позволяет легко переходите от агента к отправителю или получателю, вы можете показать возможность навигации с помощью стрелки на стороне отправителя и получателя.
• Предполагая, что другие классы представлены по тем же логам c , мы можем считать, что нет удобного перехода к агентству. Это может быть показано крестиком на стороне агента.

Таким образом, это почти полностью соответствует ассоциациям, которые вы обвели, за одним существенным исключением: агрегирование, которое неверно.

Вещь с агрегированием

Белый ромб действительно предназначен для описания отношения части-целого (с ромбиком на стороне целого). Но UML позволяет семантике открываться, и де-факто нет никаких преимуществ от ее использования, чем от обычной ассоциации. Итак, если вы составите диаграмму, лучший совет - избегать этого.

Более того, я бы попросил вас доказать, что существует взаимосвязь между агентом и отправителем / получателем: отправитель не является часть агента. Отправитель просто связан с агентом.

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

Заключение

Лучше всего убрать агрегацию с диаграммы. Если вы решите, что хотите использовать его для композиции объектов, переместите ромб на другую сторону.

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

Answer 2

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

нет, на диаграмме NetworkAgent агрегируется NetworkUDPReceiver и NetworkUDPSender , а не наоборот, потому что <> не находится на стороне NetworkAgent

что произойдет, если я выберу неправильную взаимосвязь?

если правильный ответ - «Ассоциация», что произойдет или каковы будут последствия, если я выберу неправильное объединение? (и наоборот)

в этом случае ваша модель неверна / сбивает с толку, но это, вероятно, ничего не меняет в отношении соответствующего кода Java, который не зависит от этого (в отличие от композиции, которая оказывает влияние в коде реализации)

Для меня, если у вас есть эти три класса, у вас есть композиции, а не агрегации, потому что все еще есть экземпляры NetworkUDPSender и NetworkUDPReceiver , когда соответствующие NetworkAgent экземпляр исчезает бессмысленно, поэтому NetworkAgent <*>-------NetworkUDPReceiver и NetworkAgent <*>-------NetworkUDPSender

Answer 3

Я знаю, что агрегирование представляет собой структуру целых частей

Ваша диаграмма показывает общую композицию (незаполненный ромб).

p. 110 из UML 2.5:

общий | Указывает, что свойство имеет общую семантику агрегирования. Точная семантика совместной агрегации зависит от области приложения и разработчика.

составной | Указывает, что Свойство агрегировано составно, т. Е. Составной объект несет ответственность за существование и хранение составных объектов (см. Определение частей в 11.2.3).

Итак, чтобы понять то, что разработчик UML-моделирования хотел express, вам нужно явно попросить его определить семантику совместной агрегации!