Ассоциации + квалификаторы(Прочитано 24804 раз)
Господа, помогите, плиз, разобраться, что такое "Квалификатор" и с чем его "едят"?

Изучаю UML по книге "UML Bible @ Team DDU".

Сначала, вкратце бизнес сущности, на которых я пытаюсь освоить UML:
бизнес сущности хранятся в БД.
Таблица user - представляет игроков в некой футбольной игре, имеет записи Id, Nick,... представлена классом User.
Таблица team - представляет футбольную команду в этой игре, имеет записи Id, Name, UserId,... представлена классом Team
У одного игрока может быть либо 0 команд, либо одна, либо множество. У каждой команды владелец может быть либо один владелец (его идентификатор хранится в поле UserId), либо ни одного владельца (UserId=0).

Теперь - квалификаторы.
Насколько я понял, квалификатор применяют в тех случаях, когда некий объект, допустим объект user0 класса User, имеет необходимость получить объект team0 класса Team по некоторому идентификатору допустим RequiredId. В этом случае, подразумевается, что есть некая коллекция объектов, извлечённых из таблицы team и к ней выполняется запрос: найди мне объект с Id=RequiredId.
И при этом картинка UML-диаграммы классов должна иметь такой вид (сейчас попытаюсь прикрутить)

Но у меня возникает вопрос. На картинке показано, что объект user УЖЕ знает, что существует объект team... ??? т.е. фактически я имею только Id команды, но на UML-диаграмме должен нарисовать, что у меня уже есть этот объект team... верно?




Re: Ассоциации + квалификаторы Ответ #1 : 11 Июля 2008, 19:08:12
диаграмма в моём понимании приаттачена, поправьте, если я где-то ошибся.

Спасибо.

P.S. Прошу принять к сведению, что я новичок в UML, поэтому любые комменты - приветствутются.
« Последнее редактирование: 11 Июля 2008, 19:10:16 от Budda »



Re: Ассоциации + квалификаторы Ответ #2 : 14 Июля 2008, 10:06:24
Но у меня возникает вопрос. На картинке показано, что объект user УЖЕ знает, что существует объект team... ??? т.е. фактически я имею только Id команды, но на UML-диаграмме должен нарисовать, что у меня уже есть этот объект team... верно?
Вопрос не понял.


Исходя из описания задачи, я нарисовал бы следующее (Обе диаграммы эквивалентны друг другу, просто в одной используется квалификатор)


« Последнее редактирование: 14 Июля 2008, 10:11:12 от Denis »



Re: Ассоциации + квалификаторы Ответ #3 : 14 Июля 2008, 11:10:40
Денис, спасибо за ответ. Можете черкнуть как давно вы знакомы/работаете с UML? Дело в том, что ваши диаграммы вызывают больше вопросов, чем даёт ответов. Лично для меня... может просто потому, что я ещё слаб в этой области...

1. Почему "Owner" у вас написано рядом с изображением класса юзер? Или это "стереотип" использования связи, который говорит, что в этой связи User выступает владельцем для Team. да?
2. Из нижней диаграммы не видно того факта, что у User'а может быть несколько Team'ов. Может на правой части нижней связи нижней диаграммы нужно показать "0..*"?
3. Смысл верхней ассоциации на обоих диаграммах для меня вообще непонятен. И при том, что эти ассоциации ещё и отличаются принципиальным образом. На верхней диаграмме возле Team указано "*", тогда как на нижней - "0..1".
4. Что такое "Player" в контексте ваших диаграмм?
5. Что такое квалификатор "Id", как его нужно читать?



Re: Ассоциации + квалификаторы Ответ #4 : 14 Июля 2008, 12:27:23
Можете черкнуть как давно вы знакомы/работаете с UML?
Давно. Я провожу тренинги по UML.


1. Почему "Owner" у вас написано рядом с изображением класса юзер? Или это "стереотип" использования связи, который говорит, что в этой связи User выступает владельцем для Team. да?

