UML Классовые Отношения

Question

Я хотел бы подтвердить, нахожусь ли я на правильном пути при определении общих отношений класса UML. Например, это отношения между:

1 член stackoverflow и его / ее учетная запись пользователя stackoverflow, классифицированные как отношение композиции или отношение агрегации? Сначала я подумал, что это ассоциация, потому что у этого участника "есть" аккаунт. Однако, подумав над этим, я думаю о его составе, потому что каждая «часть» (учетная запись пользователя) принадлежит только одному целому (пользователю) за раз, то есть до тех пор, пока я вошел в stackoverflow, я должен использовать эту единственную аккаунт, пока я не выйду. Если я снова войду в stackoverflow с другой учетной записью, то снова создаю его. Вы согласны?

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

Наконец, кто-нибудь может порекомендовать сайт, который специализируется на разработке кода с использованием UML? Заранее спасибо

Answer 1

Член stackoverflow и его / ее учетная запись пользователя stackoverflow, классифицированные как отношение композиции или отношение агрегации?

Хорошо, давайте посмотрим на следующую диаграмму

• Aggregation

Возможна пересадка

Если я пропущу какой-нибудь палец, значит, другая рука может получить мой пропавший палец

---

• Состав

Пересадка невозможна

Если я пропущу какой-нибудь палец, значит, никакая другая рука не сможет получить мой пропавший палец

И Агрегация, и Композиция, A Finger (Часть) имеет свой жизненный цикл, привязанный к его собственному экземпляру Entity (если я скучаю по своей Руке, значит, его Палец будет отсутствовать). мой участник Stackoverflow, его учетная запись пользователя будет удалена.

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

Answer 2

Спецификация UML не согласуется с определениями агрегации и состава. Они не определены должным образом, как было показано несколькими авторами (Хендерсон-Селлерс среди других). Я предлагаю вам не тратить свое время, пытаясь определить, соответствует ли что-то в вашем уме лучшему или другому. Там нет правильного ответа. : -)

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

Даже если бы UML был последовательным, нет правильных или неправильных моделей; некоторые модели полезны, а некоторые нет. Вы создаете моделей в зависимости от цели, которую вы преследуете.

Answer 3

Лучшая книга для UML - «Util Distilled» Мартина Фаулера. Это в третьем издании, так что оно выдержало испытание временем. Он обладает редким достоинством: он упакован хорошей информацией и остается худым .

Это хорошее обсуждение агрегации против ассоциации.

У Мартина Фаулера также есть некоторые хорошие мысли о различных лагерях UML: MDA против «скетчей». Я твердо нахожусь в лагере рисовальщиков: не слишком зацикливайтесь на том, чтобы относиться к UML так, как если бы он создавал инженерные чертежи. Это устройство связи, не более того.

Answer 4

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

• Автомобиль "имеет" 4. Колеса (совокупность)

• Идентификационный номер автомобиля - это часть автомобиля (состав)

(пример мусора, но лучшее, что я мог вспомнить:)

Answer 5

Агрегация: слабая 'имеет'
Состав: сильный "имеет"

Answer 6

Эта дополнительная информация доступна только в UML, потому что вы, например, не можете увидеть разницу в коде Java между агрегацией и композицией. Поэтому я не согласен с тем, что агрегация по сравнению с составом не является блестящей идеей, поскольку эта информация важна для качества проекта !!