Множество множественностей UML

Question

У меня возник вопрос о указании кратности в диаграмме UML.

У меня есть класс SpriteObject, в котором есть список анимаций. У SpriteObject может быть 0 .. * анимация. Все анимации создаются внутри объекта SpriteObject и не существуют сами по себе.

Я не уверен на 100%, как я должен указать это с множественностью. После поиска в Интернете я нашел следующие 3 варианта:

Вариант 1: множественность должна указываться так, потому что каждый SpriteObject имеет 0 или более анимаций. Нет множественности, указанной на стороне объекта SpriteObject, поскольку анимация не имеет понятия о существовании объекта SpriteObject.

Вариант 2: Множественность должна указываться с обеих сторон как это, потому что нам нужно указать локальную связь между двумя классами, поэтому 1 SpriteObject имеет 0 или более анимаций.

Вариант 3: Множественность должна указываться с обеих сторон, так как нам нужно уметь читать множественность и понимать ее как часть целого (игры). Игра может содержать 0 .. * SpriteObjects и SpriteObject может содержать 0 .. * Анимации. Вот почему 0 .. * SpriteObjects есть 0 .. * анимаций Может кто-нибудь сказать мне, какой вариант является правильным? (Если какой-либо из них)

Answer 1

[Редактировать]

Это должно быть Вариант 1. Это composition relationship

Что это означает, что SpriteObject содержит и управляет времени жизни объектов анимации.

В качестве примера.

public class SpriteObject : IDispose 
{ 
    private List<Animation> animations; 

    // constructor 
    public SpriteObject() 
    { 
    animations = new List<Animations>(); 

    // initialise the list 
    } 

    public ovveride Dispose() 
    { 
    // clear list 
    } 
} 

Если это отношение агрегирования.

Обратите внимание на символ, полый алмаз. Это aggregagtion relationsip. Это означает, что экземпляр SpriteObject может иметь ноль или более экземпляров анимации, но время жизни объектов анимации не зависит от времени жизни объекта SpriteObject.

AC пример # код будет выглядеть так:

public class SpriteObject 
{ 
    private List<Animation> animations; 

    // constructor 
    public SpriteObject(List<Animation> animations) 
    { 
    this.animations = animations; 
    } 
} 

Answer 2

Я бы сразу отвергнуть вариант 3, потому что вы сказали, что Animation например не может существовать сам по себе, и я был бы очень удивлен тем, что тот же экземпляр может быть связан с несколькими экземплярами SpriteObject.

Следующий вопрос: имеет ли пример Animation ссылку на свой SpriteObject владелец? Если вы не выбрали вариант 1.

Answer 3

• Третий неверный. Запись на линии - это один экземпляр одного отношения (это ассоциация на этот раз). Вы описываете его особенности. Для лучшего чувства, лучше назовите его. Например, поместите анимацию вправо с правой стороны соединения. Это означало бы, что каждый анимационный список подключается к ONE spriteObject (по крайней мере, от принадлежности) и ко многим анимациям (они скорее будут элементами списка).

• Первый вариант тоже. Он не определяет кратность с левой стороны. Таким образом, он МОЖЕТ означать то, что вы хотите, но это может означать что-то еще, вы не имеете в виду. Если вы еще не решили против варианта, что ассоциация не является структурой списка, но что-то более сложное, которое может быть связано с несколькими или нулевыми spriteObjects, тогда было бы хорошо.

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

Если вы решили, что соединение будет действительно атрибутом spriteObject, вы можете показать его более точно, поставив DOT между правой стрелкой и правым классом. Он устанавливается в большинстве инструментов, устанавливая classifier's owning для правильного конца ассоциации.

Это очень хорошая мысль, чтобы установить взаимные ограничения на концах. И не только они.Чем больше информации вы поместите в агрегацию: имена, стрелки, точки, видимость, тем лучше вы поймете свою собственную модель и больше шансов, вы заметите некоторые проблемы.

BTW, когда у вас нет стрелок на боках (это то же самое, что стрелки на стрелках BOTH), он может отображать два разных варианта: одна вещь, которая знает о случаях с обеих сторон или (чаще) две вещи одновременно - ДВА разных атрибутов из двух разных экземпляров из двух разных классов - один конец является ссылкой справа налево, а другой - ссылкой слева направо. ТОГДА точки становятся действительно необходимыми.

Answer 4

Для кратности части - если опустить множественность информации в любом месте (состав, агрегация, конец ассоциации, атрибут, часть ...), в соответствии с UML, это означает именно то, что вы не предоставили информацию, она неизвестна или не имеет значения.

Вы можете указать значение по умолчанию для своей модели (сама спецификация языка UML не определяет значение множественности по умолчанию для моделей пользователей). Большинство пользователей UML выбирают значение по умолчанию только одного [1], но я видел другие выбранные значения по умолчанию, например [0 .. *]. Формального определения множественности для модели UML нет, вы должны каким-то образом информировать читателей о своей модели (вводный текст, комментарий и т. Д.).

Если вы сталкиваетесь с моделью, которая не предоставляет эту информацию, самым безопасным предположением является то, что по умолчанию множественность установлена ​​на [1].

С этой точки зрения, я бы предположил, что случай 1 и случай 2 совпадают.

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

Это правда, что все созданные объекты должны подчиняться этому правилу, но это не обязательно означает, что все ваши объекты анимации должны быть составлены в спрайтах. У вас может быть анимация на экране заставки, который не принадлежит ни одному спрайту. С другой стороны, верно, что составные объекты (части) не могут быть составлены в нескольких композиционных объектах (целых) одновременно.

Таким образом, возможные ситуации:

1. Множественность 0..1 на конце Sprite композиции - это будет означать, что некоторые анимации являются частью спрайтов. Эти анимации и их жизнь управляются этими спрайтами. Кроме того, в системе могут быть и другие независимые от спрайтов анимации.
2. Множественность точно 1 (либо явно, как в случае 2, либо по умолчанию, как, вероятно, для случая 1) - это будет означать, что все экземпляры анимации должны быть частью некоторого спрайта.
3. Другие случаи множественности, с верхней границей больше 1 - ну, так как я не могу делиться сложенными частями, семантика композиции запрещает мне иметь более одного экземпляра спрайта на анимацию.

Может быть немного темы замечания в конце:

Настройки кратность к, скажем, 0 .. * на конец спрайта состава будет по-прежнему производит действительный UML (с абстрактной точки зрения синтаксиса). Это не имеет большого смысла, и читатель, вероятно, допустил бы какую-то ошибку, но когда вы подумаете об этом, вы можете создать модель экземпляра, которая будет уважать все структурные и семантические ограничения, просто «не используя» возможность иметь более одного sprite для анимации. Это точно так же, как сказать, что вы хотите, чтобы какое-то число было больше 0 и 10 одновременно. Это не так, просто его можно было уточнить более простым и понятным образом.