UML-ассоциация по сравнению с составом и уровнем детализации

Собственно, сделайте это несколько любительских вопросов UML! При создании диаграммы UML для моделирования некоторых концепций домена вы сталкиваетесь с концепцией домена, которая "хранит" некоторую информацию о другой концепции, лучше ли хранить штамп/ссылку на этот объект или удерживать весь объект в самой модели? Пожалуйста, имейте в виду, что это связано с созданием простой модели высокого уровня - я уверен, что на этапе реализации все будет немного отличаться.

Например, какая из двух моделей ниже на самом деле правильная? Первый имеет составные отношения, при этом FlightBooking держит весь Flight. Во втором, FlightBooking просто имеет ссылку на Flight.

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

Кроме того, еще одна вещь, при моделировании выше, где Flight "удерживает" начало/назначение как другой класс, а не строку, какой из двух способов является правильным способом моделирования этого? Я довольно смущен, когда показываю ассимиляцию и когда показываю композицию.

Ответ 1

Ассоциация:
Это означает, что у двух классов есть какие-то отношения, может быть что-то действительно. Например: A использует B, A связан с B определенным образом.

Состав:
Это также особый тип ассоциации, используемой для моделирования "Собственность". Это очень похоже на агрегирование с той лишь разницей, что на нем изображено отношение цельной части, а сущность "part" не имеет собственного независимого существования.

Например: A состоит из B; B является частью A и, следовательно, не может существовать без A.

Хорошее объяснение: Диаграмма классов UML: Ассоциация, агрегирование и состав

Ответ 2

Извините, если это немного длиннее...

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

Почему существует связь? В частности, какие области правил/ограничений он захватывает?
Какая мощность с обоих концов?
Что такое поведение create и delete? то есть кто создает/удаляет экземпляры ассоциации?

Именование отношений. Вы выполняете (1), именовав конец rel. Не с именами ролей (например, "Полеты" в первом примере), потому что это ничего не говорит о том, почему отношения существуют. Итак, в вашем примере 1: что представляют собой отношения? Это зарезервированное место в полете? Подтвержденный? Заплачено за? Невозможно рассказать по диаграмме в ее нынешнем виде. Существуют различные подходы к именованию на основе глаголов, см., Например, этот пост. Зачем это делать? Потому что он предлагает вам убедиться, что вы понимаете домен. В отношениях существует большой процент (вероятно, большинство, хотя я и не доказал этого) правил домена. Поэтому понимание того, почему существуют отношения, имеет фундаментальное значение для понимания домена.

Мощность > Вероятнее всего, более очевидна, чем именование. Вы должны определить на обоих концах - как верхний, так и нижний. Важно, чтобы нижний конец был ли он опциональным (то есть 0 или 1). На верхнем конце - 1 или много. Опять же, это накладывает важные правила из области. Вернемся к вашему примеру еще раз: сколько рейсов в рейсе? Может ли один рейс быть в нескольких заказах? (что бы ни было "в" означает...).

Создать/Удалить поведение Кто создает экземпляры отношений? Кто удаляет? Если один конец удаляется, что происходит с другим концом? Опять же, все важные правила из проблемной области.

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

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

Если мощность на одном конце отношения равна 1:1 (т.е. может быть только когда-либо), AND
тот же конец отвечает за создание и удаление экземпляров другого конца, THEN
Его можно показать как композицию.

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

НТН.

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

Ответ 3

Композиции, агрегации и ассоциации.

Перед другими вещами вы должны понимать, что такое ассоциация A-B.
- В принципе, это сплошная линия между A и B. Она может представлять одну структуру, которая соединяет класс /instanc (а) A с классом/экземплярами B. Структура может быть любого рода и принадлежать где угодно. Вся информация, написанная о строке, описывает эту структуру.
- Если есть две структуры, одна структура, которая соединяет один экземпляр A с экземпляром (-ами) B и другую структуру, которая соединяет экземпляр B с экземпляром (-ами) A, вы можете показать их как в ONE-ассоциации. Затем информация, написанная о ее конце B, описывает первую структуру (b- > a), а информация о другом конце описывает другую структуру.
- Если у вас будет более одной структуры, направляющей от A до B, вы должны нарисовать две разные ассоциации.
- Если структура соединения сложна, вы можете представить ее как класс ассоциации. Там вы можете определить более подробную информацию.
- Структура соединения может связывать более двух классов, тогда она будет показана как большой алмаз с твердыми ветвями к этим классам. Это все еще ассоциация! Внимание: эти две более сложные ассоциации очень плохо поддерживаются существующими инструментами. Вы можете легко создать с ними нечто совершенно бессмысленное. И они сложны. Используйте осторожно.
В экземпляре С++ A может иметь экземпляр B не по указателю, а непосредственно. Для него нет специального знака UML, он должен отображаться так же, как и обычный атрибут указателя.

Состав показан тем, что называется черным или полным алмазом. Он находится на стороне контейнера .
Другой, пустой алмаз, называется "общей агрегацией" или, в скором времени, "общим". Это не строго определено, и вы можете использовать его, создавая свой собственный стандарт. Разумеется, было бы глупо поместить его в пункт обмена предметов и контейнеров. Но это легко могло быть на обоих концах ассоциации.
- Почему состав алмаза может быть только с одной стороны? Поскольку композиция означает, что элементы существуют ТОЛЬКО, хотя существуют ссылки на них из контейнера (или самого контейнера). Конечно, это не могло работать для обеих сторон.
- Напротив, "общий" с обеих сторон часто имеет смысл. Например, экземпляры Student могут иметь список всех участвующих курсов, а экземпляр Courses может иметь список всех участвующих студентов.
Часто вы можете увидеть имя "агрегация", используемое для "общей агрегации". Это ошибка. Поскольку, согласно стандарту, composition, shared и даже none, все три являются агрегатами.

Итак, composition is a subset of aggregation и aggregation является признаком association

Ответ 4

В вашем первом примере первая диаграмма с композицией верна. Второй вариант, относящийся к flightID как int, мог бы работать, но он был неполным: этот int сам по себе не дает вам доступа к объекту Flight. Класс полета не волшебным образом хранит список объектов полета, которые вы можете получить по номеру, так что второй вариант должен был где-то в третьем классе хранить все объекты полета.

Для вашего второго вопроса, на высоком уровне это действительно зависит от личных предпочтений (или вашего личного предпочтения вашего профессора!). Просто постарайтесь использовать свое лучшее решение.