When one object has another object in it as a property and this other object is independent, this is called an aggregation relationship. Let's take the example in the previous section and try to see whether this was an aggregation relationship or not.

The previous example looked at the relationship between a car and an engine. We all know that a car must have an engine, and that is why an engine is the property of a car, as shown in the following code:

public class Car {
    public Engine Engine { get; set; }
    // Other properties and methods
}

Now the question is, what is this type of relationship? The deciding factor is that an engine is a separate object that functions independently of a car. When the manufacturer creates an engine, they don't make it when they are creating the other parts of the car: they can create it separately. Even without a car, an engine can be tested or even used for another purpose. Consequently, we can say that the type of relationship that the car has with the engine is an aggregation relationship.

Now let's look at the example of our restaurant management software. If we analyze the relationship between the Food and Chef objects, it is clear that no food can exist without a chef. Someone has to cook, bake, and prepare the food, the food cannot do this itself. Consequently, we can say that the food has a chef. This means that the Food object should have a property named Chef, which will hold the Chef object of that Food. Let's look at the code for this relationship:

public class Food {
    public int? FoodId {get;set;}
    public string Name { get; set; }
    public string Price { get; set; }
    public Chef Chef { get; set; }
}

If we think about the Beverage object, every beverage must have a company or maker. For example, commercial beverages are made by companies such as Pepsi Co., Coca Cola Company, and so on. The beverages that these companies produce are their legal property. Beverages can also be made locally, in which case the company name would be the name of the local shop. However, the main idea here is that a beverage must have a manufacturer company. Let's see how the Beverage class would look in code:

public class Beverage {
    public int? BeverageId {get;set;}
    public string Name { get; set; }
    public string Price { get; set; }
    public Manufacturer Manufacturer { get; set; }
}

In both of these examples, the Chef and Manufacturer objects are objects that are used as the property of Food and Beverage respectively. We also know that a Chef or a Manufacturer company is independent. Consequently, the relationship between Food and Chef is an aggregation relationship. This is also the case for Beverage and Manufacturer.

To make things clearer, let's look at another example of aggregation. Our computer that we use for programming or for any other task is made up of different components. We have a motherboard, RAM, CPU, graphics card, screen, keyboard, mouse, and many other things. Some components have an aggregation relationship with the computer. For example, the motherboard, RAM, and CPU are internal components that are needed to build a computer. All of these components can exist independently of the computer, and consequently, all of these have aggregation relationships with the computer. Let's look at how the Computer class is related to the MotherBoard class in the following code:

public class Computer {
    public int Id { get; set; }
    public string ModelNumber { get; set; }
    public Company Manufacturer { get; set; }
    public Ram Ram { get; set; }
    public MotherBoard MotherBoard { get; set; }
    public CPU CPU { get; set; }
}

public class Ram {
    // Ram properties and methods
}

public class CPU {
    // CPU properties and methods
}

public class MotherBoard {
    // MotherBoard properties and methods
}

Now, let's see how the aggregation relationship is drawn in a UML diagram. If we try to display the preceding computer class aggregation relationship with the RAM, CPU, and motherboard, then it would look something like the following:

A solid line and a diamond are used to represent an aggregation relationship. The diamond is placed at the side of the class that holds the property, as shown in the following diagram: