I know that composition implements complete ownership while association does not involve ownership. What about Inheritance and Aggregation?
Inheritance: one thing is also another type of thing and inherits all of the attributes of that other type of thing. (Example: a student is also a person.)
Aggregation: one thing currently owns another thing, but the other thing doesn't require the owner to exist. (This is in contrast to composition, where one thing owns another thing, which requires the owner to exist.)
For example, a table has a surface on which to place things -- the surface cannot exist apart from the table (and have the table still be a table). The table is composed from (among other things) a surface.
But a table can have many plates on it -- the table aggregates the plates. The plates can still exist apart from the table (you can put them in the cupboard).
Related
The image shows the logistics of the Warehouse. Very very simplistic. What is its concept: There are documents: ReceivingWayBill, DispatchingWaybill, ReplacementOrder.
They interact with the main classes: Warehouse, Counterparty, Item.
And the Register class: ItemRemainsInWarehouse. It turns out, the document is confirmation of the operation, reception, sending, and so on. The Register simply stores information about the number of remaining goods.
If you miss a lot of problems of this scheme, such as: the lack of generalization, getters and setters and a heap of everything else.
Who can tell: the relationship between classes, and there is concrete aggregation everywhere, are placed correctly, or can we somehow consider the association in more detail?
It is so hard (maybe impossible) to correct your whole model with provided explanation. I give some improvements.
You should put Multiplicity of you relationships. They are so important. In some relationship, you have 1 (ReplacementOrder , Warehouse) and some of your relatioships are maybe * (Item , ReceivingWayBill)
You put Aggregation between your classes and we know that Aggregation is type of Association. You can put Associations too. You can find a lot of similar questions and answers that explain differences between Association and Aggregation (and Composition). see Question 1, Question 2 and Question 3. But I recommend this answer.
I think, there is NOT a very significant difference between Aggregation and Association. See my example in this question.
Robert C. Martin says (see here):
Association represents the ability of one instance to send a message to another instance.
Aggregation is the typical whole/part relationship. This is exactly the same as an association with the exception that instances
cannot have cyclic aggregation relationships (i.e. a part cannot
contain its whole).
Therefor: some of your relationships are exactly an Aggregation. (relationship between Item and other classes). Your Counterparty has not good API definition. Your other relationships is about using Warehouse class. I think (just guess) the other classes only use Warehouse class services (public methods). In this case, they can be Associations. Otherwise, if they need an instance of Warehouse as a part, they are Aggregations.
Aggregation is evil!
Read the UML specs about the two variants they introduced (p. 110):
none: Indicates that the Property has no aggregation semantics. [hear, hear!]
shared: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
composite: Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time. If a composite object is deleted, all of its part instances that are objects are deleted with it.
Now, that last sentence clearly indicates where you should use composite (!) aggregation: in security related appications. When you delete a person record in a database you need to also delete all related entities. That often used example with a car being composed of motor, tires, etc. does not really fit. The tires do not vanish when you "delete" the car. Simply because you can not delete it. Even worse is the use of a shared composite since it has no definition per definition (sic!).
So what should you do? Use multiplicities! That is what people usually want to show. There are 0..n, 1, etc. elements related to to the class at the other side. Eventually you name these by using roles to make it explicit.
If you consider DispatchingWaybill and ReceivingWaybill it looks like those are association classes. With the right multiplicities (1-* / *-1) you can leave it this way. (Edit: note the little dots at the association's ends which tell that the class at the opposite has an attribute named after the role.)
Alternatively attach either with a dashed line to an association between the classes where they are currently connected to.
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
Can composition be bidirectional in a way that both classes are aware of each other?
And if not, what is the default direction of composition?
You should distinguish navigability and aggregation. Arrow and diamond.
Arrow A->B means only that B is reachable from A in some simple way. If A contains a composition of B, it means that
the composite object has responsibility for the existence and storage
of the composed objects (parts).
(citation from OMG Unified Modeling Language TM (OMG UML) - p.109)
So, can composition have bi-directional navigability?
Yes. It is quite normal.
If, for example, you have decided to destroy B in some of its functions, you MUST reach A and destroy it from there. So, composition has bi-directional navigability often enough. Notice, that bi-directional navigability, according to both current and coming UML standards, is shown as line without arrows on both sides. Both-sided arrow is deprecated. THAT is the reason you won't see it often.
Can the composition itself be bi-directional? Can we see black diamonds on both sides of an association?
No, of course this sort of association cannot be mutual, for it is impossible for B to be created in A only and, simultaneously, for A to be created in B only.
What is interesting, the shared aggregation (empty diamond) cannot be mutual, too, but here the limitation is not inherent, it is simply forbidden by UML standard.
Yes, Composition does not add constraints with regards to the navigability of the association.
More info on the difference between Accociation, Composition and Aggregations can be found here: UML Composition vs Aggregation vs Association
From https://www.lucidchart.com/pages/uml/class-diagram:
Bidirectional associations are the default associations between two classes and are represented by a straight line between two classes. Both classes are aware of each other and of their relationship with each other. In the example above, the Car class and RoadTrip class are interrelated. At one end of the line the Car takes on the association of "assignedCar" with the multiplicity value of 0..1 which means that when the instance of RoadTrip exists, it can either have one instance of Car associated with it or no Cars associated with it. In this case, a separate Caravan class with a multiplicity value of 0..* is needed to demonstrate that a RoadTrip could have multiple instances of Cars associated with it. Since one Car instance could have multiple "getRoadTrip" associations-- in other words, one car could go on multiple road trips--the multiplicity value is set to 0..*
In the past I had the same opinion as Gangnus with
So, can composition have bi-directional navigability?
But following some recent discussion I had a more detailed look into the UML specs. And simply, that statement is not true (only partially). Let's look into the UML 2.5 specs. On p. 110 it is stated
Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation. To represent such circumstances, a Property has an aggregation property, of type AggregationKind; the instance representing the whole group is classified by the owner of the Property, and the instances representing the grouped individuals are classified by the type of the Property. AggregationKind is an enumeration with the following literal values:
[omitting shared aggregation]
composite: Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time. If a composite object is deleted, all of its part instances that are objects are deleted with it.
Note my emphasis on the object/instance in the above text. So UML just talks of responsibility. If A composes B it will be responsible to delete B when it is destroyed itself. Vice versa B would be responsible for A's destruction. So, if you have references in both directions (i.e. diamonds on both sides) then you will be reponsible to delete the object on the other side. This of course works only if just one of both holds a reference to the other. If both would have a reference, it would not be possible to have a directed responsibility (because it's circular).
I still think that having composite aggregation on both sides is not really a good idea. But according to the specification it is possible.
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.
This question already has answers here:
What is the difference between association, aggregation and composition?
(21 answers)
Closed 9 years ago.
What is the difference between aggregation, composition and dependency?
Aggregation implies a relationship where the child can exist independently of the parent. Example: Class (parent) and Student (child). Delete the Class and the Students still exist.
Composition implies a relationship where the child cannot exist independent of the parent. Example: House (parent) and Room (child). Rooms don't exist separate to a House.
The above two are forms of containment (hence the parent-child relationships).
Dependency is a weaker form of relationship and in code terms indicates that a class uses another by parameter or return type.
Dependency is a form of association.
Aggregation and composition are almost completely identical except that composition is used when the life of the child is completely controlled by the parent.
Aggregation
Car -> Tires
The Tires can be taken off of the Car object and installed on a different one. Also, if the car gets totaled, the tires do not necessarily have to be destroyed.
Composition
Body -> Blood Cell
When the Body object is destroyed the BloodCells get destroyed with it.
Dependency
A relationship between two objects where changing one may affect the other.
Aggregation - separable part to whole. The part has a identity of its own, separate from what it is part of. You could pick that part and move it to another object. (real world examples: wheel -> car, bloodcell -> body)
Composition - non-separable part of the whole. You cannot move the part to another object. more like a property. (real world examples: curve -> road, personality -> person, max_speed -> car, property of object -> object )
Note that a relation that is an aggregate in one design can be a composition in another. Its all about how the relation is to be used in that specific design.
dependency - sensitive to change. (amount of rain -> weather, headposition -> bodyposition)
Note: "Bloodcell" -> Blood" could be "Composition" as Blood Cells can not exist without the entity called Blood. "Blood" -> Body" could be "Aggregation" as Blood can exist without the entity called Body.
An object associated with a composition relationship will not exist outside the containing object. Examples are an Appointment and the owner (a Person) or a Calendar; a TestResult and a Patient.
On the other hand, an object that is aggregated by a containing object can exist outside that containing object. Examples are a Door and a House; an Employee and a Department.
A dependency relates to collaboration or delegation, where an object requests services from another object and is therefor dependent on that object. As the client of the service, you want the service interface to remain constant, even if future services are offered.
Aggregation and composition are terms that most people in the OO world have acquired via UML. And UML does a very poor job at defining these terms, as has been demonstrated by, for example, Henderson-Sellers and Barbier ("What is This Thing Called Aggregation?", "Formalization of the Whole-Part Relationship in the Unified Modeling Language"). I don't think that a coherent definition of aggregation and composition can be given if you are interested in being UML-compliant. I suggest you look at the cited works.
Regarding dependency, that's a highly abstract relationship between types (not objects) that can mean almost anything.
One object may contain another as a part of its attribute.
document contains sentences which contain words.
Computer system has a hard disk, ram, processor etc.
So containment need not be physical. e.g., computer system has a warranty.
Containment :- Here to access inner object we have to use outer object. We can reuse the contained object.
Aggregation :- Here we can access inner object again and again without using outer object.