Комментарии

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

1. Названия свойств записанны неверно. Комната 1, Комната 2... - это ведь одно свойство, например, названиекомнаты или номеркомнаты
2. Зачем нужно свойство "периодичность", ведь и так есть связь комната-период, которая эту периодичность показывает.
3. Маршрут - это явно сложный объект. Из чего он состоит? И какие, кстати, данные нужны для его определения?
4. Не правильно проставленны кратности - не бывает кратности "бесконечность", может быть 0-бесконечность, 1-бесконечность, 1, 0-1 и тд.

Если что-то не понятно, пишите, постараюсь объяснить подробнее. Жду исправелнную модель)

> ... такие предметы как стулья или кровати могут находиться в нескольких комнатах сразу

Разумеется могут, но ведь это будут разные стулья и у каждого из них будет свое положение в пространстве. А ваша модель читается именно так, что один и тот же стул находится в нескольких комнатах.

> не находится в комнатах или быть убранным вообще, тогда 0

Вот это можно и оставить, хотя не понятно зачем пылесосу знать о таких предметах.

> а разве само нахождение предметов в комнате не определяет сколько в ней находится

В принципе да, определяет. Но тут есть нюанс. Если у нас есть только ассоциация предмет -> комната, то для того чтобы узнать какие предметы находятся в данной комнате нам придется перебрать все предметы и проверить для каждого а находится ли он в нашей комнате. Поэтому мы добавляем вторую ассоциацию комната -> предмет. Эти две ассоциации по сути несут одну и ту же информацию, хотя у них будет разное название и разная кратность, и обозначаются они одной линией. Добавление обоих названий и кратностей делает нашу модель более полной и удобной для чтения.

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

1. Файлик с заготовкой это шаблон, он все таки немного отличается от текста. Есть интересный вариант, когда вы не редактируете шаблон в ручную, а заполняете его данными программно. Поэтому лучше всего для шаблона и текста сделать разные классы.
2. Ну да, только те что нужны. Связи это по сути лишнее свойства. Зачем вам в посте нужен список всех картинок? Он ведь и так будет в тексте. Если еще одна связь и понадобится, в всегда сможете добавить ее на этапе проектирования или просто в коде. Пока разбираетесь с предметной областью лишние связи просто захламляют модель.

Выглядит хорошо, но есть пара проблем:

1. Если вы наследуете пост-обзор от поста-участника, зачем нужно повтороно устанавливать ассоциации поста-обзора с изображением и текстом-поста? Ведь эти ассоциации и так наследуются от поста-участника.
2. Не очень понятно зачем нужно наследавание текста-поста от текста-заготовки... Какие свойства там наследуются?
3. Текст-поста ассоциируется с изображением и сам пост тоже ассоциируется с изображением - точно нужны обе эти ассоциации? Они разные по смыслу? Не достаточно ли одной, той что идет от текста и изображению?

Выглядит хорошо, но можно улучшить пару мелочей:

1. Желательно поподписывать связи с обоих сторон
2. Можно уточнить кратности - не очень понятно 10-бесконечность, да и не везде они проставлены
3. Как насчет класса Предмет? Может пригодится?
4. Проверьте модель на предмет избыточных связей. Нужна ли связь Учитель - Расписание? Ведь вы обошлись без связи Аудитория - Расписание, так как эти сущности связанны опосредованно, через Урок.

P.S. Советую (не настаиваю) не мучаться с графическим редактором, делайте просто карандашом на бумажке и фотографируйте.

Очень понравилось, что вы выложили промежуточный вариант работы.

Вы идете в правильном направлении, но модель еще нужно дорабатывать. Справа, там где Предмет, Комната, Траектория - все норм, а вот слева, еще надо подумать :) Думаю вы разберетесь, но если все же не получится - пишите, помогу.

1. Ну да, все свойства наследуются. Именно поэтому наследование применяется не сказать чтобы часто. Я бы для Фермера и Местного Жителя ввел общего предка, скажем, Физлицо - куда вынес бы ФИО и другие общие свойства. Второй вариант, это изменить кратность ассоциации между местным жителем и паем, поставить там 0-1, вместо 1.

2. Ага, может. В реале, такие штуки надо будет уточнять у заказчика, а пока учимся можно просто постулировать - да или нет.

