Я рисовал диаграммы ввода-вывода, активности и классов для «Crafting System» для моей игры.UML - справочная система рисования чертежей
Я немного уверен в диаграммах активности и использования, но сомневаюсь в диаграммах классов. Вы находите в нем какие-либо ошибки? или предложить какие-либо улучшения?
Крафт Механика:
Crafter может быть либо NPC или здание кап, который игрок взаимодействует ремеслу. После нажатия на крафт окно откроется.
Хм. Если мы посмотрим на процесс крафтинга очень абстрактным образом, это может сработать. То, что я пропустил здесь, - это направленные (ака односторонние) зависимости в диаграмме классов; например, процесс обработки не может теперь ничего о крафтере. То же самое касается предметов.
В более подробном виде вы должны будете разделить некоторые сложные классы. Например, процесс обработки, скорее всего, будет разделен по меньшей мере на два класса, если не больше. Причина этого заключается в том, что вы хотите, чтобы данные («рецепт») были разделены на фактический процесс. Это не только облегчит работу с фактической реализацией, но также даст вам возможность предоставить фактические элементы рецепта игроку.
Это приводит меня к другому вопросу: если у вас есть какое-то дерево элементов, ваш ConsumableItem и CraftableItem больше похожи на интерфейсы с одним и тем же родителем. Infact, я честно не понимаю, почему вы делаете какую-либо разницу между этими двумя, потому что здесь вы можете смешивать классы и роли (которые в UML описываются по-разному).
Вопрос на самом деле не связан с программированием; это больше процесса программирования, чем фактическое программирование. – fdh
то что такое UML для здесь? почему существует созданный тег UML? –
Поскольку многие из этих вопросов касаются реализации UML посредством программирования, а не создания и редактирования UML, как вы спрашиваете. – fdh