Owner - это роль. Как и Player. Из условия задачи видно, что User может быть по отношению к команде как игроком (player), так и владельцем (owner)

2. Из нижней диаграммы не видно того факта, что у User'а может быть несколько Team'ов. Может на правой части нижней связи нижней диаграммы нужно показать "0..*"?

На верхней диаграмме я нарисовал * у ассоциации с ролью Player. "*" = "0..*"
На нижней диаграмме квалификатор позволяет снизить кратность (для этого он и нужен!).
Тут я не прав и если у пользователя несколько команд, то надо действительно писать "*", а не "0..1", как я написал. Просто обычно id нужен для уникальной идентификации...


3. Смысл верхней ассоциации на обоих диаграммах для меня вообще непонятен. И при том, что эти ассоциации ещё и отличаются принципиальным образом. На верхней диаграмме возле Team указано "*", тогда как на нижней - "0..1".

см. ответ на 1. Две ассоциации - так как две роли.
По поводу кратности на нижней диаграмме. Квалификатор нужен, чтобы показать, что существует способ снизить эту кратность.

4. Что такое "Player" в контексте ваших диаграмм?
Роль, которую ты описал в задаче (игрок).

5. Что такое квалификатор "Id", как его нужно читать?
Это значит, что в классе, на другом конце ассоциации (team) есть поле id, зная значение которого можно снизить кратность на полюсе ассоциации.



Re: Ассоциации + квалификаторы Ответ #5 : 14 Июля 2008, 13:17:11
А. Квалификатор применяется для того чтобы показать что у нас есть один экземпляр нашей ассоциации м\у объектами. Более подробно см. http://www.xpdian.biz/UML2changes.html

Б. Диаграмма объектов применяется, чтобы показать конкретное состояние объекта некоторого класса. Т.е. есть конкретный Юзер - Вася и он является либо владельцем, либо игроком команды. Поэтому надо сначала правильно нарисовать Диаграмму Классов, а потом уже нарисовать конкретное состояние Объектов, скорее всего двумя Диаграммами Объектов (либо владелец, либо игрок) с квалификаторами.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Ассоциации + квалификаторы Ответ #6 : 14 Июля 2008, 13:42:29
Денис, спасибо за помощь. Продолжим? :)

Цитировать
Цитировать
1. Почему "Owner" у вас написано рядом с изображением класса юзер? Или это "стереотип" использования связи, который говорит, что в этой связи User выступает владельцем для Team. да?
Owner - это роль. Как и Player. Из условия задачи видно, что User может быть по отношению к команде как игроком (player), так и владельцем (owner)
Наверное, я плохо описал задачу. User - это владелец и игрок в одном лице. нет отдельной роли "игрок". Если он владелец, то он и игрок. Кроме того, не стоит задача поиска команды по её ИД. Т.е. ваша ассоциация, наверное, не нужна.

пункты 2-4 - вроде прояснились, как я понимаю, ввиду того, что роли Player - реально нет, то верхнюю ассоциаци можно бы и убрать. Да?

Цитировать
Цитировать
5. Что такое квалификатор "Id", как его нужно читать?
Это значит, что в классе, на другом конце ассоциации (team) есть поле id, зная значение которого можно снизить кратность на полюсе ассоциации.
:) надо осмыслить... :)
в той книге, что я читаю, перед полем (Id) ставиться имя класса, потом точка, а уже потом имя поля, т.е. так: Team.Id - получается вроде немного понятнее, чем просто Id... а смысл по идее тот же самый.
Но в любом случае, это обозначение (квалификатор) означает, что на другом конце ассоциации есть соответствующее поле, по которому можно найти соответствующий объект. да?
Но где хранится значение "поля Id" на "этом" конце ассоциации, т.е. внутри объекта класса User? Как с точки зрения программиста читать диаграмму, чтобы реализовать классы User и Team?

