This is really helpful video to understand the difference between the relationships of classes. Watched so many videos before this one, but this is the best match!! MUST WATCH!!!
The video clearly explained how the association relationship evolved into aggregation and association relationships, and the drawing of the symbols, and the difference between class and object relationships. I watched many videos before and read a lot of articles, but each time I got more confusion as I watch/read, very frustrated. finally, I got it all figured out. To make your video more complete, it would be nice if you could add some real code along with the video. After all we want to code. Thank you.
On the last example at 9:09, there's a mistake on the relationship between the SubAcnt and the SavingAccount objects as the SubAcnt objects appear containing the SavingsAccount object, but it should be the other way around, with the filled diamond on the SavingsAccount side.
@@geekific Thanks for the reply and, of course, for the content of your video! I like very much the way you explain things! Sorry I wasn't careful enough to check if there was any comment on that error, I did a quick search and didn't see anything about that loaded on the top comments at least so I decided to leave that message. I've been researching this topic lately, I've learned a lot and redefined many concepts I thought I understood already.
I believe there is something wrong with the object diagram show case appers at 9:26 regarding to the relationship directions between subaccounts and bandaccounts.
Great content! Are the composition associations from the SavingsAccount to the SubAcnt backwards? I thought the filled in diamond node at the end of the association was supposed to be connected to the more generalized container
Thanks :) Ohh, at the very end in Object Diagrams, it's direction should be exactly the way it was while explaining Class Diagrams. Kudos to you, well done
I have a different opinion that except inheritance others like association aggregation and composition talks about object relationship. Where Inheritance is all about relationship between classes.
This is an amazing explanation, and the result is that I'm able to highlight a mistake in the Object Diagram when aggregating SavingsAccount to SubAcnt. In fact, the diamond shape must be towards SavingsAccount because this SavingsAccount is a container for SubAcnt, just like Customer, which is a container for BankAccount. Regards
I learnt about a dotted line notation with open arrow at the end, which denotes dependency. I am unable to understand what is the difference between dependency and association. Like, With your example, Customer class has a method for subscribing to BankEvent. So Customer has an association with BankEvent, at the same time, Customer is dependent on BankEvent. Isn't that always the case????
Good question! A class is associated with another whether it has it as an attribute / property or no. If it is an attribute, then it either falls under aggregation or composition as explained in the video, if not (if it is only used as a method parameter or return type etc.) then it is a dependency. Hope this helps :)
Multiplicity wasn't explained very well. Allow me to clarify: The multiplicity attached to each class indicates how many instances of that class can be aggregated-by/composed-by/associated-with a *single* object of the other class. For example, the relationship @4:53 says two things: (1) "0...N BankAccount(s) can be aggregated by each single Customer object" and (2) "There is exactly 1 Customer object for each single BankAccount object". Similarly, @7:23 (1) "0...N BankEvent is associated with a single Customer object (i.e., a Customer can attend 0 or more BankEvents)" and (2) "0...N Customer is associated with a single BankEvent (i.e., Each BankEvent can have 0 or more Customer(s))"
Thank you for the great video. I am struggling with the banccount class and the subclasses. As you did the object diagram there was no bank account obejects only savingaccoubt and milesaccount object. Is backaccount an interface or abstraxt class? Customer has a list of Bankaccoubt how it will work with saving accounts and milesaccount because its not the same type. I am honest great uml explanation but i am confused af 😢. Can you explain it? I would love it if you could explain whrn to use inheritance or Interface? Thank u Update: ok, Bankaccoubt is an abstraxt class so we can create instance of the the inplementation as Saving Account and Milesaccount. Can we use only base and subclasses instead of interface and implementing classes? Plz do an video 😵💫 I am for the first time really confused.
@@geekific yes, thats the first Question, second is what if we use only inheritance for bankaccoubt and the subclasses? Will it work? If not what is the scenario of using inheritance and not abstraction? Thanks
Thanks for the video. But regarding that association between BankEvent and Customer. Point is why did you decide to relate BankEvent to the Customer at all? I would create a Bank - class and relate it to the Bank (as a composition, cause event can't exist without a bank).. For me the question of necessity of having an "association" option remains unclear. Could you make maybe another example where havng "association" in unavoidable?
Great video. I have a question regarding aggregation. So how do we determine the place of the "diamond symbol"?. If the diamond is placed at the "customer class", does it mean that a customer has a bankaccount or a bankaccount has a customer? It is probably a bad example here since both things are possible...
Yes it is, in the object diagram it is switched, I can't fix the video but because it is not the first comment addressing this, I will add it as a note in the description :) Cheers!
@Geekific on second thought about the last example, is not right eventually we have to break down many -to -many to one- to -many and we need a middle table
@@mehdi-vl5nn You are thinking about it from a DB perspective! But to answer your question, the relation between the middle table and each entity in this case will be one to many, but what about the two outer entities linked via the linking table? it is still a many to many, and that is what we are trying to explain here:) Hope this helps! Cheers!
There is a relation between the two as action is being taken by the Customer when provided with an Event, so, it does know stuff about the event and act upon them but it is not storing these event, it is not a *container* for these events and hence it is not an Aggregation, that was the whole point :) Hope this answers your question!
Sorry to read that :/ I'll be more than happy to answer any question you may have in the comments section :) Do you mind pointing which parts/topics specifically were confusing to you so we may improve it in future videos? Thanks for your feedback :) Cheers!
I honestly believe that everyone having troubles to understand relationships should watch this video. It helped me a lot! Thank you
😊
Maybe the best content on this topic in the entire youtube. Very Comprehensive Video. Thanks Geekific.
I have been trying to understand where to use associations by watching tutorials for an hour and 10' now. Finally I understand. Thank you!
This is really helpful video to understand the difference between the relationships of classes. Watched so many videos before this one, but this is the best match!! MUST WATCH!!!
This is the only video lecture where I clearly understood class relations 😭😭😭... Thank you very much ❤️❤️❤️
greatest video of uml class model
you have the best teaching skill among the youtubers i've watched , keep it up bro ....!
The video clearly explained how the association relationship evolved into aggregation and association relationships, and the drawing of the symbols, and the difference between class and object relationships. I watched many videos before and read a lot of articles, but each time I got more confusion as I watch/read, very frustrated. finally, I got it all figured out. To make your video more complete, it would be nice if you could add some real code along with the video. After all we want to code. Thank you.
10 minutes of effective knowledge. Thanks to you and UA-cam algo for bringing your videos to me which keeps me updated with these information.
So nice of you! It's my pleasure man :)
Best explanation I've heard on this topic. I don't think ever really understood it until now.
Like trump says, it was the best of the best tut on this topic. Finally grasp the concept with clarity.
Thank you for taking the time to record this. It was really helpful.
On the last example at 9:09, there's a mistake on the relationship between the SubAcnt and the SavingAccount objects as the SubAcnt objects appear containing the SavingsAccount object, but it should be the other way around, with the filled diamond on the SavingsAccount side.
Yup, thanks for sticking till the end! Was mentioned multiple times in the comments :)
@@geekific Thanks for the reply and, of course, for the content of your video! I like very much the way you explain things! Sorry I wasn't careful enough to check if there was any comment on that error, I did a quick search and didn't see anything about that loaded on the top comments at least so I decided to leave that message. I've been researching this topic lately, I've learned a lot and redefined many concepts I thought I understood already.
I am so happy you found our videos helpful :) On the contrary thanks for mentioning it, you're helping a lot :D
Very helpful video. I watched it once and got the concept.
I believe there is something wrong with the object diagram show case appers at 9:26 regarding to the relationship directions between subaccounts and bandaccounts.
I also noticed, small mistake
Yes! It is noted in the description, sorry about that.
@@geekific Nice. Thanks for the well designed tutorial!👍
Super explanation with the much needed humor!
Glad it helped!
Great content! Are the composition associations from the SavingsAccount to the SubAcnt backwards? I thought the filled in diamond node at the end of the association was supposed to be connected to the more generalized
container
Thanks :) Ohh, at the very end in Object Diagrams, it's direction should be exactly the way it was while explaining Class Diagrams. Kudos to you, well done
7:50 How on earth Customer have relation and knowing when Bank Event without have anything about Bank Event?
Thank you for explaining so clearly.😊
Excellent! This is the best description of the arrows~
I have a different opinion that except inheritance others like association aggregation and composition talks about object relationship. Where Inheritance is all about relationship between classes.
Why do the diamond arrows point in different directions in classes (6:30 min) and objects (9:20 min)?
Are you referring to the "correction" mentioned in the description?
This is an amazing explanation, and the result is that I'm able to highlight a mistake in the Object Diagram when aggregating SavingsAccount to SubAcnt. In fact, the diamond shape must be towards SavingsAccount because this SavingsAccount is a container for SubAcnt, just like Customer, which is a container for BankAccount.
Regards
Wonderful explanation 😄. Keep producing more of these content with us 💟
Thank you so much. It helps me have a clear understanding about relationships.
you are really doing a good job here .
Thanks a lot! Glad it was helpful!
By hierarchical relationship
sub class can not exist without super class it is same as composite aggregation ???
This is gold.
I learnt about a dotted line notation with open arrow at the end, which denotes dependency. I am unable to understand what is the difference between dependency and association. Like, With your example, Customer class has a method for subscribing to BankEvent. So Customer has an association with BankEvent, at the same time, Customer is dependent on BankEvent. Isn't that always the case????
Good question! A class is associated with another whether it has it as an attribute / property or no. If it is an attribute, then it either falls under aggregation or composition as explained in the video, if not (if it is only used as a method parameter or return type etc.) then it is a dependency. Hope this helps :)
wow literally wonderful
u just helped me to pass my test.....thanks alot !!!
Glad I could help! All the best :)
You're a life saver bro 🙌
Really amazing job with the explanation!
Thank you! Glad it helped!
Thanks for helping me with my software technology program
Glad I could help :)
In the last object diagram, aren't the composition arrows inverted?
Yes! It is noted in the description, sorry about that.
Thank you. Blessings
Great video 👍, it explained a lot to me, but I miss converting UML to code to see what the code looks like digested with such a diagram.
Thanks! Great idea, will try to cover it in an upcoming video :)
Multiplicity wasn't explained very well. Allow me to clarify:
The multiplicity attached to each class indicates how many instances of that class can be aggregated-by/composed-by/associated-with a *single* object of the other class.
For example, the relationship @4:53 says two things: (1) "0...N BankAccount(s) can be aggregated by each single Customer object" and (2) "There is exactly 1 Customer object for each single BankAccount object". Similarly, @7:23 (1) "0...N BankEvent is associated with a single Customer object (i.e., a Customer can attend 0 or more BankEvents)" and (2) "0...N Customer is associated with a single BankEvent (i.e., Each BankEvent can have 0 or more Customer(s))"
When Object diagram is formed, where is Bank aount lass is gone? WHY is it not there in Objet Diagram
Because you create objects based on implementations and not abstractions!
shouldn't the object diagram at 9:18 be bankAcc: milesAccount not milesAcc : milesAccount?
Thanks for pointing that out! This was actually mentioned as part of the description! Cheers :)
my university lecturer is great but you really helped me understand this more
Glad I could help! :)
You're one of the very few people who admired the university lecturer along with the channel. That's nice!
nice one
ياعم انت جامد ياعم♥️
Thank you
Thanks a lot! Glad you liked it :)
Thank you for the great video. I am struggling with the banccount class and the subclasses. As you did the object diagram there was no bank account obejects only savingaccoubt and milesaccount object.
Is backaccount an interface or abstraxt class? Customer has a list of Bankaccoubt how it will work with saving accounts and milesaccount because its not the same type.
I am honest great uml explanation but i am confused af 😢.
Can you explain it? I would love it if you could explain whrn to use inheritance or Interface? Thank u
Update: ok, Bankaccoubt is an abstraxt class so we can create instance of the the inplementation as Saving Account and Milesaccount. Can we use only base and subclasses instead of interface and implementing classes? Plz do an video 😵💫 I am for the first time really confused.
Can you please clarify as to what is the confusing part exactly? Is it the difference between abstractions and interfaces?
@@geekific yes, thats the first Question, second is what if we use only inheritance for bankaccoubt and the subclasses? Will it work? If not what is the scenario of using inheritance and not abstraction? Thanks
Thank you so much, very clear explanation
Glad you liked it :)
very helpful for concepts on UML class and object diagram. I wonder how to represent method in object diagram, kind of value of method!
Glad it was helpful!
keep going , perfect explanation, thanks a lot
Thanks, will do! Glad it was helpful :)
How can bank account exist if there is no customer?
You are thinking about it from a real-world perspective, in the video we are doing this from an implementation / a technical perspective.
Thanks for the video. But regarding that association between BankEvent and Customer. Point is why did you decide to relate BankEvent to the Customer at all? I would create a Bank - class and relate it to the Bank (as a composition, cause event can't exist without a bank).. For me the question of necessity of having an "association" option remains unclear. Could you make maybe another example where havng "association" in unavoidable?
Thanks for the feedback, well received! We will try to answer these concerns in future videos. Stay Tuned!
Seems direction of subAccount direction might be pointed opposite in the Object daigram. Please correct me if i am wrong
Mentioned in the description!
@@geekific Thanks
nice explanation!
Great video. I have a question regarding aggregation. So how do we determine the place of the "diamond symbol"?. If the diamond is placed at the "customer class", does it mean that a customer has a bankaccount or a bankaccount has a customer? It is probably a bad example here since both things are possible...
Thanks! The "diamond symbol" is usually placed on the container class. Hope this answers it!
@@geekific yeah. Thanks!
Hi, cool video. I have one question tho: shouldn't it be a dependency relationship between Customer and BankAccount instead of an association one?
Thanks! Can you please elaborate? It is already set as an aggregation in the video.
Oh sorry, i meant BankEvent, not BankAccount.. didn't notice
The direction between subaccount and account is different in the two models...isn't it?
Yes it is, in the object diagram it is switched, I can't fix the video but because it is not the first comment addressing this, I will add it as a note in the description :) Cheers!
Great! Thank you so much
Glad you liked it :)
perfect explanation
Glad you think so!
@Geekific on second thought about the last example, is not right eventually we have to break down many -to -many to one- to -many and we need a middle table
@@mehdi-vl5nn You are thinking about it from a DB perspective! But to answer your question, the relation between the middle table and each entity in this case will be one to many, but what about the two outer entities linked via the linking table? it is still a many to many, and that is what we are trying to explain here:) Hope this helps! Cheers!
7:50 How on earth Customer have relation and knowing when Bank Event without have anything about Bank Event?
There is a relation between the two as action is being taken by the Customer when provided with an Event, so, it does know stuff about the event and act upon them but it is not storing these event, it is not a *container* for these events and hence it is not an Aggregation, that was the whole point :) Hope this answers your question!
Thank you so much!
No worries! Glad it helped :)
great thank u
Thanks! You're welcome :)
Thank you
My pleasure :)
nice video sir, thanks
Glad I could help!
Cool, man.
Thanks!
magnifique
In many to many association do we need to Define a new class?
Hello :) Am not sure I really got your question, can you please rephrase it? Sorry.
Tooo much confusing honestly .....
Sorry to read that :/ I'll be more than happy to answer any question you may have in the comments section :)
Do you mind pointing which parts/topics specifically were confusing to you so we may improve it in future videos? Thanks for your feedback :) Cheers!
are you Lebanese bro?
Yup