Во-первых, в дизайне нет верного или неправильного, только мнения.Обращаться за советом - хорошая идея, просто помните, что совет - это все, что вы получаете, а не правильный или неправильный ответ.Тем не менее, вот некоторые из моих предложений:
1) Обратите особое внимание на направления и кратности ассоциаций.
На данный момент у вашего MovieInfo есть прямая связь с жанром и MovieInfo.конечная кратность равна 0..1.Это означает, что в любом жанре может быть не более одного фильма, а также что вы не можете выбрать жанр и найти все фильмы этого жанра.
Если вместо этого сделать ассоциацию двунаправленной, а кратность 0 .. * одновременнозаканчивается, это лучше соответствует логическим отношениям между фильмом и жанром.
2) Не разрешать установку ключевых характеристик.
Например, ваш класс Genre содержит операцию setGenre ()Это означает, что вы можете связать фильм с жанром «ужас», а затем изменить сам жанр, вместо этого «романтическая комедия».Вы, скорее всего, не хотите, чтобы это произошло, поэтому вместо этого название жанра должно быть установлено только в конструкторе Genre.
3) Больше классов!
Хорошая идея - создать отдельного человека.класс для каждой концепции в вашем информационном пространстве.Прямо сейчас вы используете простые строки для представления таких вещей, как студия, режиссер и т. Д., Что означает, что если вы хотите найти, скажем, все фильмы, выпущенные определенной студией, вы должны просмотреть все фильмы и проверить их «студийные» поляиндивидуально.
Нынешний дизайн также очень затрудняет работу с совместными постановками, в которых задействовано более одной студии.
Вместо этого вы должны создать отдельные классы, как вы делали для Actor иЖанр.
4) Смена актера на человека.
Некоторые люди являются актерами в одних фильмах, режиссерами в других, продюсерами в некоторых ... Но если вы создадите отдельные классы для актера, режиссера,и т. д. вы в конечном итоге сталкиваетесь с ситуацией, когда один и тот же индивидуум представлен несколькими экземплярами разных классов, что является беспорядочным.
Если вместо этого вы создаете один класс Person с ассоциацией 0 .. * для Movie с именем actorInеще одна 0 .. * ассоциация с фильмом по имени DirectorOf и т. д., вы решаете эту проблему.Да, вы можете иметь несколько отдельных ассоциаций между одними и теми же двумя классами.
5) Отделить информационную модель от модели реализации.
Информационная модель описывает концепции и их взаимосвязи, модель реализации -кодовые объекты, используемые для достижения желаемой функциональности.В этом случае процедуры get () и set () являются частью модели реализации;они ничего не добавляют к информационной модели.
Как только вы попадаете в модель реализации, именно здесь вы начинаете думать о таких вопросах реализации, как «действительно ли я хочу иметь возможность произвольно устанавливать счетчик воспроизведения фильма,не хочу ли я просто увеличить его на единицу? "
Хорошо, надеюсь, это поможет некоторым.Помните, что это все личное мнение, и удачи.
Часть 2 - Добавлено после комментариев Эгиды 30 июля:
Вы задаете довольно большой вопрос здесь, и это больше вобласть общего проектирования программного обеспечения, в частности Java или UML.
В больших или сложных системах часто используется модель предметной области.Это описывает контекст, в котором существует система.В вашем случае модель домена будет содержать такие вещи, как IMDB, но не будет Actor, поскольку ваша система не будет взаимодействовать с какими-либо участниками.
Информационная модель, с другой стороны, описывает информацию, управляемуюсистема и отношения между различными информационными объектами.Информационные объекты могут представлять определенные доменные объекты, но они не должны и не все доменные объекты должны быть представлены в информационной модели.На обновленной диаграмме у вас есть начало информационной модели.
Как домен, так и информационная модель помогают определить или объяснить систему.Они не используются напрямую для генерации кода или чего-либо подобного.Они там, чтобы помочь вам поговорить и понять систему и ее части.Причина, по которой они являются отдельными моделями, заключается в том, что проектирование системы является сложным процессом, и это помогает упростить ситуацию, если вы можете сосредоточиться только на одном аспекте за раз.Кроме того, в семействе языков UML отсутствует понятие «аспект», что означает, что вы не можете описать различные аспекты одной и той же вещи простым способом;следовательно, отдельные модели для разных аспектов.
После того, как вы приступите к реализации, вам нужно будет управлять информацией.Опять же, классы, которые вы создаете для этого, не обязательно должны напрямую соответствовать классам в информационной модели, но здесь вам нужно убедиться, что вы правильно реализовали все информационные концепции и отношения.
Все, что сказано,в любом проекте вам всегда нужно находить правильный баланс между написанием спецификаций и выполнением заданий, а также между указанием различных аспектов системы.Управление информацией - это только один аспект, и есть много других, таких как обмен данными, управление ошибками, многопоточность и т. Д. И т. Д.
При любой документации (а модели UML - это тип документации) вы всегда должны помнить оцелевая аудитория: что вы должны им сказать, и как вы должны структурировать сообщение, чтобы оно было максимально четким?Если предполагаемая аудитория - это вы сами, то, возможно, вы слишком конкретизируете - хотя всегда полезно попытаться изложить свои мысли на бумаге (или в модели), чтобы проверить себя и убедиться, что выЯ не пытаюсь где-то делить на ноль.
Я не пытаюсь вас обескуражить, ум.Если одной из ваших целей в этом проекте является изучение UML, то у вас все хорошо.Просто имейте в виду, что моделирование склоняет вас к мысли, что, пока модель завершена и последовательна, код будет писать сам.Это не произойдет, и всегда останется несколько Больших Проблем, которые не заявят о себе, пока вы не попадете в код.Если вы тратите много времени на определение и моделирование только для того, чтобы понять, что это не решает эти большие проблемы, вам может надоест все это и выкинуть все это, что было бы жаль.