Dependency → Association → Aggregation → Composition. UML Relationships Explained

The connections between classes in a UML class diagram are called relationships.

Examples include association, inheritance, composition and so on. Now

inheritance and implementation implementing interfaces are taxonomic relationships that describes hierarchy.

If B inherits from A, then B is A plus more. Taxonomic relationships are design

more. Taxonomic relationships are design time relationships. They are designed in

time relationships. They are designed in code and they are permanent. Now on the other hand there are association, aggregation and composition. They

describe how objects relate to each other in terms of reference and ownership and life cycle. These

relationships are also designed at design time but manifest themselves at runtime through object instances.

Now the first relationship we are going to look at is dependency.

Underneath of all the other relationships is the dependency relationship. Every other relationship

relationship. Every other relationship implies dependency. When object A has a

implies dependency. When object A has a relationship with object B, object A depends on object B. Now, this is what

it looks like in a UML class diagram. It

is easy to spot in a module file. Now,

here is main.py.

Module main has a dependency on daytime.

Now, since daytime is a different module file, we say that main has a source code dependency on daytime. Now look at this

main class employee is defined and instantiated. You are looking at two

instantiated. You are looking at two modules the class and the rest of the code in main. Main depends on the employee module. Since they are in the

employee module. Since they are in the same module file, there is no need to import anything. Now what happens when

import anything. Now what happens when class employee is moved to employee.py?

Maine must now import employee.

Maine now has a source code dependency on the employee module.

Interesting. Now there are more situations that require dependencies on employee. Here is module report.py with

employee. Here is module report.py with

class report.

The print employee method takes an employee and prints it. Since Python

does not require static types in the code, there is no need to import employee. But even if there is no source

employee. But even if there is no source code dependency on employee, there is still a runtime dependency at runtime on employee. You can check this. Every

employee. You can check this. Every

Python developer knows what would happen if you send wrong objects to methods.

The code will likely crash at runtime.

But Python supports type annotations which make these dependencies visible in the code. Once I annotate employee, I

the code. Once I annotate employee, I have to import the employee module and I'll use type annotations from now. Now

what you just saw are dependencies.

Module A depends on module B. Nothing

more. The second type of relationship we're going to look at is the association.

When the employee object is used in more places in the reporting module, it might be a good idea to store it in the object.

The report module still depends on employee but it does more. It stores a reference to an instance of it. Now this

is known as association and it looks like this in the UML. Now association

does not prescribe how a report gets an employee. It only states that report has

employee. It only states that report has a reference to employee at runtime. Now

in 99% of my code I would do this through dependency injection in the class initializer. Now so far you've

class initializer. Now so far you've seen dependency and on top of that association.

And here is where things get a bit confusing. When object A stores a

confusing. When object A stores a reference to object B, UML classifies this as an association.

However, developers often colloquially say that object A is composed of everything inside object A plus the

things in B. In this informal usage, composition refers to the act of building an object out of multiple

parts, not to UML composition, which has a stricter whole part and life cycle meaning. Now, the multiple meanings of

meaning. Now, the multiple meanings of composition are a frequent source of confusion in design discussions among developers and we need to differentiate

between them. When objects store

between them. When objects store references to other objects in UML known as association, we will speak of

technical composition. Now the next step

technical composition. Now the next step in our relation is aggregation depicted with the open diamond. Aggregation

requires a dependency and a stored reference. But if that was also the case

reference. But if that was also the case with association, then what is the difference between them? To answer this question, let me show you three

aggregation examples. Example one could

aggregation examples. Example one could be a department has employees. Another

example could be a playlist has songs.

And yet another example is a folder has files.

Now let me give you three association examples. Now a mill client has a

examples. Now a mill client has a logger. A user has a session or a user

logger. A user has a session or a user service has a user repository.

Do you notice the difference with association? Two objects collaborate in

association? Two objects collaborate in a technical way. A mill client uses a logger. A user service requires a user

logger. A user service requires a user repository. But these collaborations are

repository. But these collaborations are technical. They are probably unknown to

technical. They are probably unknown to the user of the software. Now in

contrast, aggregation describes domain relationships. For example, a department

relationships. For example, a department has employees or a playlist has songs.

Such relationships are often visible in the UI of the application. A technical

relationship with a logger is hopefully invisible to the user of the software.

Now dependency association aggregation, if this all starts to dazzle you, and I certainly know it did to me when I first looked into all this,

you're in good hands because what I did is I gathered all this information and put it in a nice ebook for you. Now, the

link is in the description and I recommend you download it and memorize it because it will help you with your next discussion during design meetings.

Back to the tutorial. Okay, we're almost done, I promise. So, dependency,

association, aggregation, and on top of that is composition. Since we already saw there is such a thing as technical composition, I will explicitly call this

UML composition. Now, just like

UML composition. Now, just like aggregation, it describes a whole part relationship. But with aggregation, an

relationship. But with aggregation, an object does not create its own dependencies. Instead, it receives them

dependencies. Instead, it receives them and stores them in a reference. Now, UML

composition does things differently.

First, let me show you what it looks like. With UML composition, object A

like. With UML composition, object A creates object B. This implicates that object A also is responsible for the

life cycle of object B. Once A is destroyed, B will also be destroyed. A good example of this is an HTML document.

To build this document in code, you need objects that act as nodes and leaves.

Simply put, nodes store children and leaves store text. The root of the object tree is an object of type HTML.

What happens when this object is destroyed? All child objects must also

destroyed? All child objects must also be destroyed. There is no conceptual

be destroyed. There is no conceptual reason for a body, heading or paragraph to exist without an HTML container. Now

let me give you an overview of common UML relationships. There is realization,

UML relationships. There is realization, inheritance dependency association aggregation and UML composition. Now we

have focused on dependency which is the underlying relationship of all the UML relationships and association aggregation and composition which focus

on runtime behavior. There's only one more thing that I'd like to say and that is about cardality. A common pitfall during UML relationship classification

is taking cardality into account.

Cardinality specifies the number of instances that one class could be related with to another class. For

example, one to one or one to many or many to many. These number

specifications do not affect the semantic strength of the relationship.

If you made it so far in this video, let me tell you again. I put all this in an ebook and you can download it with the link in the description. I hope this helped you.