3. Я бы все же советовал ручками рисовать, на практике вы редко будете пользоваться софтом для рисования диаграмм, обычно этим балуются бизнес аналитики или архитекторы при составлении документации. Для остальных - блокнот или доска с маркерами. Для разработчика схемы нужны чтобы быстро разобраться с задачей, объяснить ее другим и т.д. - программы хоть и выдают красивый результат менее удобны в этом чем обычный карандаш с резинкой :) Еще учтите, что сейчас мы занимаемся анализом предметной области, а программы обычно заточенны под проектирование (очень похоже, но все же разные вещи - думаю, курс поможет понять в чем), отсюда, кстати, и вылезли плюсики :)

Тут похуже. Согласен с классами Учитель, Предмет и Кабинет (названия классов всегда в единственном числе, так принято, хотя и подразумеваются множества). В вот дальше явно криво. Что такое Рабочее время не понятно, для Рассписания явно нужна дополнительная сущность Урок, которая будет связана с Учителем, Предметом и Кабинетом и будет иметь дополнительные свойства, такие как время_проведения. Не ясно что такое Нагрузка, при этом у него есть свойство "Программа занятий...", которое тянет на полноценную сущность, то есть не является элементарным. Короче, надо дорабатывать :)

Хорошая работа!

Есть правда пара замечаний:

1. В вашей модели получается, что сам фермер всегда является владельцем пая, ассоциация ведь тоже наследуется.
2. Есть непонятная ассоциация между Фермером и Местным жителем. Что это такое?
3. Ассоциации хорошо бы подписать, например, Местный житель владеет Паем, Пай принадлежит Местному жителю
4. Видимость (плюсики) не нужны - это относится к реализации, когда строите модель предметной области все это преждевременно

В целом все хорошо, но есть парочка замечаний :)

С репутацией не понятно. Там по идее две связи должно быть - кто поставил лайк и к чему он относится (пост, коммент)

Еще я бы убрал айдишки, обозначения областей видимости и типы данных - все это относится скорее к реализации, при анализе предметной области - это преждевременно. Еще заметил, что в модели есть свойства, которые отвечают за связи между сущностями, например, Reputation, User - это тоже реализация, причем в стиле ООП, если нужно будет модель трансформировать в схему реляционной БД будем мешать - имхо лишнее, тем более что имена для них выбраны не лучшим образом (Post.user - Post.createdBy: User, Comment.post - Comment.replyTo: Post)

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

> Интересно попробовать другую задачу (если успею до понедельника то добавлю в пост)

Делайте обязательно, можно и не одну :) Даже если не успеете до понедельника, напишите мне - все равно посмотрю.

> фермер тоже является жителем и у него одинаковые свойства с жителями, земельные паи, и значит он может наследовать жителям

На мой взгляд это достаточно странное ограничение. Да, фермер может быть жителем/владельцем пая, но может и не быть. Не уверен, что здесь нужно использовать наследование. Не проще ли ввести классы "Пай", "Владелец пая" и связать их ассоциацией? Насчет класса "Фермер" - зачем он нужен вообще? Что бы связать "Пай" и "Зерновые культуры" не лучше ли ввести класс "Посев/Урожай/..", как запись о том, чем конкретно был засеян пай в этом сезоне.

Еще не понятно, как с такой моделью считать расходы на аренду земли. Не ясно, что такое "паи" - это по-идее отдельная сущность, у нее есть свойства, например, размер и владелец.. И что такое "аренда" и "затраты"?

> Что можно из архитипа сделать своего персонажа добавив ему определенные вещи, а можно так не делать и оставить архитип.

За это отвечает наследование. Вторая связь, выходит, там лишняя.

В целом выглядит хорошо.

А что означает связь между Персонажем и Архитипом?

> Со следующими занятиями я могу немного пролететь

В этом нет ничего страшного, вернетесь - нагоните.

> Вы проверите опоздавших?

Конечно проверю :)

По сути - задача у вас описана хорошо, модель тоже в принципе годная. Не совсем понятно, что означает связь "мой компьютер". Зачем она нужна? Ведь вроде все файлы и так у вас на компьютере. Еще не понятна связь между видео и фото файлами.

По сущностям можно сделать еще так (рассмотрите как вариант):

Файл
     формат: фото/видео
     время_создания
     тема

Папка:
     сортировка: по времени создания/по теме/по формату

При таком раскладе у вас будет только одна связь между двумя сущностями - к какой папке отосится файл. Отношение будет "многие ко многим", то есть один файл может быть в разных папках и в одной папке будет больше одного файла.

У вас предметная область - это игровой мир. То есть сущностями будут "сундук", "монеты" и другие вещи которые встречаются в игре.

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

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