Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Java Coding and UML Aggregation v/s Composition

 
karan khosla
Greenhorn
Posts: 25
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aggregation [ 'HAS-A' Relationship ]



In UML Aggregation is Expressed as






Composition [ 'Contains' Relationship ]



In UML Composition is Expressed as




Correct me if i'am wrong
 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Karan,

actually there's no question in your post but I think I can figure out what you want to know

Of course there is almost always more than one way to model such relationships in code but your examples point out the difference between composition and aggregation quite well. As you pointed out the main difference between aggregation and composition is that the life cycle of the aggregated object is controlled externally whereas the life cycle of the composed object is controlled by the object it belongs to.

So I'd say your thought are CORRECT

Marco
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In fact, the first example could be composition, too. Composition very well allows to hand over responsibility for an object.

In a garbage collected language, Composition isn't a very important concept, anyway.

See http://faq.javaranch.com/java/AssociationVsAggregationVsComposition
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marco Ehrentreich wrote:As you pointed out the main difference between aggregation and composition is that the life cycle of the aggregated object is controlled externally whereas the life cycle of the composed object is controlled by the object it belongs to.

So I'd say your thought are CORRECT

I don't think so, the main different is aggregated objects are shareable while component objects are not. It's not necessary that the composite object must control the life cycle of its components.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kengkaj Sathianpantarit wrote:
Marco Ehrentreich wrote:As you pointed out the main difference between aggregation and composition is that the life cycle of the aggregated object is controlled externally whereas the life cycle of the composed object is controlled by the object it belongs to.

So I'd say your thought are CORRECT

I don't think so, the main different is aggregated objects are shareable while component objects are not. It's not necessary that the composite object must control the life cycle of its components.


The definition I know is exactly the other way around. There can be as many references to component objects as you like, from as many other objects as you like, but there needs to be exactly one "whole" at any time that is responsible for its lifecycle.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja is correct.

 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja Preuss wrote:
Kengkaj Sathianpantarit wrote:
Marco Ehrentreich wrote:As you pointed out the main difference between aggregation and composition is that the life cycle of the aggregated object is controlled externally whereas the life cycle of the composed object is controlled by the object it belongs to.

So I'd say your thought are CORRECT

I don't think so, the main different is aggregated objects are shareable while component objects are not. It's not necessary that the composite object must control the life cycle of its components.


The definition I know is exactly the other way around. There can be as many references to component objects as you like, from as many other objects as you like, but there needs to be exactly one "whole" at any time that is responsible for its lifecycle.

Well, I might not be clear enough, I'll explain again.
As you said, "there needs to be exactly one "whole" at any time".
That means non-shareable, no? I think we talk the same thing but use words differently.

Regarding managing life cycle, please look at the following quotes from UML 2 Superstructure Specification.
James, please not blame me for copy and paste, I think it would help to explain.

composite Indicates that the property is aggregated compositely, i.e., the composite object has
responsibility for the existence and storage of the composed objects (parts).

However, it's not crystal clear what the exactly meaning of "responsibility for the existence and storage" is.
The specification doesn't specify that the composite must responsible for lifecycle of the composed objects.
By life cycle I mean not-exist -> instantiated -> exist -> destroyed.

Please see next.
Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one
composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite.

It's clear that parts can be removed from a composite, so we can conclude that the composite has no complete control of life cycle of the composed objects.

Moreover, there is a Semantic Variation Point about parts creation.
Semantic Variation Points
The order and way in which part instances in a composite are created is not defined.

If the way of creating parts is not defined, I don't think we can say that it's necessary that the composite must control the life cycle of its parts.

You can find UML 2 Superstructure Specification from omg.org.

From all explanations above, validity of my comments stands still. But if you disagree with my explanation, please let me know and explain why.
 
John Kimball
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By "lifecycle", would that include giving up a particular instance?

Problems occur when words like "normally" is included into the definition, as the OMG spec. does for "...all of its parts are normally deleted...".

Two things that are clear:
- An instance is only owned by (at most) one composite; so another way of saying things is the composite is responsible for the lifecycle of an instance while it retains ownership.
- Most developers & designers expect instances owned by a composite to destroy it; and unless you have a good reason, it's probably bad to deviate from this.

Also, this thread ended up answering one of my questions
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
John Kimball wrote:By "lifecycle", would that include giving up a particular instance?

I don't think so, giving up a composed object is not a life cycle of a composed object, it's just an operation of the composite (removeXXX).

John Kimball wrote:
Problems occur when words like "normally" is included into the definition, as the OMG spec. does for "...all of its parts are normally deleted...".

No, have you read the following sentence?
Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite.

There is no problem there.

