Модель домена UML: как различать атрибуты и классы? - PullRequest
Новая
       38

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

0 голосов
/ 27 мая 2018

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

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

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

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

1 Ответ

0 голосов
/ 28 мая 2018

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

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

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

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

...