• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

UML Relations & Java Implementation

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
     
    Prasma Kankut
    Greenhorn
    Posts: 21
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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?
     
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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.
     
    Greenhorn
    Posts: 2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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.
     
    Rancher
    Posts: 43081
    77
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Some useful explanations on this topic can also be found in http://faq.javaranch.com/java/AssociationVsAggregationVsComposition
     
    Damon Jasperson
    Greenhorn
    Posts: 2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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.
     
    author
    Posts: 608
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    At my java articles I have links to a series of articles that I wrote 5-6 years ago on this topic.

    - Scott
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic