Совокупность должна быть "одна ко многим"?

Ответ 1

Хороший сайт для этого -

http://www.uml-diagrams.org/class-diagrams.html

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

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

Лично это соответствует моему пониманию, что UML очень интерпретируется.

Ответ 2

Две вещи:

• Разрешены ли общие агрегации? Согласно спецификации UML, да.
• Полезно ли это на практике? Вообще-то я бы сказал нет.

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

• Какова мощность?
• Что такое поведение create/delete?
• Почему существует связь? (т.е. какой бизнес-факт/правило является захватом отношений?

Все вышеизложенное может быть сделано с прямыми ассоциациями. Если ответ: (a) он один для многих, (б) "один" конец отвечает за создание/удаление конца "много" и (в), который вы действительно хотите, затем используйте ассоциацию Composite. Агрегация, однако, обычно не улучшает читаемость модели, она добавляет путаницу и умаляет возможность всплытия основных правил/требований домена.

НТН.

footnote: существует один сценарий, когда агрегирование имеет четко определенную семантику и может быть полезна. В частности, если у вас есть рекурсивная связь, Aggregation говорит, что результирующая структура объекта ациклична (т.е. DAG). Недостаток относительно мало людей понимают, что собственность - конечно, не эксперты бизнес-домена. Таким образом, вы, как правило, должны выделять в любом случае, например. в комментарии/ограничение.

Ответ 3

• Пусть заданы члены. Агрегация - это metaterm в стандарте UML, и означает BOTH-состав и общую агрегацию, просто называемую shared. Чаще он назван неправильно "агрегацией". Это ПЛОХО, а состав также является агрегацией. Как я понимаю, вы имеете в виду "общий".

• Опять же, если мы посмотрим на стандарты UML (посмотрите там документацию надстройки), мы найдем, что "Точная семантика общей агрегации зависит от области применения и модельера". Таким образом, любая стратегия, которую вы выбираете, приемлема. И вы даже можете использовать разную стратегию для разных проектов.

• Но совместная агрегация полезна и может использоваться с множественностями с обеих сторон, и даже пустой алмаз может быть с обеих сторон.

Связь в UML - это абстракция, которая может быть реализована на любом языке и любым способом, только реализация должна соответствовать диаграмме.

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

Каждый экземпляр Студента имеет список курсов, на которые он зарегистрирован, и каждый экземпляр курсов имеет список зарегистрированных студентов/участников.

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

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

• наша диаграмма становится более сложной и, следовательно, менее читаемой.
• мы подробно описываем элементарные вещи, которые любой кодер будет делать в любом случае в 99% случаев.
• мы ограничиваем свободу кодировщиков. И в 1% случаев им придется выбирать между тем, чтобы не следовать диаграмме, а не кодировать эффективно. Это просто не ваша работа.

Итак, делай, как хочешь. Запрещено только изменять стратегию в течение одного проекта и FORBID другим использовать свою единственную стратегию.