Scribd
Upload
3K views

How To Convert A Class Diagram Into Java Code

Association is a relationship where one class holds a reference to another class. It is represented by a line with an arrow indicating navigation direction. Dependency occurs when a class receives a reference to another class for a specific operation but does not hold a reference. It is represented by a dashed arrow. Aggregation is often considered redundant as it can be represented by association, with no separate UML symbol. Composition represents one class owning the creation of another, so the composed object is destroyed when the owner is destroyed. It is shown as a solid line with a diamond.

Uploaded by

cb
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
3K views

How To Convert A Class Diagram Into Java Code

Association is a relationship where one class holds a reference to another class. It is represented by a line with an arrow indicating navigation direction. Dependency occurs when a class receives a reference to another class for a specific operation but does not hold a reference. It is represented by a dashed arrow. Aggregation is often considered redundant as it can be represented by association, with no separate UML symbol. Composition represents one class owning the creation of another, so the composed object is destroyed when the owner is destroyed. It is shown as a solid line with a diamond.

Uploaded by

cb
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

Association is reference based relationship between two classes.

Here a class A holds a class


level reference to class B. Association can be represented by a line between these classes with
an arrow indicating the navigation direction. In case arrow is on the both sides, association
has bidirectional navigation.

class Asset { ... }


class Player {
Asset asset;
public Player(Assest purchasedAsset) { ... } /*Set the asset via
Constructor or a setter*/
}

Dependency is often confused as Association. Dependency is normally created when you


receive a reference to a class as part of a particular operation / method. Dependency indicates
that you may invoke one of the APIs of the received class reference and any modification to
that class may break your class as well. Dependency is represented by a dashed arrow starting
from the dependent class to its dependency. Multiplicity normally doesnt make sense on a
Dependency.

class Die { public void Roll() { ... } }


class Player
{
public void TakeTurn(Die die) /*Look ma, I am dependent on Die and it's
Roll method to do my work*/
{ die.Roll(); ... }
}

Aggregation is same as association and is often seen as redundant relationship. A common


perception is that aggregation represents one-to-many / many-to-many / part-whole
relationships (i.e. higher multiplicity), which of course can be represented by via association
too (hence the redundancy). As aggregation doesnt convey anything more effective about a
software design than an association, there is no separate UML representation for it (though
some developers use a hollow diamond to indicate aggregation). You can give aggregation a
miss unless you use it to convey something special.

class Asset { ... }


class Player {
List assets;
public void AddAsset(Asset newlyPurchasedAsset)
{ assets.Add(newlyPurchasedAssest); ... }
...
}

Composition relates to instance creational responsibility. When class B is composed by class


A, class A instance owns the creation or controls lifetime of instance of class B. Needless to
say when class instance A instance is destructed (garbage collected), class B instance would
meet the same fate. Composition is usually indicated by line connecting two classes with
addition of a solid diamond at end of the class who owns the creational responsibility. Its
also a perceived wrong notion that composition is implemented as nested classes.
Composition binds lifetime of a specific instance for a given class, while class itself may be
accessible by other parts of the system.

public class Piece { ... }


public class Player
{
Piece piece = new Piece(); /*Player owns the responsibility of creating the
Piece*/
...

You might also like