В чем разница между ассоциацией, агрегацией и составом?

В чем разница между ассоциацией, агрегацией и составом? Пожалуйста, объясните с точки зрения реализации.

Ответ 1

Ассоциация - это связь, в которой все объекты имеют собственный жизненный цикл, и нет владельца.

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

Возьмем пример Департамента и учителя. Один преподаватель не может принадлежать нескольким отделам, но если мы удалим отдел, объект учителя не будет уничтожен. Мы можем думать об этом как о "has-a".
Состав - это снова специализированная форма агрегации, и мы можем назвать это как "смерть". Это сильный тип агрегирования. У дочернего объекта нет жизненного цикла, и если родительский объект удален, все дочерние объекты также будут удалены.

Давайте снова возьмем пример отношений между Домом и Комнатами. Дом может содержать несколько комнат - нет независимой жизни комнаты, и любая комната не может принадлежать двум различным домам. Если мы удалим помещение, вы автоматически удалите его.

Возьмем еще одну примерную взаимосвязь между Вопросами и Параметрами. Отдельные вопросы могут иметь несколько опций, и опция не может принадлежать нескольким вопросам. Если мы удалим вопросы, параметры будут автоматически удалены.

Ответ 2

Для двух объектов, Foo и Bar могут быть определены отношения

Ассоциация - у меня есть отношения с объектом. Foo использует Bar

public class Foo { 
    void Baz(Bar bar) {
    } 
};

Композиция - я владею объектом и отвечаю за его жизнь. Когда умирает Foo, Bar тоже

public class Foo {
    private Bar bar = new Bar(); 
}

Агрегация - у меня есть объект, который я позаимствовал у кого-то другого. Когда Foo умирает, Bar может жить дальше.

public class Foo { 
    private Bar bar; 
    Foo(Bar bar) { 
       this.bar = bar; 
    }
}

Ответ 3

Я знаю, что этот вопрос помечен как С#, но понятия довольно общие вопросы, такие как перенаправление здесь. Поэтому я собираюсь изложить свою точку зрения здесь (немного предвзято с точки зрения Java, где мне удобнее).

Когда мы думаем об объектно-ориентированной природе, мы всегда думаем об объектах, классе (чертежах объектов) и отношениях между ними. Объекты связаны и взаимодействуют друг с другом с помощью методов. Другими словами, объект одного класса может использовать службы/методы, предоставляемые объектом другого класса. Этот тип отношений называется ассоциацией..

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

И в агрегации, и в композиции объект одного класса "владеет" объектом другого класса.
Но есть небольшая разница. В композиции объект класса, принадлежащий объекту, которому принадлежит класс , не может жить сам по себе(также называемый "отношения смерти"). Он всегда будет жить как часть своего объекта-владельца, где, как и в Aggregation, зависимый объект является автономным и может существовать, даже если объект-владелец класса мертв.
Таким образом, по составу, если владелец объекта является сборщиком мусора, будет принадлежать и принадлежащий объект, чего не происходит при агрегации.

Смущенный?

Пример композиции: рассмотрим пример автомобиля и двигателя, который очень специфичен для этого автомобиля (то есть его нельзя использовать ни в каком другом автомобиле). Этот тип отношений между Car и SpecificEngine классом называется Composition. Объект класса Car не может существовать без объекта класса SpecificEngine, а объект класса SpecificEngine не имеет значения без класса Car. Проще говоря, класс Car является единственным владельцем класса SpecificEngine.

Пример агрегации. Теперь рассмотрим класс Автомобиль и класс Колесо. Автомобиль нуждается в объекте Колесо, чтобы функционировать. То есть объект Car владеет объектом Wheel, но мы не можем сказать, что объект Wheel не имеет значения без объекта Car. Его очень хорошо можно использовать в велосипеде, грузовике или другом объекте автомобилей.

Подводя итог -

