Доброго времени суток, Уважаемые!

В виду моей неопытности я никак не могу разобраться с одной диаграммой, поэтому решил попросить помощи. Мне интересно - это я неправильно понимаю кратность ассоциации, или в книге ошибка.

Речь идет о книге - Язык UML. Руководство пользователя. Буча, Рамбо и Якобсона. В ней представлена диаграмма из вложения.

В пояснениях к диаграмме сказано:

Каждый курс относится исключительно к одному факультету.

Однако чуть раньше в книге сказано:

Устанавливая множественность дальнего конца ассоциации, вы указываете, сколько объектов может существовать на дальнем конце ассоциации для каждого объекта класса находящегося на ближнем ее конце.

Получается что для класса "Курс" используется кратность А. Для класса "Факультет" - кратность Б.
Тогда курсу может соответствовать 1 или много факультетов. Так ли это?

Привет.
История такая. Картинку взяли из 1-го издания, где она имела номер 5-10 и в сопроводительном тексте ничего не было сказано о мощностях ассоциации Курс -- Факультет. Но текст взяли из второго издания, где картинка исправлена и выглядит так:

Итог. Ошибка у тех, кто готовил к изданию перевод на русский язык. 

Фух, отлегло!
Спасибо большое за разъяснение!

Итог. Ошибка у тех, кто готовил к изданию перевод на русский язык.

А почему один и тот же курс лекций не может читаться на разных факультетах?

Ну и теоретически может быть ситуация, когда на факультете лекций не читают, или есть курс лекций, который пока не читается нигде. То есть кратность 0.*-0.*

А вообще пример в принципе неполный. Явно не хватает сущностей типа план обучения, расписание и т.д.

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

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

Если верить этому переводу

http://dit.isuct.ru/ivt/books/CASE/case11/ch5.htm

то там задана кратность 1..*-1..*

И как раз отношение Курс-Факультет не поименовано и не описано. Что вообщем-то и вызывает такие кривотолки как у переводчиков, так и у студентов.

Это лишний раз подчеркивает, как важно в реальных моделях вроде бы очевидные отношения именовать и описывать

Если верить этому переводу...

Это перевод первой редакции книги (про "первый" UML). Вот мы и раскрыли тайны "кухни". При подготовке перевода второй редакции поленились снова перевести диаграмму, взяли готовую из предыдущего перевода, не обратив внимание на то, что у неё в разных редакциях разные версии.

Не совсем в тему.
По моим представлениям диаграмма (для определённости возьмём исправленную - из второго англоязычного издания) представляет собой незаконченный артефакт (даже как просто диаграмма). По ней возникают вопросы:

• Преподаватель может быть деканом факультета, на котором не работает?
• Студент может посещать курс, факультет которого не входит в ВУЗ, в котором студент обучается?
• Преподаватель может читать курс, если не работает на факультете курса?
• Студент посещает курс или чтение этого курса преподавателем? Это происходит в рамках ВУЗа?

Определение подобных вопросов по уже полученной информации (диаграммирование очень помогает!) - существенная часть работы аналитика. Или я ошибаюсь?

Ну коли уж пошла такая пьянка... А как подобные условия отображаются на диаграммах? Есть ли примеры?

По ней возникают вопросы:

• Преподаватель может быть деканом факультета, на котором не работает?
• Студент может посещать курс, факультет которого не входит в ВУЗ, в котором студент обучается?
• Преподаватель может читать курс, если не работает на факультете курса?
• Студент посещает курс или чтение этого курса преподавателем? Это происходит в рамках ВУЗа?

Мне нравится, как у Амблера написано про годные гибкие модели: http://agilemodeling.com/essays/whenIsAModelAgile.htm Что у модели есть цель и аудитория, что она достаточно подробна, достаточно точна  и достаточно непротиворечива. В этом смысле любую модель можно критиковать, определяя свою цель, свой уровень подробности, точности, непротиворечивости.
Пример, похожий на [1] даётся далее в главе 6

поэтому тут можно усмотреть чисто методические причины.
[2] Когда было проще с проходом в здания, такое практиковалось и, насколько мне известно, официально не запрещено.
[3] Может. У нас физику читали преподы с другого факультета (физфака). А наши преподы мучили студентов-геологов.
[4] Имеет смысл отделить описание курса от прочтения курса, если мы хотим идти дальше учебного эскиза. 

Ну коли уж пошла такая пьянка... А как подобные условия отображаются на диаграммах? Есть ли примеры?

Практически любое ограничение можно выразить в виде комментариев или на OCL.
Диаграмно тоже можно.
[1] в предыдущем сообщении.
[1], [2] и [3] вместе - во вложении.

Мне нравится, как у Амблера написано про годные гибкие модели: http://agilemodeling.com/essays/whenIsAModelAgile.htm Что у модели есть цель и аудитория, что она достаточно подробна, достаточно точна  и достаточно непротиворечива. В этом смысле любую модель можно критиковать, определяя свою цель, свой уровень подробности, точности, непротиворечивости.

В реальности приходилось сталкиваться только с 2 целями:

• оценка объема работы - тогда достаточно определить состав классов и состав ассоциаций
• собственно разработка: от UI до тестирования - тогда подробно, полно и непротиворечиво

Понимаю, что может быть и по-другому и хочу узнать - как именно.

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

Диаграмно тоже можно.

Не подскажете, где можно почитать про такой стиль построения диаграмм классов?
Интуитивно все понятно, но хотелось бы получить формальное описание

11ая глава стандарта UML2.5. Только тут есть отступления от стандартной нотации. Кроме того, в стандарте, как обычно, накручено так, что OCL я бы применил с большей уверенностью.