I am having a hard time understanding these when it comes to designing a class diagram, from what I know composition is a "has-a" relationship but Aggregation ?? I have no idea what is it. and one thing when will I know to use Composition in a class diagram? and when will I know to use Aggregation in a class diagram?? a example will be highly appreciated.
The main difference between an aggregation and a composition is the property of your "has-a" relationship. It' either strong or weak.
The aggregations "has-a" relationship is of "weak-type". Weak meaning the linked components of the aggregator may survive the aggregations life-cycle or may be accessed in some other way. A simple example would be a football club with its members. If the club is dissolved, you still got the members - which in fact could also be members of other clubs and thus are kept alive.
The composition "has-a" relationship is of "strong-type". Strong meaning that one can't exist without the other. The component's life-cycles are directly linked to the "parent". An example would be a house with rooms. If you decide to tear the house down, you will also lose your rooms.
Maybe a little abstract but I think that's the idea behind it.
See answers to previous questions here, here and here.
Personally I don't use Aggregation. The semantics are too weak to be useful. It causes more problems than it solves. There's only one place where it has well-defined and potentially useful properties that distinguish it from a simple binary association (see footnote).
Composition can be useful because it defines important properties on immutability and lifecycle management (see 1st link above). I've survived quite happily for many years without ever needing to use Aggregation.
hth.
Footnote. Aggregation can be applicable if you need to model a recursive tree relationship, e.g. a part decomposed recursively into sub-parts. Aggregation says there can be no circular relationships, i.e. a part can't be a sub-part of itself - directly or indirectly. However most people reading the model are unlikely to know that. -So you'd need to add a comment. Which means you'd be as well to stick with a binary association and avoid the confusion of using Aggregation.
Related
It's pretty strange to see all those answers about composition/aggregation/association.
Who/What is the source of those notions?
geeksforgeeks
wikipedia?!?!
stackexchange
and finally my lovely stackoverflow (at least I glad that answers were not marked as verified)
What is the difference between association, aggregation and composition?
What is the difference between aggregation, composition and dependency?
There is a great book "Design Patterns"
GoF
It describes two most common techniques for reusing functionality in object-oriented systems:
1) class inheritance (is-a)
2) object composition (has-a)
"Object composition is an alternative to class inheritance. Here, new functionality is obtained by assembling or composing objects to get more complex functionality."
"Composition" is a very descriptive term to express relationship between objects unlike "Association".
Why all those sources above use term "Composition" in the wrong way?!
Let's go further.
Objects could be composed in two ways:
1) Aggregation
2) Acquaintance
"Consider the distinction between object aggregation and acquaintance and how differently they manifest themselves at compile- and run-times. Aggregation implies that one object owns or is responsible for another object. Generally we speak of an object having or being part of another object. Aggregation implies that an aggregate object and its owner have identical lifetimes."
aggregate object and its owner have identical lifetimes!!!
"Acquaintance implies that an object merely knows of another object. Sometimes acquaintance is called "association" or the "using" relationship. Acquainted objects may request operations of each other, but they aren't responsible for each other. Acquaintance is a weaker relationship than aggregation and suggests much looser coupling between objects."
"It's easy to confuse aggregation and acquaintance, because they are often implemented in the same way. In Smalltalk, all variables are references to other objects. There's no distinction in the programming language between aggregation and acquaintance. In C++, aggregation can be implemented by defining member variables that are real instances, but it's more common to define them as pointers or references to instances. Acquaintance is implemented with pointers and references as well."
Guys, please, help me to figure out what's going on here...
Yes, there is lot of confusion around for these two terms Composition and Aggregation [There is More to add Shared and non-shared Aggregation]. After going through a lot of confusion and getting biased towards UML resources, I have formed my view as follows [need not be taken as final or accurate].
A simplest and loosely coupled relationship I take is Association [it can be unidirectional or bidirectional] where an Object has a reference of other object but both live independently. Association can be Qualified Association if its connected by specific Identity [In OO, identity is an important part of every entity object] e.g. accountNumber for Account of Customer.
Aggregation is collection (of other object types and can be assembled for restricted purpose) maintained by an Object. Still both the objects live independently. e.g. Athletics team. Same student can be part of many such teams like Cycling team [aggregates] and so on. Deleting Athletics team makes no harm to each student entry in college records [they still exist]. Such a relationship can be maintained as Collection of students on Team side or reference of Athletics team for each student being part of team. It depends on more frequently required navigability for application.
Composition is more tight relationship where container object completely holds the contained object and contained object does not have any meaning outside relationship with container object. I can see an example as relationship between Person and Address where for each person we keep separate/ fresh entry of address. For family members Address may have same logical equality, but never physical equality. Change of address for one member does not affect other members [simple test is - DB columns for Person record has extended columns for address as a part of person table.] another example is Single entry (row) of item purchase and Complete bill of items. where deleting bill makes each entry context-less.
If an object instantiates and contains another object completely [never allows outside world to obtain its ref by any means] I would take that as Composition. Techniques like Cloning objects at interaction points instead of passing same ref can be helpful here. In case of association or aggregation, we exchange same reference.
Containment being black-box reuse, is preferred over white-box kind of reuse (implemented using inheritance). Most of the GOF patterns suggest best combinations of Containment for reuse and inheritance for polymorphism. e.g. In case of Adapter pattern, Object Adapter is preferred over Class Adapter.
Implementing all these flavors in Java (Implementations will be language specific) has its own challenge and NOT very straight forward, especially composition. There is a point on learning curve, where one feels (at least I felt) Composition is same as inner class, inner class can help us implement it, but simply having inner class does not give any guarantee of composition.
In the below UML diagram, Account has an aggregation of Orders. Based on most online resources, this would typically mean Account class has something similar to a List as an instance.
But in reality, for a real world web app with persistent storage, that is not usually how the Account Class would be. It won't have a list of orders as instance. Instead some other controller class will just query a datastore asking for all Orders belonging to an Account. So in a UML class diagram for such an app, is this still the right way to represent relations? The cardinality and maybe the concept of aggregation looks right from a database entity perspective. Just that the diamond makes no sense from a Class perspective.
Or should it show a DataStore/DataManager with a getOrdersForAccount() method and connect it to Account class and Orders class through a dependency relation (dotted line with arrow) ?
This depends on what you want to represent.
The class model you have already would be sufficient as a logical domain model, expressing the logical relationships between entities in your domain. This might not be how you implement your software in code precisely, but it will guide you (and others) in understanding the entities and their relationships without getting bogged down in that implementation detail. At this level, your diagram may have a few design choices (strong aggregation for example is arguably a design choice, but it may not be, as is the use of enumerations and keys) but not that many and nothing that really detracts from the underlying logic. If anything, you could loose some design choices here and improve the expression of logic.
What you may also want is to provide a representation of how the OO code is implemented physically as well. This would be an additional class diagram that shows more precisely the implementation detail. You will have far more design choices in this diagram -- whether to use a collection or not for orders (e.g. a list or some other collection type class), what your data access patterns are (Adapters, Managers, ORMs etc.). At this level you will most likely loose the strong aggregate notation, as at this level we are talking about classes referencing each other which is most simply denoted using basic associations. You might want to use arrows and/or dot-notation to indicate end ownership and reference directions so that it's more clear what the relationships between classes are.
So, I think your question is a classic question about levels of abstraction in models and analysis vs design. Thanks for asking it!
The aggregation just means: "if you delete the account you need to delete the orders as well".
I also recommend to just leave the aggregation away (for most cases) since it only adds little extra semantics to your model. In this case it seems obvious to delete the order when the account is deleted. The only thing the aggregation added here is (as in most cases) some confusion or some futile discussions about the worth of that diamond.
If you have a domain where the filled diamond is used it should be documented in the modeling rules. When using the shared aggregation the documentation is even mandatory since there is no semantics per se in the specs (see box on p. 110 of UML 2.5).
It depends on how deep you want to go with UML design.
If you target code generation from UML then you probably need to add the class you mentioned.
It would look a lot like Registry Pattern:
UML Diagram
You can add abstraction so you can change implementation of your DataManager (if your DataManager is third-party then just call the API from DataManagerImplementation).
After that, depending on your implementation, once you have the list, if you need to keep it then add the association Account -> Order, if you can live with the list on the stack then you are good to go.
C++ instanciation example:
DataManagerImplementation *db = new DataManagerImplementation();
// Dependency injection
Account *acc = new Account(db);
Then in 'Account' class:
Account::Account(DataManager *db)
{
// Fetch list at creation
// Here 'orders' could be a member
m_db = db;
vector<Order*> *orders = m_db->GetOrders(this);
}
PS: I also recommend to put arrow (direction) on association/aggregation, otherwise it implies that the association is bi-directional and so that account has a pointer to an order list, and every order also has a pointer to an account, and I am not sure this is needed.
To edit PlantUML: http://www.plantuml.com/plantuml/png/SoWkIImgAStDuN99B4dqJSnBJ4yjyimjo4dDJSqhIIp9pCzJqDMjiLFmBqf9BK9ImuKk05Hcfw2afGHHYIbjfL2McboINsG3bj6oKz1oJoq1iuir79EJyqlpIZIve0m5a566IfYMEgJcfG0T2m00
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.
Composition: A class can have references to objects of other classes as members. This is called composition and is sometimes referred to as a has-a relationship.
By Deitel P.J., Deitel H.M. - Java How to Program 9th Edition.
This viewpoint is discussed in this topic:
Prefer composition over inheritance?
Composition: Composite aggregation (composition) is a "strong" form of aggregation with the following characteristics:
*it is binary association,
*it is a whole/part relationship,
*a part could be included in at most one composite (whole) at a time, and
*if a composite (whole) is deleted, all of its composite parts are "normally" deleted with it.
Found on http://www.uml-diagrams.org/composition.html
(actually, Deitel presents UML examples following this idea, in the same book, but did not bother to explain the difference).
This viewpoint is discussed in this topic:
What is the difference between association, aggregation and composition?
Fine, BOTH ARE CORRECT. And this introduces the problem of homonym concepts.
For instance: don't draw a UML model with composition arrows to exemplify the first definition: In UML, any association is a composition by Deitels' the first definition.
Here are some aspects of my question that may help in the correct answer:
How I can say (and know) which composition are we talking about?
Where we draw the line between the two definitions (in contextual terms)?
Can I say that the first is object oriented programming and the second is software engineering/modeling?
Is the UML composition a model-only concept/jargon?
Is the UML composition an UML exclusive thing? or is also applied in the programming field?
How to avoid miscommunication of "what composition are we talking about" in a team?
Please, answer with references, evidences, it is not a philosophical/opinion problem, it is a "scope" problem that I´m trying to address.
And it is not "what is composition" question.
Edit: I´m thinking if the distinction is verb x adjective: "to compose" a class (first def.) and "a composite relation" (second def.).
I found it hard to explain the difference between UML association and implementation references without explaining at least a little bit what UML associations actually are, and what they can do, so here we go.
Association & Link
Lets start by looking at what a UML Association and a link (Association's instance) are.
[11.5.3.1] An Association specifies a semantic relationship that can occur between typed instances.
[11.8.1.1] A link is a tuple of values that refer to typed objects. An Association classifies a set of links, each of which is an instance of the Association. Each value in the link refers to an instance of the type of the corresponding end of the Association.
So the following is a valid implementation of a limited association.
class Brain { }
class Head { }
a = new Brain;
b = new Head;
link = (new Array).add(a).add(b);
Ownership
[9.5.3] When a Property is owned by a Classifier other than an Association via ownedAttribute, then it represents an attribute of the Classifier.
(Note: Class is a subclass of a Classifier.)
Navigability
[11.5.3.1] An end Property of an Association that is owned by an end Class or that is a navigableOwnedEnd of the Association indicates that the Association is navigable from the opposite ends; otherwise, the Association is not navigable from the opposite ends. Navigability means that instances participating in links at runtime (instances of an Association) can be accessed efficiently from instances at the other ends of the Association. The precise mechanism by which such efficient access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient.
Why are those concepts relevant? Imagine the following example.
We see that brain is an attribute of Head class (the black dot signifies ownership by the opposite Class), and that it is navigable (the arrow).
We also see that head is NOT an attribute of Brain (no black dot ⇒ not owned by the Brain class ⇒ not an attribute of Brain), however it is still navigable. This means that in UML the head Property is held by the association itself.
The implementation could, for example, look like this (the association itself is represented by a tuple of two references (see link description earlier)).
class Head {
public Brain brain;
}
class Brain {
}
h = new Head;
b = new Brain;
h.brain = b;
link = (new Array).add(h).add(b);
So as you hopefully start to see, UML association is not such a simple concept as a has-a relationship.
Composition
Lets add another piece, composition.
[11.5.3.1] A binary Association may represent a composite aggregation (i.e., a whole/part relationship). Composition is represented by the isComposite attribute
[9.9.17] The value of isComposite is true only if aggregation is composite.
With the aggregation being
none - Indicates that the Property has no aggregation semantics.
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
Again we see, that a UML association is explicitly specifying concepts that are hard to perceive from implementation (e.g. who is responsible for object management/destruction).
Model Composition vs Object Implementation Composition
So from the description above we can construct a more precise description of what an implementation composition (has-a relationship) would be.
[Deteils] Composition: A class can have references to objects of other classes as members. This is called composition and is sometimes referred to as a has-a relationship.
McConnell [Code Complete 2, 6.3] also refers to has-a relationship as a Containment.
Neither of them however talk about HOW the objects (container-contained, composer-composite) are related to one another, who is responsible for lifecycles, or whether the contained element knows about the container.
So just by saying that objects have a has-a relationship (and call it composition), you could actually mean any of these (and several more)
So if you call something composition in programming, you can mean pretty much any relationship/reference (or rather not an inheritance), so the word by itself is not very useful.
In UML on the other hand you are trying to capture all such information about how the objects are related to one another. Therefore there's a focus on giving terms a more precise meaning. So when you call something composition in UML you have in mind a very specific has-a relationship, where the container is responsible for the lifecycle of the contained items.
Implementation of UML associations
All those extra concepts information mean that there is really no precise way how to even implement associations. This makes sense as the implementation would depend on the target programming language or environment (e.g. executable models, where the UML concepts are used as the final product).
As an example I can recommend a paper describing UML association implementation in Java with enforced concepts such as multiplicity, navigability, and visibility Implementing UML Associations in Java.
More subquestions
How I can say (and know) which composition are we talking about?
By context, or you can just ask (which is always a good thing to do when unsure). Personally I've heard the use of composition as "has-a relationship" only when differentiating from inheritance; and in the rest in terms of UML. But then again I am in academia, so my view is biased.
Where we draw the line between the two definitions (in contextual terms)?
As the "programming" term composition doesn't actually mean anything (only that it is has-a), I'd recommend drawing the line yourself and pushing others to use more precise terminology.
Can I say that the first is object oriented programming and the second is software engineering/modeling?
More or less, with all the nuances mentioned in this answer.
Is the UML composition a model-only concept/jargon?
Is the UML composition an UML exclusive thing? or is also applied in the programming field?
No, you can use it in programming to mean the same thing as it means in UML, but you might need to state it more obviously. E.g. "This class is a composite for those classes, because it manages their lifecycle.".
The point is to teach people to differentiate between regular-old has-a relationships, and relationships that have more precise semantics.
How to avoid miscommunication of "what composition are we talking about" in a team?
This is a very broad question that you could apply to any term to which you want attach special meaning (what even is software engineering?), and there is no best way. Have a team-shared vocabulary (you are probably already having a lots of specific terms in your domain), and guide people to use more precise terminology.
numbered quotes refers to sections in UML 2.5 Specifications.
To cite the UML 2.5 specification on page 110:
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:
none: Indicates that the Property has no aggregation semantics.
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).
Personally I see it the way that notion of a composite aggregation is about object lifetime, not about static relation. A composite aggregation kills aggregate members when their parent dies. None leaves this open. And shared aggregation is a bastard that OMG should not have introduced at all since it's semantics is domain dependent.
I 'm concern about what techniques should I use to choose the right object in OOP
Is there any must-read book about OOP in terms of how to choose objects?
Best,
Just write something that gets the job done, even if it's ugly, then refactor continuously:
eliminate duplicate code (don't repeat yourself)
increase cohesion
reduce coupling
But:
don't over-engineer; keep it simple
don't write stuff you ain't gonna need
It's not a precise recipe, just some general guidelines. Keep practicing.
P.S.
Code objects are not related to tangible real-life objects; they are just constructs that hold related information together.
Don't believe what the Java books/schools teach about objects; they're lying.
You probably mean "the right class", rather than "the right object". :-)
There are a few techniques, such as text analysis (a.k.a. underlining the nouns) and Class Responsibility Collaborator (CRC).
With "underlining the nouns", you basically start with a written, natural language (i.e. plain English) description of the problem you want to solve and underline the nouns. That gives you a list of candidate classes. You will need to perform several passes to refine it into a list of classes to implement.
For CRC, check out the Wikipedia.
I suggest The OPEN Toolbox of Techniques for full reference.
Hope it helps.
I am assuming that there is understanding of what is sctruct, type, class, set, state, alphabet, scalar and vector and relationship.
Object is a noun, method is a verb. Object members can represent identity, state or scalar value per field. Relationships between objects usually are represented with references, where references are members of objects. In cases, when relationships are complex, multidirectional, have arity greater than 2, represent some sort of grouping or containment, then relationships can be expressed as objects.
For other, broader technical reasons objects are most likely the only way to represent any form of information in OOP languages.
I am adding a second answer due to demian's comment:
Sometimes the class is so obvious
because it's tangible, but other times
the concept of object it's to abstract
like a db connector.
That is true. My preferred approach is to perform a behavioural analysis of the system (using use cases, for example), and then derive system operations. Once you have a stable list of system operations (such as PrintDocument, SaveDocument, SpellCheck, MergeMail, etc. for a word processor) you need to assign each of them to a class. If you have developed a list of candidate classes with some of the techniques that I mentioned earlier, you will be able to allocate some of the operations. But some will remain unallocated. These will signal the need of more abstract or unintuitive classes, which you will need to make up, using your good judgment.
The whole method is documented in a white paper at www.openmetis.com.
You should check out Domain-Driven Design, by Eric Evans. It provides very useful concepts in thinking about the objects in your model, what their function are in the domain, and how they could be organized to work together. It's not a cookbook, and probably not a beginner book - but then, I read it at different stages of my career, and every time I found something valuable in it...
(source: domaindrivendesign.org)