Подводя итог, можно сказать, что ассоциация - это очень общий термин, используемый для обозначения того, когда класс использует функции, предоставляемые другим классом. Мы называем это композицией, если один объект родительского класса владеет другим объектом дочернего класса, и этот объект дочернего класса не может существенным образом существовать без объекта родительского класса. Если это возможно, то это называется агрегацией.

Подробнее здесь. Я являюсь автором http://opensourceforgeeks.blogspot.in и добавил ссылку выше на соответствующий пост для большего контекста.

Ответ 4

Ассоциация является обобщенной концепцией отношений. Включает в себя как состав, так и агрегацию.

Композиция (смесь) - это способ объединить простые объекты или типы данных в одну единицу. Композиции являются важным строительным блоком многих базовых структур данных.

Агрегирование (сбор) отличается от обычного состава тем, что оно не подразумевает владение. В композиции, когда владелец объекта уничтожается, также и содержащиеся объекты. В совокупности это не обязательно верно.

Оба обозначают отношения между объектами и отличаются только их силой.

Trick помнить разницу: есть A - A ggregation и O шп - с O mpositoin

Теперь давайте посмотрим на следующее изображение

Аналогия:

Композиция: Следующая картинка представляет собой композицию изображения, т.е. использует отдельные изображения, составляющие одно изображение.

Агрегация: коллекция изображений в одном месте

Например, университет имеет различные факультеты, и на каждом факультете есть несколько профессоров. Если университет закроется, кафедры больше не будут существовать, но профессора на этих кафедрах будут продолжать существовать. Следовательно, университет можно рассматривать как состав кафедр, тогда как кафедры имеют совокупность профессоров. Кроме того, профессор может работать более чем на одном факультете, но факультет не может быть частью более чем одного университета.

Ответ 5

Зависимость (ссылки)
Это означает, что между двумя объектами нет концептуальной связи. например, объект объекта "Зачисление". Объекты Student & Course (как параметры метода или типы возврата)

public class EnrollmentService {
    public void enroll(Student s, Course c){}
}

Ассоциация (имеет-a)
Это означает, что почти всегда есть связь между объектами (они связаны). Объект Order имеет объект Customer

public class Order {
    private Customer customer
}

Агрегация (имеет + целую часть)
Особый вид ассоциации, где существует целая связь между двумя объектами. они могли бы жить друг без друга.

public class PlayList{
    private List<Song> songs;
}

Примечание: самая сложная часть - отличить агрегацию от нормальной ассоциации. Честно говоря, я думаю, что это открыто для разных интерпретаций.

Состав (есть + целая часть + собственность)
Специальный вид агрегации. Apartment состоят из некоторых Room. Room не может существовать без Apartment. когда квартира удалена, все связанные комнаты также удаляются.

public class Apartment{
    private Room bedroom;
    public Apartment() {
       bedroom = new Room();
    }
}

Ответ 6

Из сообщения Роберт Мартин в comp.object:

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

//[Example:]

//|A|----------->|B|

class A
{
  private:
    B* itsB;
};

Агрегация [...] - это типичное отношение целого/части. Это точно так же, как и ассоциация с исключением того, что экземпляры не могут иметь циклические отношения агрегации (т.е. Часть не может содержать ее целое).

//[Example:]

//|Node|<>-------->|Node|

class Node
{
  private:
    vector<Node*> itsNodes;
};

Тот факт, что это агрегирование, означает, что экземпляры Node не могут сформировать цикл. Таким образом, это Дерево узлов, а не граф узлов.

Композиция [...] точно такая же, как Агрегация, за исключением того, что время жизни "части" контролируется "целым". Этот контроль может быть прямым или транзитивным. То есть "целое" может взять на себя прямую ответственность за создание или уничтожение "части", или оно может принять уже созданную часть, а затем передать ее другому целому, которое берет на себя ответственность за это.

//[Example:]

//|Car|<#>-------->|Carburetor|

class Car
{
  public:
    virtual ~Car() {delete itsCarb;}
  private:
    Carburetor* itsCarb
};

Ответ 7

Как говорили другие, ассоциация - это взаимосвязь между объектами, агрегация и композиция - это типы ассоциации.

С точки зрения реализации агрегация получается с помощью члена класса по ссылке. Например, если класс А агрегирует объект класса B, у вас будет что-то вроде этого (в С++):

class A {
    B & element;
  // or B * element;
};

Семантика агрегации заключается в том, что когда объект A уничтожается, объект B, который он хранит, по-прежнему будет существовать. При использовании композиции у вас более сильные отношения, обычно, сохраняя элемент по значению:

class A {
    B element;
};

Здесь, когда объект A уничтожается, объект B, который он содержит, также будет уничтожен. Самый простой способ добиться этого - сохранить элемент по значению, но вы также можете использовать некоторый умный указатель или удалить член в деструкторе:

class A {
    std::auto_ptr<B> element;
};

class A {
    B * element;

    ~A() {
        delete B;
    }
};

Важным моментом является то, что в композиции объект-контейнер владеет содержащим его, тогда как в агрегации он ссылается.

Ответ 8

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

Обратите внимание, что термины агрегация и состав использовались в сообществе C++, возможно, в течение некоторого времени, прежде чем они были определены как особые случаи ассоциации в диаграммах классов UML.

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

Насколько я понимаю, эта путаница имеет два корня:

В сообществе C++ термин "агрегация" использовался в смысле класса, определяющего атрибут для ссылки на объекты другого независимого класса (см., Например, [1]), что является смыслом ассоциации в диаграммах классов UML., Термин "композиция" использовался для классов, которые определяют объекты-компоненты для своих объектов, так что при уничтожении составного объекта эти объекты-компоненты также уничтожаются.
В диаграммах классов UML и "агрегация", и "композиция" были определены как особые случаи ассоциаций, представляющих частично-целые отношения (которые давно обсуждались в философии). В их определениях различие между "агрегацией" и "композицией" основано на том факте, позволяет ли оно разделять часть между двумя или более целыми. Они определяют "композиции" как имеющие не разделяемые (эксклюзивные) части, в то время как "агрегаты" могут делиться своими частями. Кроме того, они говорят что-то вроде следующего: очень часто, но не во всех случаях, композиции имеют зависимость жизненного цикла между целым и его частями, так что части не могут существовать без целого.

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

См. также мой расширенный ответ на вопрос SO за апрель 2009 года, указанный ниже.

И свойство, которое, как предполагалось, определяет "композицию" между объектами ООП в сообществе C++ (и это убеждение по-прежнему широко распространено): зависимость жизненного цикла во время выполнения между двумя связанными объектами (составной и ее компонент), на самом деле не характерно для "композиции", потому что мы можем иметь такие зависимости из-за ссылочной целостности и в других типах ассоциаций.

Например, следующий шаблон кода для "композиции" был предложен в SO-ответе:

final class Car {    
  private final Engine engine;

  Car(EngineSpecs specs) {
    engine = new Engine(specs);
  }

  void move() {
    engine.work();
  }
}

Респондент утверждал, что для "состава" было бы характерно, чтобы никакой другой класс не мог ссылаться на компонент или знать его. Однако это, безусловно, не относится ко всем возможным случаям "композиции". В частности, в случае автомобильного двигателя, изготовитель автомобиля, возможно, реализованный с помощью другого класса, может ссылаться на двигатель, чтобы иметь возможность связаться с владельцем автомобиля всякий раз, когда возникает проблема с ним.

[1] http://www.learncpp.com/cpp-tutorial/103-aggregation/

Приложение - неполный список часто задаваемых вопросов о композиции и агрегации на Qaru

[апрель 2009 г.]
Агрегация против состава [закрыто как основанное на мнении]
[апрель 2009 г.]
В чем разница между Композицией и Ассоциацией? [май 2009 г.]
Разница между ассоциацией, агрегацией и составом
[май 2009 г.]
В чем разница между составом и агрегацией? [дубликат]
[октябрь 2009 г.]
В чем разница между агрегацией, составом и зависимостью? [помечен как дубликат]
[ноябрь 2010 г.]
Ассоциация против агрегации [помечено как дубликат]
[август 2012 г.]
Разница в реализации между Агрегацией и Композицией в Java
[февраль 2015]
UML - ассоциация или агрегация (простые фрагменты кода)

Ответ 9

Ассоциация

Ассоциация представляет взаимосвязь между двумя классами. Она может быть однонаправленной (в одну сторону) или двунаправленной (двухсторонней).

например:

однонаправленный

Клиент размещает заказы

двунаправленным

A женат на B

B женат на A

Агрегация

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

например:

У клуба есть члены

Клуб ( "весь" ) состоит из нескольких членов клуба ( "части" ). У члена есть жизнь вне клуба. Если клуб ( "целое" ) должен был умереть, члены ( "части" ) не умерли бы вместе с ним. Поскольку член может принадлежать нескольким клубам ( "целые" ).

Состав

Это более сильная форма агрегации. "Целый" несет ответственность за создание или уничтожение своих "частей"

Например:

В школе есть отделы

В этом случае школа ( "целая" ) должна была умереть, отдел ( "части" ) умрет вместе с ней. Потому что каждая часть может принадлежать только одному "целому".

Ответ 10

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

ассоциация

Самый абстрактный способ описать статические отношения между классами - это использовать ссылку "Ассоциация", которая просто утверждает, что существует какая-то связь или зависимость между двумя классами или более.

Слабая Ассоциация

ClassA может быть связан с ClassB для того, чтобы показать, что один из его методов включает параметр экземпляра ClassB или возвращает экземпляр ClassB.

Сильная Ассоциация

ClassA также может быть связан с ClassB, чтобы показать, что он содержит ссылку на экземпляр ClassB.

Агрегация (Общая Ассоциация)

В тех случаях, когда существует частичная взаимосвязь между ClassA (целым) и ClassB (частичным), мы можем быть более конкретными и использовать ссылку агрегации вместо ссылки ассоциации, подчеркивая, что ClassB также может агрегироваться другими классами в приложении ( поэтому агрегация также называется общей ассоциацией).

Важно отметить, что ссылка агрегации ни в коем случае не указывает, что ClassA владеет ClassB, и что между ними есть родительско-дочерние отношения (когда родитель удалил все его дочерние элементы, удаляемые в результате). На самом деле, совсем наоборот! Ссылка агрегации обычно используется для подчеркивания того факта, что ClassA не является эксклюзивным контейнером ClassB, поскольку на самом деле ClassB имеет другой контейнер.

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

Мартин Фаулер предлагает, чтобы ссылка агрегации вообще не использовалась, потому что она не имеет добавленной стоимости и нарушает последовательность, цитируя Джима Рамбо "Думайте об этом как о плацебо для моделирования".

Композиция (Не разделяемая ассоциация)

Мы должны быть более конкретными и использовать композиционную ссылку в тех случаях, когда в дополнение к частичной взаимосвязи между ClassA и ClassB - существует сильная зависимость жизненного цикла между ними, что означает, что когда ClassA удаляется, ClassB также удаляется в результате

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

В отличие от ассоциации и агрегации, при использовании отношения составления составной класс не может отображаться как тип возвращаемого значения или тип параметра составного класса. Таким образом, изменения в составленном классе не могут распространяться на остальную часть системы. Следовательно, использование композиции ограничивает рост сложности по мере роста системы.

Измерительная система сложности

Сложность системы можно измерить, просто взглянув на диаграмму классов UML и оценив линии связей, агрегации и композиции. Способ измерения сложности состоит в том, чтобы определить, сколько классов может быть затронуто изменением определенного класса. Если класс A предоставляет класс B, то на любой данный класс, который использует класс A, теоретически могут повлиять изменения в классе B. Сумма числа потенциально затронутых классов для каждого класса в системе равна общей сложности системы.

