I'm trying to make a class diagram for an Online Auction System and I'm having this problem. Bids belong to both the Auction and the Buyer (Correct me if i'm wrong). So can I say that User is composed of bid AND auction is composed of Bid or is this against the rules of UML? I'm confused
In general
The term composition is ambiguous and this explains your confusion:
In OOP, object composition means to use an object in another one.
In UML, composition is a special kind of association that represents a part-whole relationship, with an exclusive ownership of the parts by the whole.
So in the UML sense, it is not possible to have an object that is part of two different compositions, because the ownership would no longer be exclusive. But you could use the object in several aggregations, which are a whole-part relations allowing a shared ownership.
In the OOP sense, there is no problem of having the same object used in (or using) several compositions. The object composition corresponds to a navigable UML association.
In your practical case
The situation is straight forward: A Bid has one Buyer, a Buyer may have several Bids, and an Auction has several Bids. You can model this with simple associations:
You could alternatively use an aggregation here, since one could argue that there is a whole-part relation between an Auction and the corresponding Bids (personally, I wouldn't see it like this):
You should however not see an aggregation on the other side, because there is no real whole-part relation between a Buyer and a Bid: a Buyer is not "made of several Bids".
Additional remarks
You could use also an association class here. But it's not required. And the semantic would be different: it would mean that there is a Bid association between a Buyer and an Auction:
Technically speaking, you'd still have three classes.
But the focus is different: the Bid is accessory to the Buyer and the Auction and cannot exist on its own (e.g. if the buyer disappears)
Have you learned about association classes in UML? They represent an object that is created from the relationship between two other classes, exactly what you are trying to map. There are plenty of contents detailing Association Classes (e.g. Correct use of an association class)
That way you shouldn't get confused reading the diagrams (which you were doing correctly btw), it would be clear to you that exists the entity Bid, which exists only associated to both Buyer and Auction.
I have been searching all over the internet and can't seem to find anything that specifically answers my question.
As far as I can tell, a simple association does not imply any form of life dependency.
A Composition is a whole-part relationship where the lives of the two classes are tied. For example, building and room. A room can not be created without a building, and if a building "dies", so does the room, and vice versa. BOTH are dependent on each other.
I do understand that aggregation is a weaker composition. For example, Car and Tires. But does aggregation imply dependence on the whole's side? Can the whole exist without the parts? Also, in aggregation, do the parts only belong to one whole?
I've found conflicting answers...
I have one more question. Can a simple association be a one-to-many relationship? For example, I am designing a prison management system, a PrisonBlock has Guards. If I say a guard is only assigned to one block. Their lives are obviously not dependent on each other. But there IS, however, a whole-part relationship. Or is there!? I'm confused. The way I see it, the Block (whole) has Guards (parts). Is this association or aggregation? And why? What would I have to change for it to become one or the other? Can an association even BE a one-to-many relationship!?
Aggregation is simply Has-a realtionship. In your example, Car should have tires . Because if it is not then that is not a Car. But Tires doesn't need to have car necessarily. Simply it is Has-a relationship.
2.Association is a relationship between two separate classes which can be of any type say one to one, one to may etc. It joins two entirely separate entities.
Aggregation is a special form of association which is a unidirectional one way relationship between classes (or entities)
THink like this:
If your prisonBlock class can exist without Guard class?
Or Guard class can exist without your prisonBlock class?
In compostion we create a opject which is defined in that class scope for example
class a:
b comObject = new b()
while in aggregation shows has a relation which means object has parent child kind of relationship but this do not means that when parent class die child also die because parent just make a deep copy
in case of association we only make a shallow copy and the differences between association and aggregation is that the related object can not have another parent
This is a silly question, but I seriously didn't find an answer...
I have a one-to-many relationship from the Entity Events to Discounts and I set a relationship like this in Xcode:
I need that relationship to be inverse, so I can check which Event a Discount is from, but in XCode I can only choose "No Inverse." How can I set that relationship to be inverse?!
If you have to do it programatically, first, seriously? It can't be done from XCode? Secondly, how can I do it? And where should this be done?
Thanks
To be able to set inverse relationship you need to create it first in destination entity.
So in Discounts entity create relationship to Event that you want to use as reverse (e.g. event), then you will be able to choose it as reverse for your toDiscounts relationship
Sorry if this sounds noob, this is something related to database design for inherited classes.
I have currently 2 type of user for registration on my system, member and staff. They both share some same property (i.e. name, dob, contact no) while possessing some unique property for their own usage (i.e. membership no for member, staff position for staff). Currently they both are stored as 2 different tables in the database and have no relation with each others.
I'm thinking now to create a entity called Person with all the common property while having a class call Member and another Staff that both extends the Person class in the system. However i'm having problem designing the database. Should there be a table called Person with a type property to denote the type of the person, or i should stick with the existing design where 2 tables that separate them?
It depends.
If you're not going to do polymorphic queries, I'd stick to the design you have right now.
This sort of design is called in literature "table per concrete class"
On the other hand if most of your queries are going to be like "give me all the people in the system regardless of whether they're a member or staff" you might want to put them all together into a single table called Person.
This sort of design is called "table per class hierarchy"
Obviously this mandates that all columns corresponding to properties of your inherited classes would have to be nullable in the database.
If that is not acceptable (I'm finding it hard to believe it would, but...) and for completeness you may end up with a three-class, three-table structure, which is unsurprisingly called "table per class"
There's no hard and fast rule for this, and while I generally tend to work with systems where table per class hierarchy makes the most sense, it may or may not be the case for you.
I am getting really confused about OOD when designing relatively large system. Always, we talk about has-a relationship between two entities. My question is about which one owns the other?
when designing a parking lot, there are many parking space. Should the car has an data field called parking space, or should the parking space hold the car? or both?
in a library reservation system, I am assuming there is a class Library, a class Book, and a class User. Shall the user call checkout(book), or the book call checkout(user), or the library call checkout(book, user)?
It's been very confusing for me. Any comment/suggestion is welcomed.
Lily
It depends on the situation, and what you mean by "own".
In your first example there is a one-one relationship between a car and a parking space. From a database perspective you will have to make a judgement about which should "own" the other (which table 'owns' the foreign key). You would base this judgement on expected usage - for example - since a parking space is likely to remain fixed, but you have cars coming and going all the time, it might make more logical sense for the carpark to "own" the car. That's where your design skills come into play.
In the second example, it seems to me that a single book can only be checked out to one user at a time, and "checking out" is an action that occurs on a book. Therefore the correct solution is Book.checkout(user). Building on that, a user is likely to checkout more than one book at a time, so I would be inclined to do have a checkout method on Library, such that Library.checkout(Books[], user) called Book.checkout(user) in turn.
For #1, the parking space should keep a record of if it is occupied and if so, what car is in it. Otherwise to see if you could park somewhere, you would have to poll every car to see if they are in that spot.
My immediate thinking for #2 is that it should be Library.checkout(Book, User) such that you make a note that a User has checked out a specific book.
This is heavily dependent on what you're trying to do however, and you should design it in such a way that is easiest for the problem at hand.
Sometimes replicating the data in two places isn't a terrible idea as long as you keep it synchronized. For instance, if you need to know where a specific car is parked, you're going to end up wanting to keep track of that data in the Car class as well, otherwise you're going to have to poll every parking spot to know if that car is parked there.
In Object Oriented design the object can be considered an entity. At this point you may use the Entity relationship modelling to better understand who has to own what.
When you design your model you shouldn’t care how you are going to implement it. I mean you shouldn’t think who is going to own what because this is another process of the design that is when you are going to convert your model to objects (that can be data table, XML, C# object ,…. ) : only at this point against the relationship the entity got you can decide who has to own what(sometime even against the requirements as I’ll show you later).
At the design time you must focus just on the requirements you have. In the case of the car and car parking you should think about :
How many park car one can occupied ?
How many cars a park can host ?
What kind of answer has my system to answer ? EX: as user I want know where a car is parked against its car plate number (in this case the previous answer would be wrong because if you let the park own the car you should iterate through the park to get what car is on it)
As you can see it really depends by you business requirements especially when you have “one-to-one” relationship(as in this case).
So I can suggest you to have a look at “Entity relationship Modelling” and stick to its concept to better design you object model.
In this case undoubtedly parking space should hold a car(it's called aggregation), because the relationship between car and parking space isn't permanent(different cars can be parked in the same parking place in the same day)
In this case, I think, the user wants to get a book, so the GUI of this system must have some button(or smht else) that user has to click to reserve a book. So, user calls a method checkout(book) of the system(object Library represents it) to check if the book is free(or available). Then the system(Library) checks whether the book wasn't reserved earlier by other user, so it calls method Book.check() for all instances of this book. In such solution every user account in the system should have a list of reserved books which method Book.check() uses.
To think out of box, I don't think the examples you provided have a natural "has a" or "owns a" relationship, and there are more relationships than "has a" or "owns a". In my opinion, I'd like to use a loosely coupled relationship for your examples, in implementation perspective, I would use a map to describe and maintain this relationship, which means, for a parking lot and a car, I would put a map in the Parking class, and map its slots to cars, if we find a slot existing in the map, we know that slot is occupied, if not, it's a free slot, for me, it doesn't make much sense either saying car owns the slot or the slot owns the car; for the library example, the same thing, the book and its borrower are in a very loose relationship, I'd put a map in the Library class, and map the book to its borrower. And who's the guy really does the checkout action? it's either the library staff or the auto machine or simply the library, so we can have a library.checkout(user, books), and inside the method, put books and user into the map.
For the bonus, what is really a "has a" relationship scenario? not a man has a car, this is not really a "has a", even we have "has a" in the sentence (don't let the human language mislead you), this just means, inside the car's class, there is a String field called ownerName or ownerId, that's it. One example for a real "has a" relationship scenario is human has a heart or a car has an engine, which means, in the implementation, there is really a Heart class field inside the Human Class.
How beautiful the object oriented design is!