Designing Object Oriented

Programmimg with Java using

UML

Real World Relationships from a

Requirement

�The whole point of OOP is that your code replicates real world objects, thus making your code readable and maintainable

�Let’s consider the simple requirement listed below:

1.Manager is an employee of XYZ limited corporation.

2.Manager uses a swipe card to enter XYZ premises.

3.Manager has workers who work under him.

4.Manager has the responsibility of ensuring that the project is successful.

5.Manager's salary will be judged based on project success.

Extracting Real World Relationships

�If you flesh out the above five point

requirement, we can easily visualize four

relationships

� Inheritance

�Aggregation

�Association

�Composition

Requirement 1: The IS A relationship

Manager is an employee of XYZ limited

corporation

� It’s a parent child relationship or inheritance

relationship.

�The sentence above specifies that Manager is

a type of employee

�We will have two classes

�parent class Employee

�child class Manager which will inherit from the

Employee class.

Other Inheritance Example

� The little arrowhead pointing at Employee denotes

inheritance

� If you draw your arrowheads carelessly, it may be hard to tell

whether you mean inheritance or association.

� To make it clearer, inheritance relationships is generally

made vertical and associations is made horizontal.

Requirement 2: The Using relationship:

Association

Manager uses a swipe card to enter XYZ

premises

�The manager object and the swipe card object

use each other but they have their own object

life time.

� They can exist without each other.

�In association relationship, there is no single

owner.

we can create objects of the Manager class and SwipeCard

class independently and they can have their own object life time.

Other Association Example

Associations between classes most often represent instance variables

that hold references to other objects.

The direction of the arrow tells us that Phone holds a reference to

Button

A Phonebook has many PhoneNumbers.”

description of what actually happens in software is such as:

“is connected to.”

Requirement 3: The Using Relationship

with Parent: Aggregation

Manager has workers who work under him �This relationship denotes the same type of relationship

like association but with a difference that one of them is an owner.

�For each requirement, the Manager object will own Worker objects.

�The child Worker objects can not belong to any other object.�For instance, a Worker object cannot belong to a SwipeCard

object.

�Worker object can have its own life time which is completely disconnected from the Manager object.

� If the Manager object is deleted, the Worker object does not die.

Another Example

Aggregation is a special form of association that connotes

a “whole/part” relationship

UML does not provide a strong definition for this

relationship.

This relationship implies where the child can exist

independently of the parent.

Example: Whole (parent) and Part (child). Delete the

Whole and the Part still exist.

Another Example

The aggregation link doesn't state in any way that Class A

owns Class B nor that there's a parent-child relationship

The aggregation link is usually used to stress the point that

Class A instance is not the exclusive container of Class B

instance, as in fact the same Class B instance has another

container/s.

Requirements 4 and 5:

The Death relationship: Composition

Manager has the responsibility of ensuring that the project is successful.

Manager's salary will be judged based on project success.

The conclusion from analyzing the above requirements:

�Manager and the project objects are dependent on each other.

�The lifetimes of both the objects are the same.

In other words

�The project will not be successful if the manager is not good

�The manager will not get good increments if the project has issues.

� This relationship is termed as the composition relationship.

� Both objects are heavily dependent on each other.

� If one goes for garbage collection the other also has to be garbage

collected

� The lifetime of the objects are the same.

Other Example

Composition implies a relationship where the child

cannot exist independent of the parent.

Example: Owner (parent) and Ward (child).

Ward don't exist separate to a Owner .

There's a strong lifecycle dependency between

the two classes

when Class A is deleted then Class B is also

deleted as a result

� An instance of a ward cannot be owned simultaneously by two

owners.

� The object diagram is illegal.

� However the corresponding class diagram is not illegal.

� An owner can transfer ownership of a ward to another

owner.

� The owner is responsible for the lifetime of the ward.

� If the owner is destroyed, the ward must be destroyed

with it.

� If the owner is copied, the ward must be copied with it.

We have a class named Address that holds many Strings.

Each string holds one line of the address.

When you make a copy of the Address, you want the copy to change

independently of the original.

We need to.

Make a Deep Copy

Owner, Lifetime and Child Object of

Relationships

Association Aggregation Composition

Owner No owner Single owner Single owner

Life timeHave their own

lifetime

Have their own

lifetimeOwner's life time

Child objectChild objects all are

independent

Child objects

belong to a single

parent

Child objects

belong to a single

parent

Multiplicity

�Objects can hold arrays or vectors of other objects

�Objects can hold many of the same kind of objects in

separate instance variables.

� In UML this can be shown by placing a multiplicity

expression on the far end of the association.

�Multiplicity expressions can be simple numbers, ranges, or a

combination of both.

�BinaryTreeNode uses a multiplicity of 2.

Association stereotypes

«create» stereotype�The «create» stereotype indicates that the target

of the association is created by the source.

�The implication is that the source creates the

target and then passes it around to other parts of

the system.

«local» stereotype

� The «local» stereotype is used when the source class creates

an instance of the target and holds it in a local variable.

� The implication is that the created instance does not survive

the member function that creates it.

� Tt is not held by any instance variable nor passed around the

system in any way.

«Parameter» Stereotype� The «parameter» stereotype shows that the source class gains

access to the target instance though the parameter of one of its

member functions.

� The implication is that the source forgets all about this object once

the member function returns.

� The target is not saved in an instance variable.

Delegate» stereotype

� The «delegate» stereotype is used when the source class

forwards a member function invocation to the target.

� There are a number of design patterns where this technique

is applied, such as PROXY, DECORATOR, and COMPOSITE