Модель предметной области UML: как различать атрибуты и классы?

В настоящее время я создаю доменную модель боевой игры, и мне трудно определить, должны ли определенные элементы быть собственным классом или атрибутами какого-то класса. Например, я использовал список категорий для определения следующих идей/объектов: Боец, Уровень, Оружие, Доспехи, Атрибуты, Навыки, Арена, Режим игры, Журнал игры, Противник.

Например, я не могу сказать, должны ли Уровень, Оружие, Броня, Атрибуты, Навыки просто указываться как атрибуты бойца или они должны быть разграничены как самостоятельный объект. Я также не могу сказать, должен ли противник быть отдельным классом, поскольку в конечном итоге это объект-истребитель с ассоциацией «атака/защита» с другим бойцом.

Как определить, что будет правильным выбором для каждого элемента в списке категорий? Могут ли они быть субъективными?

К вашему сведению, я использую 3-е издание Крейга Лармана «Применение UML и шаблонов» в качестве источника информации.


uml domain-model
person hisoka    schedule 27.05.2018    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Чтобы на мгновение прояснить ваш вопрос - каждый класс в вашей модели предметной области будет иметь набор атрибутов. Думаю, вы задаетесь вопросом, должен ли Type каждого из этих атрибутов быть самим классом или какой-либо другой структурой данных (например, структурой, перечислением, примитивом и т. д.).

Если это верно, то ответ сводится к выбору дизайна, который вытекает из вашего анализа; не существует одного «правильного пути» — это искусство проектирования программного обеспечения. Однако есть несколько ключевых моментов, на которые вы, возможно, захотите обратить внимание при принятии решения:

  1. Доказательства поведенческих требований. Должен ли объект, на который ссылается атрибут, сам инкапсулировать поведение? Очевидно, что определенные структуры данных не могут инкапсулировать поведение, что может привести к тому, что вы сделаете выбор в пользу тех, которые могут (например, класс или структура).
  2. Сложность структуры данных. Должен ли объект, на который ссылается атрибут, инкапсулировать сложные структуры данных? (например, несколько, возможно, иерархических данных различных примитивов и/или сложных типов) Или это просто? (например, одно целое значение). Опять же, сложность структуры будет ограничивать то, как вы можете ее представить.
  3. Каковы нефункциональные требования вашей системы? (например, требования к производительности?) NFR, такие как производительность, масштабируемость и безопасность, могут ограничить ваш выбор дизайна, так что вы можете выбрать простое представление сложных типов или исключить поведенческие потребности и т. д..
  4. Помогает вам выбор дизайна или мешает? Нет смысла представлять что-то слишком сложным способом, который мешает вашей работе или системе.
  5. Аудитория. Это, возможно, самый важный момент — для кого вы создаете модель предметной области и что вы пытаетесь донести до них?

Так, например, вы можете представить «Оружие» как атрибут, типизированный как класс, или используя простой тип. Есть ли у «Оружия» собственное поведение? Содержит ли он несколько сложных данных? Существует ли NFR, который означает, что его можно рассматривать только как перечисление? И так далее.

person muszeo    schedule 28.05.2018
comment
Я собирался написать аналогичный ответ, но пока набрал только одно предложение :-) - person qwerty_so; 28.05.2018