Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: Budda от 11 Июля 2008, 19:07:04
-
Господа, помогите, плиз, разобраться, что такое "Квалификатор" и с чем его "едят"?
Изучаю 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... верно?
-
диаграмма в моём понимании приаттачена, поправьте, если я где-то ошибся.
Спасибо.
P.S. Прошу принять к сведению, что я новичок в UML, поэтому любые комменты - приветствутются.
-
Но у меня возникает вопрос. На картинке показано, что объект user УЖЕ знает, что существует объект team... ??? т.е. фактически я имею только Id команды, но на UML-диаграмме должен нарисовать, что у меня уже есть этот объект team... верно?
Вопрос не понял.
Исходя из описания задачи, я нарисовал бы следующее (Обе диаграммы эквивалентны друг другу, просто в одной используется квалификатор)
-
Денис, спасибо за ответ. Можете черкнуть как давно вы знакомы/работаете с UML? Дело в том, что ваши диаграммы вызывают больше вопросов, чем даёт ответов. Лично для меня... может просто потому, что я ещё слаб в этой области...
1. Почему "Owner" у вас написано рядом с изображением класса юзер? Или это "стереотип" использования связи, который говорит, что в этой связи User выступает владельцем для Team. да?
2. Из нижней диаграммы не видно того факта, что у User'а может быть несколько Team'ов. Может на правой части нижней связи нижней диаграммы нужно показать "0..*"?
3. Смысл верхней ассоциации на обоих диаграммах для меня вообще непонятен. И при том, что эти ассоциации ещё и отличаются принципиальным образом. На верхней диаграмме возле Team указано "*", тогда как на нижней - "0..1".
4. Что такое "Player" в контексте ваших диаграмм?
5. Что такое квалификатор "Id", как его нужно читать?
-
Можете черкнуть как давно вы знакомы/работаете с 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, зная значение которого можно снизить кратность на полюсе ассоциации.
-
А. Квалификатор применяется для того чтобы показать что у нас есть один экземпляр нашей ассоциации м\у объектами. Более подробно см. http://www.xpdian.biz/UML2changes.html
Б. Диаграмма объектов применяется, чтобы показать конкретное состояние объекта некоторого класса. Т.е. есть конкретный Юзер - Вася и он является либо владельцем, либо игроком команды. Поэтому надо сначала правильно нарисовать Диаграмму Классов, а потом уже нарисовать конкретное состояние Объектов, скорее всего двумя Диаграммами Объектов (либо владелец, либо игрок) с квалификаторами.
-
Денис, спасибо за помощь. Продолжим? :)
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"
-
А. Квалификатор применяется для того чтобы показать что у нас есть один экземпляр нашей ассоциации м\у объектами. Более подробно см. http://www.xpdian.biz/UML2changes.html
Не верно.
Во-первых по ссылке ни о каких квалификаторах (qualifier) речи нет.
Там показаны именованные коннекторы.
Во-вторых, квалификаторы применяются для снижения кратности на полюсе ассоциации.
Б. Диаграмма объектов применяется, чтобы показать конкретное состояние объекта некоторого класса. Т.е. есть конкретный Юзер - Вася и он является либо владельцем, либо игроком команды. Поэтому надо сначала правильно нарисовать Диаграмму Классов, а потом уже нарисовать конкретное состояние Объектов, скорее всего двумя Диаграммами Объектов (либо владелец, либо игрок) с квалификаторами.
Диаграмма объектов НЕ применяется, чтобы показать конкретное состояние объекта некоторого класса.
Состояние показывается на диаграмме автоматов (терминология UML2).
>Т.е. есть конкретный Юзер - Вася и он является либо владельцем, либо игроком команды.
В постановки задачи не сказано либо-либо.
>Поэтому надо сначала правильно нарисовать Диаграмму Классов, а потом уже нарисовать конкретное состояние Объектов, скорее всего двумя Диаграммами Объектов (либо владелец, либо игрок) с квалификаторами.
Еще раз. Квалификаторы НЕ используются на диаграмме объектов.
Квалификаторы применяются на диаграммах классов, а не на диаграммах объектов. Диаграмма объектов служит другим целям.
-
Bas, спасибо за помощь, вашу ссылку обязательно посмотрю.
А пока: по поводу диаграммы объектов. Диаграмма объектов применяется, чтобы показать конкретное состояние объекта некоторого класса. Т.е. есть конкретный Юзер - Вася и он является либо владельцем, либо игроком команды. Поэтому надо сначала правильно нарисовать Диаграмму Классов, а потом уже нарисовать конкретное состояние Объектов, скорее всего двумя Диаграммами Объектов (либо владелец, либо игрок) с квалификаторами.
Я же не строю диаграмму объектов. И как я только что описал, юзер - это и владелец, и, в тоже время, игрок. Вот как раз я и работаю над правильной прорисовкой диаграммы классов.
-
Б.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?
Здесь, наверное, можно над ассоциацией написать имя используемого метода... ? Другого способа я не вижу... ведь внутри класса обычно МНОГО методов, и какой из них относится к конкретной ассоциации - не всегда очевидно, верно?
-
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?
см. выше. Но вообще ты занимаешься проектированием, а не реализацией.
Обычно программисту одной статики (диаграммы классов) мало. Нужна динамика. Например, диаграммы последовательности, на которых ты опишешь основные варианты использования данных классов. МОжешь представить их в виде коопераций, если захочется.
-
>А.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 один объект может вызвать методы другого вот и все.
Диаграмма классов описывает статику, а не динамику, которую ты уже стараешься пропихнуть.
Предлагаю тебе исходя из всего написанного еще раз сформулировать задачу, чтобы не было неточностей. А потом поговорим...
-
>> О чем, говорит квалификатор? что если у тебя имеется Объект типа user (а в нем естественно заполненный массив с team), то зная ключ (квалификатор), ты быстро найдешь или не найдешь нужную тебе команду (команды).
Ключ при этом НЕ хранится в User. Он приходит извне.
По сути это и есть ответ на мой вопрос... спасибо.
>> вообще ты занимаешься проектированием, а не реализацией.
Обычно программисту одной статики (диаграммы классов) мало. Нужна динамика. Например, диаграммы последовательности, на которых ты опишешь основные варианты использования данных классов. МОжешь представить их в виде коопераций, если захочется.
Вообще - я программист, которому в ближайшем будущем придётся играть роль архитектора, поставлена задача изучить УМЛ... вот и изучаю. При этом я хочу писать те же диаграммы классов максимально информативно...
Вот, к примеру, в моём "старом" проекте реализовано кеширование объектов. при этом формирование списков объектов и самих объектов происходит довольно быстро, но хранить списки после использования - нельзя...
Т.о. возникает задача показать на диаграмме классов, что список объектов держать членом класса -нельзя. Это можно сделать в виде отдельного комментария на диаграмме, а можно как-то более конкретно?
>> Если тебе не нравится, что team знает про user, то нарисуй стрелку на конце ассоциации, показав тем самым направление возможной навигации
Ну у меня как раз наоборот, team должен знать про user, но вот user - может получить список team'ов лишь отдельным запросом "куда-то"...
>> Реализовывается ассоциация например с помощью ссылок или указателей.
Да, по ссылки/указатели я знаю.
вобщем, спасибо ещё раз.
-
>> Тут начинается путаница... Ассоциация просто описывает знание одного класса о наличии другого и все
Т.е. не важно, кто и каким образом на кого-то ссылается. Мне, как архитектору, надо отобразить лишь наличие это ассоциации и её тип, да? А программист, посмотрит статику, динамику и решит как делать. Если есть какие-то факторы, на какие надо обратить его внимание (кеширование в моей реализации), то об этом надо сообщить отдельно.
>> Тут начинается путаница... Ассоциация просто описывает знание одного класса о наличии другого и все. Не надо связывать ассоциации с конкретными методами. Ассоциация показывает что в run-time один объект может вызвать методы другого вот и все.
>> Диаграмма классов описывает статику, а не динамику, которую ты уже стараешься пропихнуть.
аа.... вот оно что... в приципе, логично.
>> Предлагаю тебе исходя из всего написанного еще раз сформулировать задачу, чтобы не было неточностей. А потом поговорим...
нет необходимости. Задача - это я себе придумал пример, чтобы было конкретнее. С квалификаторами - вроде стало понятно... (ключ по которому искать нужные объекты в списке). В вот динамика
Наверное архитектору и не стоит вникать в детали реализации. верно? Надо делать свою задачу, а девелоперы уже будут делать свою?
-
Вот, к примеру, в моём "старом" проекте реализовано кеширование объектов. при этом формирование списков объектов и самих объектов происходит довольно быстро, но хранить списки после использования - нельзя...
Т.о. возникает задача показать на диаграмме классов, что список объектов держать членом класса -нельзя. Это можно сделать в виде отдельного комментария на диаграмме, а можно как-то более конкретно?
Это нефункциональное требование - только комментарий
-
Наверное архитектору и не стоит вникать в детали реализации. верно? Надо делать свою задачу, а девелоперы уже будут делать свою?
В детали релизации влезать не стоит, но показать динамику и др. безусловно необходимо.
Почитай про представления (view)
-
Не верно.
Во-первых по ссылке ни о каких квалификаторах (qualifier) речи нет.
Там показаны именованные коннекторы.
Во-вторых, квалификаторы применяются для снижения кратности на полюсе ассоциации.
Сорри, это я действительно не про то, просто всегда указывал атрибут связи, кот., как оказалось, называется квалификатор :)
-
Коллеги.
1. Давайте производить корректное цитирОвание для начала. И Budda и Денис - Вам следует сначала познакомится со справкой на использование форума. Сделайте одолжение.
2. Насчет квалификатора. Квалификатор создает квалифицированную ассоциацию.
Qualifier - qualify + er и определитель; уточнитель, спецификатор
Таким образом квалифицированная ассоциация - ассоциация уточняющая. Что же она уточняет, она уточняет связь одного класса с другим, сводя ее до уровня 1 ко 1. Т.е. квалификатор показывает, что каждый объект в такой связи со стороны противоположной квалификатору имеет атрибут с уникальным значением.
Так как одним из важнейших и определеющих свойств ОО парадигмы является уникальность объекта, то очевидно, что каждый объект уникален по определению. Однако в данном случае это не имеет практического значения, потому для подчеркивания того факта, что среди возможных значений некоего атрибута объекта могут быть только уникальные значения и используют квалификационную ассоциацию.
Типичным примером можно назвать такой пример:
смотри рисунки
-
Может значение терминов будем брать из стандарта UML?
Связь - это экземпляр ассоциации. На диаграммах классов (где рисуют квалификаторы) связей нет, там есть ассоциации, например. Связи можно найти на диаграммах объектов, взаимодействий.
Квалификатор никак не связан с ОО, а пришел из схем баз данных.
-
Может значение терминов будем брать из стандарта UML?
Связь - это экземпляр ассоциации. На диаграммах классов (где рисуют квалификаторы) связей нет, там есть ассоциации, например. Связи можно найти на диаграммах объектов, взаимодействий.
Замечание справедливое. Спасибо. Исправил ошибку
Квалификатор никак не связан с ОО, а пришел из схем баз данных.
Да, именно это я и хотел сказать, правда решил не трогать понятие схем баз данных. Насчет же причин появления квалификатора могу лишь догадываться. Связан ли он с ОО или нет, судить не могу. Однако применение его в диаграммах классов довольно широко. Рамбо, например, очень широко использует квалифицированную ассоциацию, по сути сводя ее до уровня понятия экземпляра ассоциации.
-
Рамбо, например, очень широко использует квалифицированную ассоциацию, по сути сводя ее до уровня понятия экземпляра связи.
Связь - экземпляр ассоциации.
Что такое "экземпляр связи" можно только догадываться.
Лучше процитировать Рамбо...
-
Связь - экземпляр ассоциации.
Что такое "экземпляр связи" можно только догадываться.
Ночные посиделки точно влияют на корректность :) Спасибо исправил :)