Относительно 1 к 1 ассоциациям в моделях классов UML

Question

Мы часто сталкиваемся с моделями классов в UML-моделировании, которые устанавливают связь 1 x 1 или 1 x 1 .. * или 1 .. * x 1 или 1 .. * x 1 .. * между данными классами.

Возьмем пример: игрок 1..11 x 1 команда.

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

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

Как возможны ассоциации 1 x 1?

Спасибо за потраченное время!

Answer 1

Зависит от того, что это за модель.Модель UML может быть моделью реального мира, например, человеческая рука имеет отношение 1: 1 к человеческой руке.Эта ассоциация 1: 1 моделирует биологический факт (игнорируя инвалидность).

Модель UML также может быть моделью функциональности приложения.Если приложение обеспечивает, чтобы в каждой команде было по 11 игроков, и у каждого игрока была одна команда (например, все они были созданы сразу, заполнив форму кнопкой «Сохранить»), то ассоциация 1: 11 правильно моделирует функциональностьприложение.

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

Примечание: при моделировании команд иигроков, вы можете рассмотреть связь между Командой и Персоном с множественностью 0 .. * и именем роли «игрок» на стороне Команды.

Answer 2

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

Answer 3

Ваш вопрос "Как возможно 1 х 1 объединение?"относится к вопросу обязательных взаимно обратных ссылок , или, на жаргоне СУБД, циклических внешних ключей , которые действительно могут создать объект/ проблема создания или обновления строки в приложении для управления данными или в его базовой базе данных (БД).

Существует два подхода к решению этой проблемы: 1) ослабить обязательное ограничение ссылок по крайней мере в одном направлении, 2)Разрешить промежуточные состояния приложения / БД, которые не должны удовлетворять ограничению.

1) Хотя мы знаем, что в действительности в команду всегда входит больше, чем ноль игроков, мы можем решить не применять это ограничение по прагматическим причинам, так что мы можем легче создать объект данных команды (или строку БД)) без немедленного присвоения объектам / строкам игрока.

2) В нашем приложении мы можем разрешить промежуточное состояние, когда команда была создана без назначенных ей игроков, и, соответственно, в базовой БД мыможет проинструктировать менеджера транзакций, что ограничение внешнего ключа проверяется только тогда, когда вся транзакция (состоящая из сначала создания пустой команды, затем создания 11 игроков, так что каждый из них назначается команде, а команда назначается им как ихкоманда) завершена.Это может быть достигнуто с помощью предложения SQL DEFERRABLE INITIALLY DEFERRED, см. Раздел Циклические внешние ключи поста "Отложенные ограничения SQL в глубине".

Answer 4

Когда для модели в виде отношения 1..11 (Team - Player) не существует «что на первом месте».Должно быть 11 Player с, и они могут быть подключены к одному Team.Только когда все соединения установлены, у вас есть соответствующая модель.Вы можете указать, что игроки формируют команду, добавляя состав.Но обычно с точки зрения программирования это не добавляет много семантики.В любом случае вам необходимо иметь экземпляры для создания соединений.Таким образом, Team, скорее всего, будет иметь массив 11 Player с, и для того, чтобы он работал, ни один из них не должен быть Null.

То же самое относится и к отношениям 1..1 (plug / socket).Только когда они связаны, у вас есть соответствующая модель.С точки зрения моделирования 1..1 часто используется, если вам нужен рюкзак для одного из двух классов.Затем вы связываете другую с отдельной информацией.Затем его можно использовать вместе с другими классами, которые заинтересованы только в этом содержимом, а не самим носителем.