Class Diagram

Blog is short for web log is a web application that resembles the form of writings ( published as a post ) on a public web page . These writings are often published in reverse order ( most recent content first and then followed the older content ) , although not necessarily so . Web sites like these can usually be accessed by all Internet users according to the topics and goals of the user's blog .
Class diagrams are used to show classes and packages in the system . Class diagram gives an overview of the system and the static relationships between them . Typically , dibua some class diagrams for a single system . Some diagrams will show a subset of the classes and their relationships . Can be made ​​a few diagrams as desired to get a complete picture of the system is built .
Class diagram is the best tool for the design of the development team . The diagram helps developers get the system structure before the code is written , and help to ensure that the system is the best design .

Class diagrams are used to display diagam several classes and packages that exist in the system / software we're using.

Class diagram gives us a picture (static diagram) of the system / software and relas-relationships that exist therein.

The class diagram is the main building block of object oriented modelling. It is used both for general conceptual modelling of the systematics of the application, and for detailed modelling translating the models into programming code. Class diagrams can also be used for data modeling.The classes in a class diagram represent both the main objects, interactions in the application and the classes to be programmed.

In the diagram, classes are represented with boxes which contain three parts:

• The top part contains the name of the class
• The middle part contains the attributes of the class
• The bottom part gives the methods or operations the class can take or undertake

There are five key relationships between classes in a UML class diagram : dependency, aggregation, composition, inheritance and realization. These five relationships are depicted in the following diagram:

The above relationships are read as follows:

• Dependency : class A uses class B
• Aggregation : class A has a class B
• Composition : class A owns a class B
• Inheritance : class B is a Class A  (or class A is extended by class B)
• Realization : class B realizes Class A (or class A is realized by class B)

What I hope to show here is how these relationships would manifest themselves in Java so we can better understand what these relationships mean and how/when to use each one.

Dependency

Dependency is a weaker form of relationship which indicates that one class depends on another because it uses it at some point in time. One class depends on another if the independent class is a parameter variable or local variable of a method of the dependent class. This is different from an association, where an attribute of the dependent class is an instance of the independent class.

Dependency is represented when a reference to one class is passed in as a method parameter to another class. For example, an instance of class B is passed in to a method of class A:  

?

Aggregation

Aggregation is a variant of the “has a” association relationship; aggregation is more specific than association. It is an association that represents a part-whole or part-of relationship. As a type of association, an aggregation can be named and have the same adornments that an association can. However, an aggregation may not involve more than two classes.

Aggregation can occur when a class is a collection or container of other classes, but where the contained classes do not have a stronglife cycle dependency on the container—essentially, if the container is destroyed, its contents are not.

In UML, it is graphically represented as a hollow diamond shape on the containing class end of the tree with a single line that connects the contained class to the containing class. The aggregate is semantically an extended object that is treated as a unit in many operations, although physically it is made of several lesser objects.

Now, if class A stored the reference to class B for later use we would have a different relationship called Aggregation. A more common and more obvious example of Aggregation would be via setter injection: 

?

Composition

Composition is a stronger variant of the “owns a” association relationship; composition is more specific than aggregation.

Composition usually has a strong life cycle dependency between instances of the container class and instances of the contained class(es): If the container is destroyed, normally every instance that it contains is destroyed as well. (Note that, where allowed, a part can be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite.)

The UML graphical representation of a composition relationship is a filled diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class.Aggregation is the weaker form of object containment (one object contains other objects). The stronger form is called Composition. In Composition the containing object is responsible for the creation and life cycle of the contained object. Following are a few examples of Composition. First, via member initialization: 

?

?

Realization

In UML modelling, a realization relationship is a relationship between two model elements, in which one model element (the client) realizes (implements or executes) the behavior that the other model element (the supplier) specifies.
The UML graphical representation of a Realization is a hollow triangle shape on the interface end of the dashed line (or tree of lines) that connects it to one or more implementers. A plain arrow head is used on the interface end of the dashed line that connects it to its users. In component diagrams, the ball-and-socket graphic convention is used (implementors expose a ball or lollipop, while users show a socket).
Realizations can only be shown on class or component diagrams.
A realization is a relationship between classes, interfaces, components, and packages that connects a client element with a supplier element. A realization relationship between classes and interfaces and between components and interfaces shows that the class realizes the operations offered by the interface.

?