Вы можете прочитать больше в моем блоге: http://aviadezra.blogspot.com/2009/05/uml-association-aggregation-composition.html

Ответ 11

Композиция (при удалении "целого" "часть" также удаляется автоматически - "Владение")

Создайте объекты вашего существующего класса внутри нового класса. Это называется композицией, потому что новый класс состоит из объектов существующих классов.
Обычно используют обычные переменные-члены.
Может использовать значения указателя, если составной класс автоматически обрабатывает распределение/освобождение, ответственное за создание/уничтожение подклассов.

Композиция в C++

#include <iostream>
using namespace std;
/********************** Engine Class ******************/
class Engine
{
    int nEngineNumber;
    public:
    Engine(int nEngineNo);
    ~Engine(void);
};
Engine::Engine(int nEngineNo)
{
    cout<<" Engine :: Constructor " <<endl;
}
Engine::~Engine(void)
{
    cout<<" Engine :: Destructor " <<endl;
}
/********************** Car Class ******************/
class Car
{
    int nCarColorNumber;
    int nCarModelNumber;
    Engine objEngine;
    public:
    Car (int, int,int);
    ~Car(void);
};
Car::Car(int nModelNo,int nColorNo, int nEngineNo):
nCarModelNumber(nModelNo),nCarColorNumber(nColorNo),objEngine(nEngineNo)
{
    cout<<" Car :: Constructor " <<endl;
}
Car::~Car(void)
{
    cout<<" Car :: Destructor " <<endl;
    Car
    Engine
    Figure 1 : Composition
}
/********************** Bus Class ******************/
class Bus
{
    int nBusColorNumber;
    int nBusModelNumber;
    Engine* ptrEngine;
    public:
    Bus(int,int,int);
    ~Bus(void);
};
Bus::Bus(int nModelNo,int nColorNo, int nEngineNo):
nBusModelNumber(nModelNo),nBusColorNumber(nColorNo)
{
    ptrEngine = new Engine(nEngineNo);
    cout<<" Bus :: Constructor " <<endl;
}
Bus::~Bus(void)
{
    cout<<" Bus :: Destructor " <<endl;
    delete ptrEngine;
}
/********************** Main Function ******************/
int main()
{
    freopen ("InstallationDump.Log", "w", stdout);
    cout<<"--------------- Start Of Program --------------------"<<endl;
    // Composition using simple Engine in a car object
    {
        cout<<"------------- Inside Car Block ------------------"<<endl;
        Car objCar (1, 2,3);
    }
    cout<<"------------- Out of Car Block ------------------"<<endl;
    // Composition using pointer of Engine in a Bus object
    {
        cout<<"------------- Inside Bus Block ------------------"<<endl;
        Bus objBus(11, 22,33);
    }
    cout<<"------------- Out of Bus Block ------------------"<<endl;
    cout<<"--------------- End Of Program --------------------"<<endl;
    fclose (stdout);
}

Выход

--------------- Start Of Program --------------------
------------- Inside Car Block ------------------
Engine :: Constructor
Car :: Constructor
Car :: Destructor
Engine :: Destructor
------------- Out of Car Block ------------------
------------- Inside Bus Block ------------------
Engine :: Constructor
Bus :: Constructor
Bus :: Destructor
Engine :: Destructor
------------- Out of Bus Block ------------------
--------------- End Of Program --------------------

Агрегирование (если удалить "весь", "Часть" может существовать - "Нет собственности")

Агрегация - это особый тип композиции, где не подразумевается право собственности между сложным объектом и подобъектами. Когда агрегат уничтожается, подобъекты не уничтожаются.
Обычно используют переменные-указатели/ссылочные переменные, которые указывают на объект, который находится вне области действия агрегатного класса.
Может использовать ссылочные значения, которые указывают на объект, который находится за пределами области действия агрегатного класса.
Не несет ответственности за создание/уничтожение подклассов

