Диаграмма классов UML Ассоциация vs (Агрегация | Состав) - Алмазы

Question

Я не уверен, правильно ли я использую ассоциацию и агрегацию или композиционный алмаз .

Я бы использовал Ассоциацию для интерфейсов, потому что не могу их создать.Например, они делают это здесь .Или для статических классов, по той же причине.

И алмазы, которые я использую только для объектов, которые я могу создать.Как и обычные классы.

Но я не уверен, что это правильный способ их дифференцировать, потому что, если вы снова проверите , вы увидите, что они не настолько конкретны в этом.В спецификации UML 2.3 я не мог получить больше, так как вы ее используете?

И есть третий способ, пунктирная стрелка <>, но я нене знаю, когда использовать этот.Так, может, ты тоже поможешь мне с этим?

Answer 1

Я бы использовал Ассоциацию для интерфейсов, потому что не могу их создать.Как они делают это здесь, например.Или для статических классов, по той же причине.

И алмазы, которые я использую только для объектов, которые я могу создать.Как обычные классы.

Это не совсем так, как они работают.Три формы (Ассоциация, Агрегация и Композиция) определяют различные свойства отношения.Все три обычно используются между классами, хотя могут относиться и к интерфейсам.Ассоциация и композиция являются двумя самыми простыми:

• Ассоциация (без ромба) является наиболее общей формой, позволяющей определять мощность и судоходство на обоих концах.
• Композиция (заполненный ромб)это отношение целой части, где «целое» (оканчивающееся черным бриллиантом) «содержит» часть.Он налагает два ключевых ограничения:
  1. Может быть только 1 контейнер (т. Е. Количество элементов в конце равно 1);
  2. Это накладывает ответственность за весь жизненный цикл деталей.Таким образом, контейнер отвечает за создание и удаление деталей.Часть не может продолжать существовать, если ее контейнер удален.

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

И есть третий способ, пунктирная стрелка <>, но у меня нет клея, когда его использовать.

Я думаю, вы имеете в виду отношения зависимости.Это более слабая форма ассоциации.В качестве примера возьмем следующее определение класса

class Foo {

 def bar(Baz: aParam) {
  ...
 }
}

. В этом случае тип Foo зависит от типа Baz при использовании в сигнатуре метода bar ().Однако между ними нет никакой связи (не может разумно обсуждаться, например, кардинальность отношений между экземпляром Foo и экземпляром Baz).

С практической точки зрения я бы сказал:

• вы можете использовать прямые ассоциации для 80% + отношений, которые вы, вероятно, захотите смоделировать
• Композиция, вероятно, учитывает большинство оставшихся сценариев
• Зависимость может быть полезна в некоторых обстоятельствах
• Вы можете довольно счастливо обходиться без использования Агрегации.

hth.

Answer 2

Давайте установим условия. Агрегация является мета-термином в стандарте UML и означает ОБА композицию и общую агрегацию, просто названную shared . Слишком часто это называется неправильно «агрегация». Это ПЛОХО, потому что композиция - это тоже совокупность. Как я понимаю, вы имеете в виду "поделился".

Далее от стандарта UML:

составной - Указывает, что свойство агрегировано, составной объект несет ответственность за существование и хранение составленных предметов (частей).

Итак, связь университета с кафедрами - это композиция, потому что кафедры не существует вне университета (ИМХО)

Точная семантика совместной агрегации зависит от области применения и модельер.

Т.е., все другие ассоциации могут быть нарисованы как общие совокупности, если вы только следуете некоторым своим принципам или кому-то еще. Также смотрите здесь .