• 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

sample java code needed for UML class associations

 
Ranch Hand
Posts: 1491
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Any sample java code is available for UML class associations like dependency, Aggregation, Composite Aggregation, one to many, many to many, one to one relationships ?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Most of these concepts can be implemented in a number of different ways. But this has been discussed many times in this forum, so a search should give you access to a fair amount of discussions.

The book "UML for Java Programmers" also contains lots of example code.
 
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dependency

Let's start with a dependency. The dependency is a relationship of use, and typically it is not in the diagrams.

If A---->B that means that a method in A has a parameter of type B, or that a method of A creates an instance of B to some task and then destroy it. There is just a relation of use, there is not permanent relation between A and B. Of course, there are other kind of dependencies, but these are the most common.



I can say there is dependency relationship between MyActionListener and ActionEvent.

Association

An association is a "has a" relationship. It implies that one class retains a long lasting relationship to another object. Most of the times this implies that a class has an attribute ( a field member) which is the type of the second class, then A has a B.



Client objects has permanent relationship with the String objects, because a Client has a name which is of type String.

Of course, the multiplicity implies the relation can be to more than one object.



In this case, as clients has a name, a middle name and a last name, we can have relationship to the String class with a multiplicity of three.

Aggregation

An aggregation is a stronger version of the Association. It is a relation of ownership and this relationship goes beyond lifelines. In this kind of relationship then I say that an A "owns a" B.

Typically this kind of relationship implies that B could be shared with another objects.



Now when you create the Room object you pass 4 Wall objects. Hence I can say that a room owns 4 walls. However, since rooms can share walls, you could use the north wall passed to a room as south wall of another room above this, right?

In this case, destroying a room object does not imply, necessarily, the destruction of all the wall it owned, because they could be used by another rooms. Hence the relation goes beyond lifelines.

Composition
It is the strongest relationship of all. It implies that A is part of B. That means that A is responsible of creating and destroying all instances of B. The lifetime of instance of B depends on the existence of its container object, and the parts are not shared by other objects.



When a car is garbage collected so will their wheels.


As far as I am concerned, the existence of so many types of relations is sometimes confusing to me, but that's the way UML is, very ambiguous.

I hope this helps!
[ April 17, 2006: Message edited by: Edwin Dalorzo ]
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
UML for Java Programmers

The book includes, updates (to Java/UML) and expands on some material found in these articles (most recent first):
  • The Craftsman #13: Objects
  • The Craftsman #12: Three Ugly Lines
  • The Craftsman #11: What's main() got to do with it?
  • The Craftsman #10: Dangling Threads (Iterations Unbound)
  • The Craftsman #9: Dangerous Threads
  • The Craftsman #8: Socket Service 3 (Tests are a form of documentation)
  • The Craftsman #7: Mocket to me.
  • The Craftsman #6: Once is not Enough.
  • The Single Responsibility Principle
  • The Liskov Substitution Principle
  • The Interface Segregation Principle
  • The Dependency Inversion Principle
  • The Open Closed Principle


  • [ April 17, 2006: Message edited by: Peer Reynders ]
    reply
      Bookmark Topic Watch Topic
    • New Topic