Код агрегации в C++

#include <iostream>
#include <string>
using namespace std;
/********************** Teacher Class ******************/
class Teacher
{
    private:
    string m_strName;
    public:
    Teacher(string strName);
    ~Teacher(void);
    string GetName();
};
Teacher::Teacher(string strName) : m_strName(strName)
{
    cout<<" Teacher :: Constructor --- Teacher Name :: "<<m_strName<<endl;
}
Teacher::~Teacher(void)
{
    cout<<" Teacher :: Destructor --- Teacher Name :: "<<m_strName<<endl;
}
string Teacher::GetName()
{
    return m_strName;
}
/********************** Department Class ******************/
class Department
{
    private:
    Teacher *m_pcTeacher;
    Teacher& m_refTeacher;
    public:
    Department(Teacher *pcTeacher, Teacher& objTeacher);
    ~Department(void);
};
Department::Department(Teacher *pcTeacher, Teacher& objTeacher)
: m_pcTeacher(pcTeacher), m_refTeacher(objTeacher)
{
    cout<<" Department :: Constructor " <<endl;
}
Department::~Department(void)
{
    cout<<" Department :: Destructor " <<endl;
}
/********************** Main Function ******************/
int main()
{
    freopen ("InstallationDump.Log", "w", stdout);
    cout<<"--------------- Start Of Program --------------------"<<endl;
    {
        // Create a teacher outside the scope of the Department
        Teacher objTeacher("Reference Teacher");
        Teacher *pTeacher = new Teacher("Pointer Teacher"); // create a teacher
        {
            cout<<"------------- Inside Block ------------------"<<endl;
            // Create a department and use the constructor parameter to pass the teacher to it.
            Department cDept(pTeacher,objTeacher);
            Department
            Teacher
            Figure 2: Aggregation
        } // cDept goes out of scope here and is destroyed
        cout<<"------------- Out of Block ------------------"<<endl;
        // pTeacher still exists here because cDept did not destroy it
        delete pTeacher;
    }
    cout<<"--------------- End Of Program --------------------"<<endl;
    fclose (stdout);
}

Выход

--------------- Start Of Program --------------------
Teacher :: Constructor --- Teacher Name :: Reference Teacher
Teacher :: Constructor --- Teacher Name :: Pointer Teacher
------------- Inside Block ------------------
Department :: Constructor
Department :: Destructor
------------- Out of Block ------------------
Teacher :: Destructor --- Teacher Name :: Pointer Teacher
Teacher :: Destructor --- Teacher Name :: Reference Teacher
--------------- End Of Program --------------------

Ответ 12

Связь между двумя объектами называется ассоциацией.

Ассоциация известна как состав, когда один объект владеет другим.

Хотя ассоциация известна как агрегация, когда один объект использует другой объект.

Ответ 13

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

Я собираюсь основываться на некоторых кратких чтениях многих сообщений о SO и некоторых документах UML, что есть 4 основные конкретные формы ассоциации классов:

состав: A составлен из B; B не существует без A, как комната в доме
агрегация: A имеет-a B; B может существовать без A, как ученик в классе.
зависимость: A использует-a B; нет зависимости жизненного цикла между A и B, как параметр вызова метода, возвращаемое значение или временное, созданное во время вызова метода
обобщение: A is-a B

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

Я предполагаю, что "общая ассоциация" предназначена для использования в основном в двух обстоятельствах:

когда детали отношений все еще разрабатываются; такая связь на диаграмме должна быть как можно скорее преобразована в то, что она на самом деле есть/будет (одна из остальных 4).
когда отношение не соответствует ни одному из этих 4, заранее определенных UML; "общая" ассоциация по-прежнему дает вам способ представления отношения, которое "не является одним из других", так что вы не застреваете, используя неправильную связь с запиской "это не на самом деле агрегация, это просто то, что UML не имеет другого символа, который мы могли бы использовать"

