This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes UML Relations & Java Implementation 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 » Engineering » OO, Patterns, UML and Refactoring
Bookmark "UML Relations & Java Implementation" Watch "UML Relations & Java Implementation" New topic
Author

UML Relations & Java Implementation

Prasma Kankut
Greenhorn

Joined: Oct 15, 2003
Posts: 21
How are the following relationships typically implemented in a Java program?

  • Generalization
  • Realization
  • Association
  • Aggregation
  • Composition
  • Dependency


  • For example, Generalization is implemented as



    and Realization is implemented as



    What about the other relations? Can someone throw some examples?


    <i>The fact that today we know more than yesterday is good news about today, not bad news about yesterday - Ilja Preuss</i>
    Prasma Kankut
    Greenhorn

    Joined: Oct 15, 2003
    Posts: 21
    Also is it possible to find the types of relations from a Java code?

    Code 1:


    Code 2:


    Code 3:


    I guess the Code 3 is an example for Dependency relationship. Is my understanding correct?
    What about Code 1 & Code 2? Aggregation? Association?
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Association, Aggregation and Composition can't easily be distinguished in code. The most straightforward implemention is an instance variable, but other ways are possible.

    Generalization/Realization more or less translate to inheritance. Of course it depends on what kind of diagram you see it in whether it will directly translate to code at all.

    Dependency could be all kinds of things. If A depends on B it typically means that if B changes, A needs to be recompiled together with B.


    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
    Damon Jasperson
    Greenhorn

    Joined: Mar 19, 2008
    Posts: 2
    Composition can be easily identified in Java code. Remember that composition refers to the parts that make up the whole, so without the whole, there are no parts!

    If a Car composes an Engine, then the following code will result:

    public class Car {
    private Engine engine;

    public Car() {
    engine = new Engine();
    }

    public void startEngine() {
    engine.start();
    }

    protected void finalize() {
    engine = null;
    super.finalize();
    }
    }

    The main thing to take away here is that there is no direct access to the Engine object. Ultimately, it should be understood that composition is a specialized form of aggregation (strong aggregation), which strictly defines the lifetime of a composed object.
    [ March 19, 2008: Message edited by: Damon Jasperson ]
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Damon Jasperson:

    The main thing to take away here is that there is no direct access to the Engine object.


    That's not required for a Composition. It's true, though, that this is a quite strong indicator for a Composition relationship.
    Ulf Dittmer
    Marshal

    Joined: Mar 22, 2005
    Posts: 41046
        
      43
    Some useful explanations on this topic can also be found in http://faq.javaranch.com/java/AssociationVsAggregationVsComposition


    Ping & DNS - my free Android networking tools app
    Damon Jasperson
    Greenhorn

    Joined: Mar 19, 2008
    Posts: 2
    QUOTE]That's not required for a Composition. It's true, though, that this is a quite strong indicator for a Composition relationship.

    I disagree, here's why:

    If composition implies lifecycle management by the composer (it does), then any outside object that can obtain a handle to the composed object (the Engine, in the example) can prevent garbage collection of an Engine that has been made available for garbage collection by virtue of its composer (the Car) being made available for garbage collection. In other words, by gaining access to the Engine explicitly, you've violated the contract of composition by subverting the lifecycle management defined by composition.

    So, in this case, by destructing the car, you may not be able to destruct the engine because you've allowed outside access to the engine.
    Scott Ambler
    author
    Ranch Hand

    Joined: Dec 12, 2003
    Posts: 608
    At my java articles I have links to a series of articles that I wrote 5-6 years ago on this topic.

    - Scott


    <a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Damon Jasperson:
    If composition implies lifecycle management by the composer (it does),


    Well, it not only implies it, it actually is *the* defining criteria.

    then any outside object that can obtain a handle to the composed object (the Engine, in the example) can prevent garbage collection of an Engine that has been made available for garbage collection by virtue of its composer (the Car) being made available for garbage collection. In other words, by gaining access to the Engine explicitly, you've violated the contract of composition by subverting the lifecycle management defined by composition.


    - in a language with garbage collection, you simply have much less control over the lifecycle of an object. The best the "whole" actually can do is *prevent* garbage collection as long as it needs to. (That also means that Composition is much less important in a language with a garbage collector than in a language where you actively need to destroy an object.)

    - one object having the responsibility of lifecycle management for another object doesn't necessarily mean that it's also the object's responsibility to prevent other objects from fulfilling that responsibility. It could just be the *developer's* responsibility to not make other objects intervene.

    - Composition actually allows for the responsibility to be passed around. That is, there may only be one object be responsible for it at any time through the life of the "part", but it doesn't have to be the same object all the time.
     
    jQuery in Action, 2nd edition
     
    subject: UML Relations & Java Implementation
     
    Similar Threads
    Class names in UML diagram
    realization relationship
    newInstance() doubt
    how to get the answer as 15 for this code
    UML: associations of interfaces