Давайте ещё раз:
А.
А.1. Нижняя ассоциация на ваших диаграммах показывает связь команды и её владельца по полю UserId, которое хранится в экземплярах класса Team. Верно?
А.2. В правой части ассоциации можно было бы поставить "1", но по умолчанию 1 можно и не ставить, так?
А.3. В левой, как у вас и стоит "0..1" - так и остаётся.
А.4. По идее, для этой ассоциации тоже можно создать квалификатор Team.UserId (или просто UserId) и отобразить его со стороны класса User?
А.5. Мне кажется, что здесь неплохо было бы использовать DirectedAssociation (стрелочка в сторону класса User)?
А.6. Данная ассоциация представляет, что User является владельцем Team, т.о. можно обозвать левый краяй ассоциации как "Owner", верно?
(на моём новом рисунке данная ассоциация показана снизу).

Б.
Выше (в п.А) мы описали, каким образом класс Team ссылается на класс User. А теперь, наверное, стоит описать и тот факт, что класс User может иметь метод, который возвращает список объектов класса Team, верно? С точки зрения программной реализации задачи, такой метод должен быть.
Б.1. Я так думаю, что чем нагружать уже существующую ассоциацию, то лучше ввести новую, верно? Если нет, то почему и как тогда надо предстваить ассоциацию?
Б.2. Как отобразить ассоциацию, если есть необходимость показать разработчику, что такой метод должен быть членом класса User, а его реализация метода предполагает обращение к статическому метода GetTeamsByUser(User user) класса Team, который содержит все объекты своего типа в некотором статическом контейнере и при обращении отбирает те элементы, которые удовлетворяют некоему условию (в данном случае team.UserId=user.Id)
list<Team> User::GetUserTeams(){ return Team.GetTeamsByUser(user); }В этом случае, я так думаю, необходимо также указать DirectAssociation (стрелка направлена к классу Team) с обозначением "0..*" со стороны класса Team. Верно?
Б.3. Нужно ли для этой ассоциации указывать квалификатор, т.е. обозначить, что поиск объектов класса Team будет (должен) происходить по полю UserId?

Б.4. А что, если необходимо "заказать" разработчику такую реализацию метода User.GetUserTeams, реализация которой предполагает обращение к мапперу объектов на получение списка объектов. Как я понимаю, в этом случае на диаграмме надо будет отобразить класс (а может даже экземпляр) маппера, и указать связь класса User с данным маппером, и маппера с классом Team, да?

В. Я думаю, что имея две описанных ассоциации, именно та, что описана в п.п. "А" отображает суть "владелец", т.е. у класса Team существует поле UserId, которое обозначает владельца, поэтому именно эту ассоциацию нужно обозначать ролью "Owner", верно?

На картинке показано моё видение диаграммы без использования п. "Б.4"



Re: Ассоциации + квалификаторы Ответ #7 : 14 Июля 2008, 13:43:35
А. Квалификатор применяется для того чтобы показать что у нас есть один экземпляр нашей ассоциации м\у объектами. Более подробно см. http://www.xpdian.biz/UML2changes.html
Не верно.
Во-первых по ссылке ни о каких квалификаторах (qualifier) речи нет.
Там показаны именованные коннекторы.
Во-вторых, квалификаторы применяются для снижения кратности на полюсе ассоциации.

Б. Диаграмма объектов применяется, чтобы показать конкретное состояние объекта некоторого класса. Т.е. есть конкретный Юзер - Вася и он является либо владельцем, либо игроком команды. Поэтому надо сначала правильно нарисовать Диаграмму Классов, а потом уже нарисовать конкретное состояние Объектов, скорее всего двумя Диаграммами Объектов (либо владелец, либо игрок) с квалификаторами.

Диаграмма объектов НЕ применяется, чтобы показать конкретное состояние объекта некоторого класса.
Состояние показывается на диаграмме автоматов (терминология UML2).

>Т.е. есть конкретный Юзер - Вася и он является либо владельцем, либо игроком команды.
В постановки задачи не сказано либо-либо.

>Поэтому надо сначала правильно нарисовать Диаграмму Классов, а потом уже нарисовать конкретное состояние Объектов, скорее всего двумя Диаграммами Объектов (либо владелец, либо игрок) с квалификаторами.

Еще раз. Квалификаторы НЕ используются на диаграмме объектов.

Квалификаторы применяются на диаграммах классов, а не на диаграммах объектов. Диаграмма объектов служит другим целям.



Re: Ассоциации + квалификаторы Ответ #8 : 14 Июля 2008, 13:45:30
Bas, спасибо за помощь, вашу ссылку обязательно посмотрю.

А пока: по поводу диаграммы объектов.
Цитировать
Диаграмма объектов применяется, чтобы показать конкретное состояние объекта некоторого класса. Т.е. есть конкретный Юзер - Вася и он является либо владельцем, либо игроком команды. Поэтому надо сначала правильно нарисовать Диаграмму Классов, а потом уже нарисовать конкретное состояние Объектов, скорее всего двумя Диаграммами Объектов (либо владелец, либо игрок) с квалификаторами.
Я же не строю диаграмму объектов. И как я только что описал, юзер - это и владелец, и, в тоже время, игрок. Вот как раз я и работаю над правильной прорисовкой диаграммы классов.



Re: Ассоциации + квалификаторы Ответ #9 : 14 Июля 2008, 13:55:53
Цитировать
Б.2. Как отобразить ассоциацию, если есть необходимость показать разработчику, что такой метод должен быть членом класса User, а его реализация метода предполагает обращение к статическому метода GetTeamsByUser(User user) класса Team, который содержит все объекты своего типа в некотором статическом контейнере и при обращении отбирает те элементы, которые удовлетворяют некоему условию (в данном случае team.UserId=user.Id)

Код:
list<Team> User::GetUserTeams(){ return Team.GetTeamsByUser(user); }В этом случае, я так думаю, необходимо также указать DirectAssociation (стрелка направлена к классу Team) с обозначением "0..*" со стороны класса Team. Верно?
Б.3. Нужно ли для этой ассоциации указывать квалификатор, т.е. обозначить, что поиск объектов класса Team будет (должен) происходить по полю UserId?
Здесь, наверное, можно над ассоциацией написать имя используемого метода... ? Другого способа я не вижу... ведь внутри класса обычно МНОГО методов, и какой из них относится к конкретной ассоциации - не всегда очевидно, верно?



Re: Ассоциации + квалификаторы Ответ #10 : 14 Июля 2008, 14:11:12
Budda
>Наверное, я плохо описал задачу. User - это владелец и игрок в одном лице. нет отдельной роли "игрок". Если он владелец, то он и игрок. Кроме того, не стоит задача поиска команды по её ИД. Т.е. ваша ассоциация, наверное, не нужна.

Если роли "игрок" нет, но значит ассоциация не нужна.

>пункты 2-4 - вроде прояснились, как я понимаю, ввиду того, что роли Player - реально нет, то верхнюю ассоциаци можно бы и убрать. Да?

В общем да, но тебе надо решить, как ты покажешь, что
"У одного игрока может быть либо 0 команд, либо одна, либо множество."
Или здесь "игрок" = "владелец"? Если так - добавь кратность на полюс Team

>5. Что такое квалификатор "Id", как его нужно читать?
>Это значит, что в классе, на другом конце ассоциации (team) есть поле id, зная значение которого можно снизить кратность на полюсе ассоциации.

Да

>Улыбающийся надо осмыслить... Улыбающийся
>в той книге, что я читаю, перед полем (Id) ставиться имя класса, потом точка, а уже потом имя поля, т.е. так: Team.Id - получается вроде немного
>понятнее, чем просто Id... а смысл по идее тот же самый.
Тот же самый. Пиши как нравится

>Но в любом случае, это обозначение (квалификатор) означает, что на другом конце ассоциации есть соответствующее поле, по которому можно найти соответствующий объект. да?
Найти один объект, несколько объектов или не найти ничего

>Но где хранится значение "поля Id" на "этом" конце ассоциации, т.е. внутри объекта класса User?
Нигде не хранится.
Смотри, ассоциация между user и team подразумевает, что user знает про team и наоборот.
Если тебе не нравится, что team знает про user, то нарисуй стрелку на конце ассоциации, показав тем самым направление возможной навигации.
Реализовывается ассоциация например с помощью ссылок или указателей. Т.е. в твоем случае в классе User будет член класса - например, map объектов типа team.
О чем, говорит квалификатор? что если у тебя имеется Объект типа user (а в нем естественно заполненный массив с team), то зная ключ (квалификатор), ты быстро найдешь или не найдешь нужную тебе команду (команды).
Ключ при этом НЕ хранится в User. Он  приходит извне.

>Как с точки зрения программиста читать диаграмму, чтобы реализовать классы User и Team?
см. выше. Но вообще ты занимаешься проектированием, а не реализацией.
Обычно программисту одной статики (диаграммы классов) мало. Нужна динамика. Например, диаграммы последовательности, на которых ты опишешь основные варианты использования данных классов. МОжешь представить их в виде коопераций, если захочется.






Re: Ассоциации + квалификаторы Ответ #11 : 14 Июля 2008, 14:33:18
>А.1. Нижняя ассоциация на ваших диаграммах показывает связь команды и её владельца по полю UserId, которое хранится в экземплярах класса Team. Верно?

Нижняя ассоциация отображает требование
"У каждой команды владелец может быть либо один владелец (его идентификатор хранится в поле UserId), либо ни одного владельца (UserId=0)."


>А.2. В правой части ассоциации можно было бы поставить "1", но по умолчанию 1 можно и не ставить, так?

Нет не так. Не существует кратности by default. Если ничего не стоит, то значит ничего не известно и никаких выводов (например, подразумевается 1) сделать нельзя.

>А.3. В левой, как у вас и стоит "0..1" - так и остаётся.
>А.4. По идее, для этой ассоциации тоже можно создать квалификатор Team.UserId (или просто UserId) и отобразить его со стороны класса User?
С одной стороны - Да, но назвать его надо User.id и положить на сторону team.
У тебя есть значенние ключа (team.id), но он используется, чтобы снизить кратность на полюсе User (через поле user.id)
Но с другой стороны, ты же в условиях задачи уже указал кратность и понижать ее некуда.

>А.5. Мне кажется, что здесь неплохо было бы использовать DirectedAssociation (стрелочка в сторону класса User)?
Можно. Но лучше от стрелочек воздержаться (общая практика).

>А.6. Данная ассоциация представляет, что User является владельцем Team, т.о. можно обозвать левый краяй ассоциации как "Owner", верно?
(на моём новом рисунке данная ассоциация показана снизу).

Как и было на моем рисунке... Но если ассоциация одна, то роли редко пишут. Обычно это ясно.

>Б.
>Выше (в п.А) мы описали, каким образом класс Team ссылается на класс User. А теперь, наверное, стоит описать и тот факт, что класс User может иметь метод, который возвращает список объектов класса Team, верно? С точки зрения программной реализации задачи, такой метод должен быть.

Зависит от многих вещей, но предположим...

>Б.1. Я так думаю, что чем нагружать уже существующую ассоциацию, то лучше ввести новую, верно? Если нет, то почему и как тогда надо предстваить ассоциацию?
>Б.2. Как отобразить ассоциацию, если есть необходимость показать разработчику, что такой метод должен быть членом класса User, а его реализация метода предполагает обращение к статическому метода GetTeamsByUser(User user) класса Team, который содержит все объекты своего типа в некотором статическом контейнере и при обращении отбирает те элементы, которые удовлетворяют некоему условию (в данном случае team.UserId=user.Id)

Тут начинается путаница... Ассоциация просто описывает знание одного класса о наличии другого и все. Не надо связывать ассоциации с конкретными методами. Ассоциация показывает что в run-time один объект может вызвать методы другого вот и все.

