wood burning stoves 2.0*
The moose likes Java in General and the fly likes Java Coding and UML Aggregation v/s Composition Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Java Coding and UML Aggregation v/s Composition" Watch "Java Coding and UML Aggregation v/s Composition" New topic
Author

Java Coding and UML Aggregation v/s Composition

karan khosla
Greenhorn

Joined: Apr 27, 2009
Posts: 25

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


Karan Check me out on http://pythonicway.blogspot.com/
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

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

Joined: Jul 11, 2001
Posts: 14112
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


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
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.


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Apr 16, 2008
Posts: 2187
Ilja is correct.

Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
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

Joined: Apr 13, 2009
Posts: 96
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

Joined: Jul 05, 2005
Posts: 1936
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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Apr 13, 2009
Posts: 96
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

Joined: Jul 05, 2005
Posts: 1936
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

Joined: Jul 05, 2005
Posts: 1936
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

    Joined: Apr 13, 2009
    Posts: 96
    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

    Joined: Jul 05, 2005
    Posts: 1936
    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

    Joined: Apr 13, 2009
    Posts: 96
    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

    Joined: Jul 05, 2005
    Posts: 1936
    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

    Joined: Apr 13, 2009
    Posts: 96
    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

    Joined: Jul 05, 2005
    Posts: 1936
    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

    Joined: Jul 05, 2005
    Posts: 1936
    John, I couldn't reply private message to you.
    This user is not accepting private messages.
    Vyas Sanzgiri
    Ranch Hand

    Joined: Jun 16, 2007
    Posts: 686

    The discussion has progressed so far that you can create a JR page for this!!


    ===Vyas Sanzgiri===
    My Blog
    John Kimball
    Ranch Hand

    Joined: Apr 13, 2009
    Posts: 96
    Oops, sorry about that. I updated my profile.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Java Coding and UML Aggregation v/s Composition
     
    Similar Threads
    composition and aggregation
    Compostion,Association and aggregation in java
    UML Relations & Java Implementation
    Access modifiers (very simple Q)
    Association, Aggregation and composition implementation in java