Ответ 14

Я думаю, что эта ссылка сделает вашу домашнюю работу: http://ootips.org/uml-hasa.html

Чтобы понять термины, я помню пример из первых дней программирования:

Если у вас есть объект "шахматная доска", который содержит объекты "ящика", который является композицией, потому что, если "шахматная доска" удалена, больше нет причин для того, чтобы ящики существовали больше.

Если у вас есть "квадратный" объект, имеющий "цветной" объект, и квадрат удаляется, "цветной" объект все еще может существовать, то есть агрегация

Они оба являются ассоциациями, главное отличие - концептуальное

Ответ 15

Состав: Это когда вы уничтожаете объект (Школа), другой объект (классные комнаты), который связан с ним, тоже будет уничтожен. Оба они не могут существовать независимо.

Агрегация: Это как раз противоположная вышеприведенная (Composition) ассоциация, где, когда вы убиваете объект (Company), другой объект (Employees), который связан с ним, может существовать сам по себе.

Ассоциация.
Состав и агрегация являются двумя формами ассоциации.

Ответ 16

Ассоциация Мы называем ассоциацией те отношения, объекты которых имеют независимый жизненный цикл и где нет собственности между объектами.

Возьмем пример учителя и ученика. Несколько учеников могут общаться с одним учителем, а один ученик может общаться с несколькими учителями, но оба имеют свои жизненные циклы (оба могут быть созданы и удалены независимо); поэтому, когда учитель покидает школу, нам не нужно удалять учеников, и когда ученик покидает школу, нам не нужно удалять учителей.

Агрегация Мы называем агрегацию теми отношениями, объекты которых имеют независимый жизненный цикл, но есть право собственности, а дочерние объекты не могут принадлежать другому родительскому объекту.

Возьмем пример сотового телефона и аккумулятора сотового телефона. Одна батарея может принадлежать телефону, но если телефон перестает работать, и мы удаляем его из нашей базы данных, батарея телефона не будет удалена, потому что она все еще может функционировать. Таким образом, при агрегации, когда есть собственность, объекты имеют свой собственный жизненный цикл.

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

Давайте рассмотрим пример отношений между вопросами и ответами. Отдельные вопросы могут иметь несколько ответов, а ответы не могут принадлежать нескольким вопросам. Если мы удалим вопросы, ответы будут автоматически удалены.

Ответ 17

Я хотел бы проиллюстрировать, как три условия реализованы в Rails. ActiveRecord вызывает любые отношения между двумя моделями association. При чтении документации или статей, связанных с ActiveRecord, не часто встречались термины composition и aggregation. Связь создается добавлением одного из макросов класса ассоциации в тело класса. Некоторые из этих макросов: belongs_to, has_one, has_many и т.д.

Если мы хотим установить composition или aggregation, нам нужно добавить belongs_to в принадлежащую ему модель (также называемую дочерним) и has_one или has_many к модели-владельцу (также называемой родительской). Wether, который мы установили composition или aggregation, зависит от параметров, которые мы передаем в вызов belongs_to в дочерней модели. До Rails 5, настроив belongs_to без каких-либо параметров, созданных aggregation, ребенок мог существовать без родителя. Если бы мы хотели composition, нам нужно было явно объявить это, добавив опцию required: true:

class Room < ActiveRecord::Base
  belongs_to :house, required: true
end

В Rails 5 это было изменено. Теперь, объявив, что ассоциация belongs_to создает composition по умолчанию, ребенок не может существовать без родителя. Таким образом, приведенный выше пример можно переписать следующим образом:

class Room < ApplicationRecord
  belongs_to :house
end

Если мы хотим разрешить дочерний объект существовать без родителя, нам нужно объявить это явно с помощью опции optional

class Product < ApplicationRecord
  belongs_to :category, optional: true
end

Ответ 18

    Simple rules:
    A "owns" B = Composition : B has no meaning or purpose in the system 
    without A
    A "uses" B = Aggregation : B exists independently (conceptually) from A
    A "belongs/Have" B= Association; And B exists just have a relation
    Example 1:

    A Company is an aggregation of Employees.
    A Company is a composition of Accounts. When a Company ceases to do 
    business its Accounts cease to exist but its People continue to exist. 
    Employees have association relationship with each other.

    Example 2: (very simplified)
    A Text Editor owns a Buffer (composition). A Text Editor uses a File 
    (aggregation). When the Text Editor is closed,
    the Buffer is destroyed but the File itself is not destroyed.

Ответ 19

В очень простом предложении:
Агрегация и состав являются подмножествами ассоциации.

A использует B → это агрегация
А нужен Б → это композиция.

Узнайте больше здесь.

Ответ 20

Ясное понимание Ассоциации, Агрегация, Состав и другие отношения классов UML можно найти здесь Понимание отношений класса UML

Ответ 21

Ассоциация, агрегация и состав

Ассоциация, агрегация и композиция - это три вида отношений, которые могут иметь классы в объектно-ориентированном программировании. Давайте поймем разницу между ними.

1. Ассоциация на Яве

Мы называем ассоциацией те отношения, чьи объекты имеют независимый жизненный цикл и где между объектами нет права собственности.

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

2. Агрегация в Java

Мы называем агрегацию теми отношениями, чьи объекты имеют независимый жизненный цикл, но есть владение, и дочерние объекты не могут принадлежать другому родительскому объекту.

Давайте возьмем пример сотового телефона и аккумулятора сотового телефона. Одна батарея может принадлежать телефону, но если телефон перестает работать, и мы удаляем его из нашей базы данных, батарея телефона не будет удалена, потому что она все еще может функционировать. Таким образом, в совокупности, пока существует владение, объекты имеют собственный жизненный цикл.

3. Композиция на Java

Мы используем термин "состав" для обозначения отношений, чьи объекты не имеют независимого жизненного цикла, и если родительский объект будет удален, все дочерние объекты также будут удалены.

Давайте рассмотрим пример взаимосвязи между вопросами и ответами. Отдельные вопросы могут иметь несколько ответов, и ответы не могут принадлежать нескольким вопросам. Если мы удалим вопросы, ответы будут автоматически удалены.

4. Резюме

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

Ответ 22

От: Remo H. Jansen книга "Начало реакции: изучение TypeScript 2.x - второе издание":

Мы называем ассоциацией те отношения, чьи объекты имеют независимый жизненный цикл, в котором нет владения объектами. Давайте посмотрим на пример учителя и ученика. Несколько учеников могут быть связаны с одним учителем, а один ученик может быть связан с несколькими учителями, но оба имеют независимые жизненные циклы (оба могут создавать и удалять независимо). Поэтому, когда учитель покидает школу, нам не нужно удалять учеников, а когда ученик покидает школу, нам не нужно удалять учителей.

Мы называем агрегат теми отношениями, чьи объекты имеют независимый жизненный цикл, но есть владение, и дочерние объекты не могут принадлежать другому родительскому объекту. Давайте возьмем пример сотового телефона и аккумулятора сотового телефона. Одна батарея может принадлежать телефону, но если телефон перестает работать, и мы удаляем его из нашей базы данных, батарея телефона не будет удалена, потому что она все еще может функционировать. Таким образом, в совокупности, пока существует владение, объекты имеют свой жизненный цикл

Мы используем термин состав для обозначения отношений, чьи объекты не имеют независимого жизненного цикла, и если родительский объект будет удален, все дочерние объекты также будут удалены. Давайте возьмем пример взаимосвязи между вопросами и ответами. Отдельные вопросы могут иметь несколько ответов, и ответы не могут принадлежать нескольким вопросам. Если мы удалим вопросы, ответы будут автоматически удалены.