Диаграмма классов описывает статику, а не динамику, которую ты уже стараешься пропихнуть.

Предлагаю тебе исходя из всего написанного еще раз сформулировать задачу, чтобы не было неточностей. А потом поговорим...



Re: Ассоциации + квалификаторы Ответ #12 : 14 Июля 2008, 14:39:10
>> О чем, говорит квалификатор? что если у тебя имеется Объект типа user (а в нем естественно заполненный массив с team), то зная ключ (квалификатор), ты быстро найдешь или не найдешь нужную тебе команду (команды).
Ключ при этом НЕ хранится в User. Он  приходит извне.

По сути это и есть ответ на мой вопрос... спасибо.

>> вообще ты занимаешься проектированием, а не реализацией.
Обычно программисту одной статики (диаграммы классов) мало. Нужна динамика. Например, диаграммы последовательности, на которых ты опишешь основные варианты использования данных классов. МОжешь представить их в виде коопераций, если захочется.
Вообще - я программист, которому в ближайшем будущем придётся играть роль архитектора, поставлена задача изучить УМЛ... вот и изучаю. При этом я хочу писать те же диаграммы классов максимально информативно...

Вот, к примеру, в моём "старом" проекте реализовано кеширование объектов. при этом формирование списков объектов и самих объектов происходит довольно быстро, но хранить списки после использования - нельзя...
Т.о. возникает задача показать на диаграмме классов, что список объектов держать членом класса -нельзя. Это можно сделать в виде отдельного комментария на диаграмме, а можно как-то более конкретно?

>> Если тебе не нравится, что team знает про user, то нарисуй стрелку на конце ассоциации, показав тем самым направление возможной навигации
Ну у меня как раз наоборот, team должен знать про user, но вот user - может получить список team'ов лишь отдельным запросом "куда-то"...

>> Реализовывается ассоциация например с помощью ссылок или указателей.
Да, по ссылки/указатели я знаю.

вобщем, спасибо ещё раз.



Re: Ассоциации + квалификаторы Ответ #13 : 14 Июля 2008, 14:47:28
>> Тут начинается путаница... Ассоциация просто описывает знание одного класса о наличии другого и все
Т.е. не важно, кто и каким образом на кого-то ссылается. Мне, как архитектору, надо отобразить лишь наличие это ассоциации и её тип, да? А программист, посмотрит статику, динамику и решит как делать. Если есть какие-то факторы, на какие надо обратить его внимание (кеширование в моей реализации), то об этом надо сообщить отдельно.

>> Тут начинается путаница... Ассоциация просто описывает знание одного класса о наличии другого и все. Не надо связывать ассоциации с конкретными методами. Ассоциация показывает что в run-time один объект может вызвать методы другого вот и все.
>> Диаграмма классов описывает статику, а не динамику, которую ты уже стараешься пропихнуть.

аа.... вот оно что... в приципе, логично.

>> Предлагаю тебе исходя из всего написанного еще раз сформулировать задачу, чтобы не было неточностей. А потом поговорим...

нет необходимости. Задача - это я себе придумал пример, чтобы было конкретнее. С квалификаторами - вроде стало понятно... (ключ по которому искать нужные объекты в списке). В вот динамика
Наверное архитектору и не стоит вникать в детали реализации. верно? Надо делать свою задачу, а девелоперы уже будут делать свою?




Re: Ассоциации + квалификаторы Ответ #14 : 14 Июля 2008, 14:56:43
Вот, к примеру, в моём "старом" проекте реализовано кеширование объектов. при этом формирование списков объектов и самих объектов происходит довольно быстро, но хранить списки после использования - нельзя...
Т.о. возникает задача показать на диаграмме классов, что список объектов держать членом класса -нельзя. Это можно сделать в виде отдельного комментария на диаграмме, а можно как-то более конкретно?

Это нефункциональное требование - только комментарий




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19