John Kimball wrote:
Two things that are clear:
- An instance is only owned by (at most) one composite; so another way of saying things is the composite is responsible for the lifecycle of an instance while it retains ownership.

Before a part exists and after a part is removed from the composite, the composite needn't to manage (it can - depends on implementation), so I don't think "manage lifecycle" is necessary.
I think the spec is already clear that the composite has responsibility for the existence and storage of the composed objects.

John Kimball wrote:
- Most developers & designers expect instances owned by a composite to destroy it; and unless you have a good reason, it's probably bad to deviate from this.

You mean the composite destroy parts? For garbage collected languages, this is not necessary.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kengkaj Sathianpantarit wrote:
Well, I might not be clear enough, I'll explain again.
As you said, "there needs to be exactly one "whole" at any time".
That means non-shareable, no? I think we talk the same thing but use words differently.


No, it does *not* mean non-shareable. There can be other objects referencing the part, that are not "wholes" the part is part of. That is, there is only one composite link allowed at any time, but as many additional non-composite links as you like. (By "link", I mean "instance of an association", here. If I remember correctly, that's the official term.)


Regarding managing life cycle, please look at the following quotes from UML 2 Superstructure Specification.
James, please not blame me for copy and paste, I think it would help to explain.

composite Indicates that the property is aggregated compositely, i.e., the composite object has
responsibility for the existence and storage of the composed objects (parts).

However, it's not crystal clear what the exactly meaning of "responsibility for the existence and storage" is.
The specification doesn't specify that the composite must responsible for lifecycle of the composed objects.
By life cycle I mean not-exist -> instantiated -> exist -> destroyed.


I agree that the specification doesn't seem to be very clear here.


Please see next.
Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one
composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite.

It's clear that parts can be removed from a composite, so we can conclude that the composite has no complete control of life cycle of the composed objects.


The "at most" is interesting. I thought it was "exactly".

Anyway, there is a difference between "complete control" and "responsibility". A composed object can achieve it's responsibility for the object life cycle by transferring that responsibility to a different whole, for example.
 
John Kimball
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kengkaj Sathianpantarit wrote:
John Kimball wrote:By "lifecycle", would that include giving up a particular instance?

I don't think so, giving up a composed object is not a life cycle of a composed object, it's just an operation of the composite (removeXXX).

John Kimball wrote:
Problems occur when words like "normally" is included into the definition, as the OMG spec. does for "...all of its parts are normally deleted...".

No, have you read the following sentence?
Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite.

There is no problem there.


You're misreading that sentence. When the part is removed from the composite, the composite cannot be responsible since it no longer has a reference; that's obvious.

But the "normally" phrase applies when the composite still has a reference to the part and needs to be "cleaned-up" for disposal. At that point, the expected behavior is for the composite to dispose of the object.

Kengkaj Sathianpantarit wrote:
John Kimball wrote:
Two things that are clear:
- An instance is only owned by (at most) one composite; so another way of saying things is the composite is responsible for the lifecycle of an instance while it retains ownership.

Before a part exists and after a part is removed from the composite, the composite needn't to manage (it can - depends on implementation), so I don't think "manage lifecycle" is necessary.
I think the spec is already clear that the composite has responsibility for the existence and storage of the composed objects.

Actually, the spec says it's "normally" expected that the composite deletes the stored objects.

Kengkaj Sathianpantarit wrote:
John Kimball wrote:
- Most developers & designers expect instances owned by a composite to destroy it; and unless you have a good reason, it's probably bad to deviate from this.

You mean the composite destroy parts? For garbage collected languages, this is not necessary.



But it is! For one, and as trivial as this may sound, garbage collection doesn't help if you retain a strong reference to the part outside of the composite.

Another, more common scenario (imho) is this: You may not want to destroy the part; that is, you may just want to change the state to make it available for another composite.

Things like a connection from a connection pool is a classic example.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
John Kimball wrote:
Actually, the spec says it's "normally" expected that the composite deletes the stored objects.

No, you misunderstand, the spec never said that the composite deletes the composed objects, please read the quote again. Other will delete them, not the composite itself. It's like cascade-delete action in RDBMS, the parent does not delete its child when it get deleted, RDBMS handles that.

John Kimball wrote:
Kengkaj Sathianpantarit wrote:
John Kimball wrote:
- Most developers & designers expect instances owned by a composite to destroy it; and unless you have a good reason, it's probably bad to deviate from this.

You mean the composite destroy parts? For garbage collected languages, this is not necessary.


But it is! For one, and as trivial as this may sound, garbage collection doesn't help if you retain a strong reference to the part outside of the composite.

I'm not sure what you mean by "destroy", if you mean de-allocate memory, in some languages that has garbage collection feature and has no de-allocate memory functionality like Java, it's not possible to do that.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja Preuss wrote:
Kengkaj Sathianpantarit wrote:
Well, I might not be clear enough, I'll explain again.
As you said, "there needs to be exactly one "whole" at any time".
That means non-shareable, no? I think we talk the same thing but use words differently.


No, it does *not* mean non-shareable. There can be other objects referencing the part, that are not "wholes" the part is part of. That is, there is only one composite link allowed at any time, but as many additional non-composite links as you like. (By "link", I mean "instance of an association", here. If I remember correctly, that's the official term.)

By non-shareable, I mean the parts are not shareable by more than one composite.
I use this word because actually an aggregation is an association that its AssociationKind is shared.
From UML 2.2 Superstructure:
AggregationKind is an enumeration of the following literal values:
• none
Indicates that the property has no aggregation.
• shared
Indicates that the property has a 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 (parts).

Ilja Preuss wrote:
Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one
composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite.

The "at most" is interesting. I thought it was "exactly".

The relationship's multiplicity can be 0..1 (it can only be 1 or 0..1). In M1 (User model), Whole and Part are associated with a line, but in M0 (Run-time model instances), Part doesn't need to have a Whole (if multiplicity is 0..1).
If the spec says "exactly", it would lead to a confusion, I think "at most" is fine.

Ilja Preuss wrote:
Anyway, there is a difference between "complete control" and "responsibility". A composed object can achieve it's responsibility for the object life cycle by transferring that responsibility to a different whole, for example.

In UML 2.2 Superstructure specification, there is no statement regarding life cycle of the composed objects.
But there is a Semantic Variation Point that clearly specifies that the way of creating part instances is not defined.

If go back to read from the beginning of the topic again, from source codes I think the topic creator think that for composition, the composite must create composed objects (other cannot), which is not necessary.

Actually, there are 2 main different between Aggregation and Composition:
  • For Composition, parts are not shareable (parts must have at most one composite at a time).
  • When the composite is deleted, the parts are also deleted. (From the spec I'm not 100% sure, what does it mean by "normally")

  • Anyway, I think the specification is not clear enough, I'll consider to write to OMG about this.

    [Edited - changed M2 to M1 and M1 to M0]
     
    John Kimball
    Ranch Hand
    Posts: 96
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Kengkaj Sathianpantarit wrote:
    John Kimball wrote:
    Actually, the spec says it's "normally" expected that the composite deletes the stored objects.

    No, you misunderstand, the spec never said that the composite deletes the composed objects, please read the quote again. Other will delete them, not the composite itself. It's like cascade-delete action in RDBMS, the parent does not delete its child when it get deleted, RDBMS handles that.


    Page 57, of the 2009-02-02 version of the proposed spec:
    "Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. "

    I see what you're saying, but who takes care of the parts? The container/object which manages the composite? Also, see the next response as (imho), this really should be about more than just "deletion".

    Kengkaj Sathianpantarit wrote:
    John Kimball wrote:
    Kengkaj Sathianpantarit wrote:
    John Kimball wrote:
    - Most developers & designers expect instances owned by a composite to destroy it; and unless you have a good reason, it's probably bad to deviate from this.

    You mean the composite destroy parts? For garbage collected languages, this is not necessary.


    But it is! For one, and as trivial as this may sound, garbage collection doesn't help if you retain a strong reference to the part outside of the composite.

    I'm not sure what you mean by "destroy", if you mean de-allocate memory, in some languages that has garbage collection feature and has no de-allocate memory functionality like Java, it's not possible to do that.


    The better term would be "clean-up". It's expected the composite will "Dispose" its parts when the composite itself is about to be disposed. If the class library you're writing enforces a kind of Disposable interface (e.g., as seen in the .NET world), then the composite should dispose each part. This doesn't actually de-allocate memory but it at least puts the part into an unusable state (and hopefully, frees up any underlying resources which are particularly expensive).

    In this sense, the composite is very much responsible for the lifecycle of its parts even in a managed-memory context.

    As for memory deallocation...JVM implementations aside, one can do fairly well if non-composites referencing in-use parts only refer to them using weak references.
     
    Hong Anderson
    Ranch Hand
    Posts: 1936
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    By delete, I believe it means delete from repository/existence, for example:
    - Delete a category, its subcategories will be deleted with it (if uses a RDBMS, the RDBMS handles that - a cascade delete constraint must be defined).
    - Delete a directory in Windows/Linux/Mac, its sub-directories will be deleted with it (the OS handles that).
    - Delete a requirement in a requirement management tool, its containment requirements will be deleted with it (the tool handles that).
    - Discard a broken device (into a trash can), its parts will be discarded with it (but the device itself doesn't discard its parts).
    - Discard a broken refrigerator, its parts like its doors will be discarded with it (but the refrigerator doesn't discard its parts), if we want to use the doors (for some strange purpose), we can remove the doors from the refrigerator before we discard it, in that case, the doors will not be discarded as parts of the refrigerator (how obvious, but saying like this can still cause confusion).
     
    John Kimball
    Ranch Hand
    Posts: 96
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Kengkaj Sathianpantarit wrote:By delete, I believe it means delete from repository/existence, for example:
    - Delete a category, its subcategories will be deleted with it (if uses a RDBMS, the RDBMS handles that - a cascade delete constraint must be defined).

    Your experience may be different, but I've seen a cascading delete in a production database all of once; and I'm pretty sure it was removed at some point.
    Every other time, I've seen (or we've designed) delete restrictions.

    Kengkaj Sathianpantarit wrote:
    - Delete a directory in Windows/Linux/Mac, its sub-directories will be deleted with it (the OS handles that).

    Operating systems aren't really designed in an OO manner. Also, the sub directories are generally deleted FIRST.

    Kengkaj Sathianpantarit wrote:
    - Delete a requirement in a requirement management tool, its containment requirements will be deleted with it (the tool handles that).
    - Discard a broken device (into a trash can), its parts will be discarded with it (but the device itself doesn't discard its parts).
    - Discard a broken refrigerator, its parts like its doors will be discarded with it (but the refrigerator doesn't discard its parts), if we want to use the doors (for some strange purpose), we can remove the doors from the refrigerator before we discard it, in that case, the doors will not be discarded as parts of the refrigerator (how obvious, but saying like this can still cause confusion).


    Actually, if devices could prepare itself for disposal it would solve most of our recycling problems. Some parts need to special preparation before proper disposal; and some items need to be disposed-of in a separate manner. The object-oriented world is ahead in this respect!

    Anyway, what I'm trying to get across is this: There's more to "delete" than just making it available for garbage collection or freeing up memory. In many cases, there's an idea of preparing an object for deletion.

    And consider this: If I have a container handling the composites and the container needs to dispose each of the composite's parts... then the container is tightly coupled to the composite! What if I have 12 different types of composites. Why should the container know how to dispose of each of the composites? And what happens when I create another 5 composites, each containing a different kind of part which needs to be properly prepared for deletion?

    It becomes a maintenance nightmare to support this sort of design (see real-life garbage, as an example!).
     
    Hong Anderson
    Ranch Hand
    Posts: 1936
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I guess maybe we're talking in different things.

    UML is not only for OO or programming, it's a unified language that can be used to model anything.
    If think in that way, it might clear some confusion.

    I used to explain about how to apply UML in non-OO, non-programming in another topic:
    http://www.coderanch.com/t/438483/OO-Patterns-UML-Refactoring/Companies-not-using-UML

    My posts are below in that topic, anybody interests can take a look.
     
    John Kimball
    Ranch Hand
    Posts: 96
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Ok, I think I finally see what you're saying but isn't that the exception rather than the norm?

    OO aside then, I thought the focus of UML was to model actual software.

    Do people actually use UML to model relational data, for example?
    There are other models & tools which already do this very nicely.
     
    Hong Anderson
    Ranch Hand
    Posts: 1936
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    John Kimball wrote:Ok, I think I finally see what you're saying but isn't that the exception rather than the norm?

    I'm glad you begin to understand what I'm trying to explain. It's no exception, as I said UML is not only for OO or software, it's a unified language. We can extends UML using Profiles thus UML can be used to model anything.

    John Kimball wrote:
    OO aside then, I thought the focus of UML was to model actual software.

    It seems most people think that, but it's not true.
    There is a book about business modeling using UML: Business Modeling With UML: Business Patterns at Work. It's just one example about how to apply UML in other domains.

    John Kimball wrote:
    Do people actually use UML to model relational data, for example?
    There are other models & tools which already do this very nicely.

    Maybe not many people, but if we want to use UML to do that, we can.
    Some UML tool like Enterprise Architect also provides built-in Data Modeling feature (implemented using Profiles of course).

    If you have further questions about this, you can send a private message to me, because this is an off-topic.
     
    Hong Anderson
    Ranch Hand
    Posts: 1936
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    John, I couldn't reply private message to you.
    This user is not accepting private messages.
     
    Vyas Sanzgiri
    Ranch Hand
    Posts: 686
    Chrome Netbeans IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    The discussion has progressed so far that you can create a JR page for this!!
     
    John Kimball
    Ranch Hand
    Posts: 96
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Oops, sorry about that. I updated my profile.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic