Assignment No: 1

Purpose: Understanding the implementation details of relationships

among classes
Lab pre work: Prepare a class diagram from the given problem description using
UML2.0
notations.
Laboratory work: Implement the class diagram with a suitable object oriented
language.
Theory:
Class Diagrams

Class diagrams are visual representations of the static structure and composition of a particular
system using the conventions set by the Unified Modeling Language (UML). Out of all the UML
diagram types it is one of the most used ones. System designers use class diagrams as a way of
simplifying how objects in a system interact with each other. Using class diagrams, it is easier to
describe all the classes, packages, and interfaces that constitute a system and how these
components are interrelated. For example, a simple class diagram may be used to show how an
organization such as a convenient store chain is set up. On the other hand, precisely detailed
class diagrams can readily be used as the primary reference for translating the designed system
into a programming code.
The following figure is an example of a simple class diagram:

Simple class diagram with attributes and operations

In the example, a class called loan account is depicted. Classes in class diagrams are
represented by boxes that are partitioned into three:

1. The top partition contains the name of the class.

2. The middle part contains the classs attributes.
3. The bottom partition shows the possible operations that are associated with
the class.

Those should be pretty easy to see in the example: the class being described is a loan account,
some of whose attributes include the type of loan, the name of the borrower/loaner, the specific
date the loan was released and the loan amount. As in the real world, various transactions or
operations may be implemented on existing loans such as renew and extend. The example shows
how class diagrams can encapsulate all the relevant data in a particular scenario in a very
systematic and clear way.
In object-oriented modeling, class diagrams are considered the key building blocks that enable
information architects, designers, and developers to show a given systems classes, their
attributes, the functions or operations that are associated with them, and the relationships among
the different classes that make up a system.
Relationships in Class Diagrams
Classes are interrelated to each other in specific ways. In particular, relationships in class
diagrams include different types of logical connections. The following are such types of logical
connections that are possible in UML:

Association

Directed Association

Reflexive Association

Multiplicity

Aggregation

Composition

Inheritance/Generalization

Realization

Association

Association
is a broad term that encompasses just about any logical connection or relationship between
classes. For example, passenger and airline may be linked as above:
Directed Association

Directed Association
refers to a directional relationship represented by a line with an arrowhead. The arrowhead
depicts a container-contained directional flow.

Reflexive Association

Reflexive Association
occurs when a class may have multiple functions or responsibilities. For example, a staff
working in an airport may be a pilot, aviation engineer, a ticket dispatcher, a guard, or a
maintenance crew member. If the maintenance crew member is managed by the aviation
engineer there could be a managed by relationship in two instances of the same class.
Multiplicity

Multiplicity
is the active logical association when the cardinality of a class in relation to another is being
depicted. For example, one fleet may include multiple airplanes, while one commercial airplane
may contain zero to many passengers. The notation 0..* in the diagram means zero to many.

Aggregation

Aggregation
refers to the formation of a particular class as a result of one class being aggregated or built as a
collection. For example, the class library is made up of one or more books, among other
materials. In aggregation, the contained classes are not strongly dependent on the life cycle of the
container. In the same example, books will remain so even when the library is dissolved. To
render aggregation in a diagram, draw a line from the parent class to the child class with a
diamond shape near the parent class.
Composition

is very similar to the aggregation relationship, with the only difference being its key purpose of
emphasizing the dependence of the contained class to the life cycle of the container class. That
is, the contained class will be obliterated when the container class is destroyed. For example, a
shoulder bags side pocket will also cease to exist once the shoulder bag is destroyed. To depict a
composition relationship in a UML diagram, use a directional line connecting the two classes,
with a filled diamond shape adjacent to the container class and the directional arrow to the
contained class.
Inheritance / Generalization

Inheritance
refers to a type of relationship wherein one associated class is a child of another by virtue of
assuming the same functionalities of the parent class. In other words, the child class is a specific
type of the parent class. To depict inheritance in a UML diagram, a solid line from the child class
to the parent class is drawn using an unfilled arrowhead.
Realization

Realization
denotes the implementation of the functionality defined in one class by another class. To show
the relationship in UML, a broken line with an unfilled solid arrowhead is drawn from the class
that defines the functionality to the class that implements the function. In the example, the
printing preferences that are set using the printer setup interface are being implemented by the
printer.

Conclusion Class diagram relationships are easy to understand

If you are a programmer or systems designer, youll be building or analyzing class diagrams
quite often since they are, after all, the building blocks of object-oriented modeling. As
demonstrated by this article, class diagram relationships are fairly easy to understand. As a rule
of thumb, keeping class diagrams as simple as possible allows them to be more easily understood
and appreciated by different types of audiences. For this purpose, remember to label your classes
and relationships as descriptive as possible. Lastly, class diagrams also evolve as the real world
systems they represent change. This implies that you dont need to put in much detail in your
first draft. All the classes, interfaces and relationships that are integral to the system or
application you are designing will eventually emerge as the development process moves forward.

Assignment No: 2
Purpose: Implementation of a design model
Lab pre work: Prepare a design model from analysis model in the form of UML 2
class diagram.
Laboratory work: Implement the design model with a suitable object oriented
language

Overview:
The class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing and documenting different aspects of a
system but also for constructing executable code of the software application.
The class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modelling of object oriented
systems because they are the only UML diagrams which can be mapped directly with object
oriented languages.
The class diagram shows a collection of classes, interfaces, associations, collaborations and
constraints. It is also known as a structural diagram.

Purpose:
The purpose of the class diagram is to model the static view of an application. The class
diagrams are the only diagrams which can be directly mapped with object oriented languages and
thus widely used at the time of construction.
The UML diagrams like activity diagram, sequence diagram can only give the sequence flow of
the application but class diagram is a bit different. So it is the most popular UML diagram in the
coder community.
So the purpose of the class diagram can be summarized as:

Analysis and design of the static view of an application.

Describe responsibilities of a system.

Base for component and deployment diagrams.

Forward and reverse engineering.

How to draw Class Diagram?

Class diagrams are the most popular UML diagrams used for construction of software
applications. So it is very important to learn the drawing procedure of class diagram.
Class diagrams have lot of properties to consider while drawing but here the diagram will be
considered from a top level view.
Class diagram is basically a graphical representation of the static view of the system and
represents different aspects of the application. So a collection of class diagrams represent the
whole system.
The following points should be remembered while drawing a class diagram:

The name of the class diagram should be meaningful to describe the aspect of the system.

Each element and their relationships should be identified in advance.

Responsibility (attributes and methods) of each class should be clearly identified.

For each class minimum number of properties should be specified. Because unnecessary
properties will make the diagram complicated.

Use notes when ever required to describe some aspect of the diagram. Because at the end
of the drawing it should be understandable to the developer/coder.

Finally, before making the final version, the diagram should be drawn on plain paper and
rework as many times as possible to make it correct.

Now the following diagram is an example of an Order System of an application. So it describes a

particular aspect of the entire application.

First of all Order and Customer are identified as the two elements of the system and they
have a one to many relationship because a customer can have multiple orders.

We would keep Order class is an abstract class and it has two concrete classes
(inheritance relationship) SpecialOrder and NormalOrder.

The two inherited classes have all the properties as the Order class. In addition they have
additional functions like dispatch () and receive ().

So the following class diagram has been drawn considering all the points mentioned above:

Where to use Class Diagrams?

Class diagram is a static diagram and it is used to model static view of a system. The static view
describes the vocabulary of the system.
Class diagram is also considered as the foundation for component and deployment diagrams.
Class diagrams are not only used to visualize the static view of the system but they are also used
to construct the executable code for forward and reverse engineering of any system.
Generally UML diagrams are not directly mapped with any object oriented programming
languages but the class diagram is an exception.
Class diagram clearly shows the mapping with object oriented languages like Java, C++ etc. So
from practical experience class diagram is generally used for construction purpose.
So in a brief, class diagrams are used for:

Describing the static view of the system.

Showing the collaboration among the elements of the static view.

Describing the functionalities performed by the system.

Construction of software applications using object oriented languages.

Assignment No:3
Purpose: Implementation of a state model from the given description.
Lab pre work: Prepare a state model from the given problem description and draw a
state
diagram using UML2 notations
Laboratory work: Implement the state model with a suitable object oriented
language

Overview:
The name of the diagram itself clarifies the purpose of the diagram and other details. It describes
different states of a component in a system. The states are specific to a component/object of a
system.

A Statechart diagram describes a state machine. Now to clarify it state machine can be defined as
a machine which defines different states of an object and these states are controlled by external
or internal events.
Activity diagram explained in next chapter, is a special kind of a Statechart diagram. As
Statechart diagram defines states it is used to model lifetime of an object.

Purpose:
Statechart diagram is one of the five UML diagrams used to model dynamic nature of a system.
They define different states of an object during its lifetime. And these states are changed by
events. So Statechart diagrams are useful to model reactive systems. Reactive systems can be
defined as a system that responds to external or internal events.
Statechart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is triggered. So
the most important purpose of Statechart diagram is to model life time of an object from creation
to termination.
Statechart diagrams are also used for forward and reverse engineering of a system. But the main
purpose is to model reactive system.
Following are the main purposes of using Statechart diagrams:

To model dynamic aspect of a system.

To model life time of a reactive system.

To describe different states of an object during its life time.

Define a state machine to model states of an object.

How to draw Statechart Diagram?

Statechart diagram is used to describe the states of different objects in its life cycle. So the
emphasis is given on the state changes upon some internal or external events. These states of
objects are important to analyze and implement them accurately.
Statechart diagrams are very important for describing the states. States can be identified as the
condition of objects when a particular event occurs.
Before drawing a Statechart diagram we must have clarified the following points:

Identify important objects to be analyzed.

Identify the states.

Identify the events.

The following is an example of a Statechart diagram where the state of Order object is analyzed.
The first state is an idle state from where the process starts. The next states are arrived for events
like send request, confirm request, and dispatch order. These events are responsible for state
changes of order object.
During the life cycle of an object (here order object) it goes through the following states and
there may be some abnormal exists also. This abnormal exit may occur due to some problem in
the system. When the entire life cycle is complete it is considered as the complete transaction as
mentioned below.
The initial and final state of an object is also shown below.

Where to use Statechart Diagrams?

From the above discussion we can define the practical applications of a Statechart diagram.
Statechart diagrams are used to model dynamic aspect of a system like other four diagrams
disused in this tutorial. But it has some distinguishing characteristics for modeling dynamic
nature.
Statechart diagram defines the states of a component and these state changes are dynamic in
nature. So its specific purpose is to define state changes triggered by events. Events are internal
or external factors influencing the system.
Statechart diagrams are used to model states and also events operating on the system. When
implementing a system it is very important to clarify different states of an object during its life
time and statechart diagrams are used for this purpose. When these states and events are
identified they are used to model it and these models are used during implementation of the
system.

If we look into the practical implementation of Statechart diagram then it is mainly used to
analyze the object states influenced by events. This analysis is helpful to understand the system
behaviour during its execution.
So the main usages can be described as:

To model object states of a system.

To model reactive system. Reactive system consists of reactive objects.

To identify events responsible for state changes.

Forward and reverse engineering.

Assignment No:4
Purpose: Preparing an interaction model from the given details
Prepare a use case model, sequence model and activity model from the given
description using

UML 2 notations.

Use Case Diagram:

Overview:
To model a system the most important aspect is to capture the dynamic behaviour. To clarify a bit
in details, dynamic behaviour means the behaviour of the system when it is running /operating.
So only static behaviour is not sufficient to model a system rather dynamic behaviour is more
important than static behaviour. In UML there are five diagrams available to model dynamic
nature and use case diagram is one of them. Now as we have to discuss that the use case diagram
is dynamic in nature there should be some internal or external factors for making the interaction.
These internal and external agents are known as actors. So use case diagrams are consists of
actors, use cases and their relationships. The diagram is used to model the system/subsystem of
an application. A single use case diagram captures a particular functionality of a system.
So to model the entire system numbers of use case diagrams are used.

Purpose:
The purpose of use case diagram is to capture the dynamic aspect of a system. But this definition
is too generic to describe the purpose.
Because other four diagrams (activity, sequence, collaboration and Statechart) are also having the
same purpose. So we will look into some specific purpose which will distinguish it from other
four diagrams.
Use case diagrams are used to gather the requirements of a system including internal and
external influences. These requirements are mostly design requirements. So when a system is
analyzed to gather its functionalities use cases are prepared and actors are identified.
Now when the initial task is complete use case diagrams are modelled to present the outside
view.
So in brief, the purposes of use case diagrams can be as follows:

Used to gather requirements of a system.

Used to get an outside view of a system.

Identify external and internal factors influencing the system.

Show the interacting among the requirements are actors.

How to draw Use Case Diagram?

Use case diagrams are considered for high level requirement analysis of a system. So when the
requirements of a system are analyzed the functionalities are captured in use cases.
So we can say that uses cases are nothing but the system functionalities written in an organized
manner. Now the second things which are relevant to the use cases are the actors. Actors can be
defined as something that interacts with the system.
The actors can be human user, some internal applications or may be some external applications.
So in a brief when we are planning to draw an use case diagram we should have the following
items identified.

Functionalities to be represented as an use case

Actors

Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system. So after
identifying the above items we have to follow the following guidelines to draw an efficient use
case diagram.

The name of a use case is very important. So the name should be chosen in such a way so
that it can identify the functionalities performed.

Give a suitable name for actors.

Show relationships and dependencies clearly in the diagram.

Do not try to include all types of relationships. Because the main purpose of the diagram
is to identify requirements.

Use note when ever required to clarify some important points.

The following is a sample use case diagram representing the order management system. So if we
look into the diagram then we will find three use cases (Order, SpecialOrder and NormalOrder)
and one actor which is customer.
The SpecialOrder and NormalOrder use cases are extended from Order use case. So they have
extends relationship. Another important point is to identify the system boundary which is shown
in the picture. The actor Customer lies outside the system as it is an external user of the system.

Where to Use Case Diagrams?

As we have already discussed there are five diagrams in UML to model dynamic view of a
system. Now each and every model has some specific purpose to use. Actually these specific
purposes are different angles of a running system.
So to understand the dynamics of a system we need to use different types of diagrams. Use case
diagram is one of them and its specific purpose is to gather system requirements and actors.
Use case diagrams specify the events of a system and their flows. But use case diagram never
describes how they are implemented. Use case diagram can be imagined as a black box where
only the input, output and the function of the black box is known.
These diagrams are used at a very high level of design. Then this high level design is refined
again and again to get a complete and practical picture of the system. A well structured use case
also describes the pre condition, post condition, exceptions. And these extra elements are used to
make test cases when performing the testing.
Although the use cases are not a good candidate for forward and reverse engineering but still
they are used in a slight different way to make forward and reverse engineering. And the same is
true for reverse engineering. Still use case diagram is used differently to make it a candidate for
reverse engineering.
In forward engineering use case diagrams are used to make test cases and in reverse engineering
use cases are used to prepare the requirement details from the existing application.
So the following are the places where use case diagrams are used:

Requirement analysis and high level design.

Model the context of a system.

Reverse engineering.

Forward engineering.

Sequence Diagram:

Overview:
From the name Interaction it is clear that the diagram is used to describe some type of
interactions among the different elements in the model. So this interaction is a part of dynamic
behaviour of the system.
This interactive behaviour is represented in UML by two diagrams known as Sequence diagram
and Collaboration diagram. The basic purposes of both the diagrams are similar.
Sequence diagram emphasizes on time sequence of messages and collaboration diagram
emphasizes on the structural organization of the objects that send and receive messages.

Purpose:
The purposes of interaction diagrams are to visualize the interactive behaviour of the system.
Now visualizing interaction is a difficult task. So the solution is to use different types of models
to capture the different aspects of the interaction.
That is why sequence and collaboration diagrams are used to capture dynamic nature but from a
different angle.
So the purposes of interaction diagram can be describes as:

To capture dynamic behaviour of a system.

To describe the message flow in the system.

To describe structural organization of the objects.

To describe interaction among objects.

How to draw Interaction Diagram?

As we have already discussed that the purpose of interaction diagrams are to capture the dynamic
aspect of a system. So to capture the dynamic aspect we need to understand what a dynamic
aspect is and how it is visualized. Dynamic aspect can be defined as the snap shot of the running
system at a particular moment.
We have two types of interaction diagrams in UML. One is sequence diagram and the other is a
collaboration diagram. The sequence diagram captures the time sequence of message flow from

one object to another and the collaboration diagram describes the organization of objects in a
system taking part in the message flow.
So the following things are to identified clearly before drawing the interaction diagram:

Objects taking part in the interaction.

Message flows among the objects.

The sequence in which the messages are flowing.

Object organization.

Following are two interaction diagrams modeling order management system. The first diagram is
a sequence diagram and the second is a collaboration diagram.

The Sequence Diagram:

The sequence diagram is having four objects (Customer, Order, SpecialOrder and NormalOrder).
The following diagram has shown the message sequence for SpecialOrder object and the same
can be used in case of NormalOrder object. Now it is important to understand the time sequence
of message flows. The message flow is nothing but a method call of an object.
The first call is sendOrder () which is a method of Order object. The next call is confirm ()
which is a method of SpecialOrder object and the last call is Dispatch () which is a method of
SpecialOrder object. So here the diagram is mainly describing the method calls from one object
to another and this is also the actual scenario when the system is running.

Where to use Interaction Diagrams?

We have already discussed that interaction diagrams are used to describe dynamic nature of a
system. Now we will look into the practical scenarios where these diagrams are used. To
understand the practical application we need to understand the basic nature of sequence and
collaboration diagram.
The main purposes of both the diagrams are similar as they are used to capture the dynamic
behaviour of a system. But the specific purposes are more important to clarify and understood.
Sequence diagrams are used to capture the order of messages flowing from one object to another.
And the collaboration diagrams are used to describe the structural organizations of the objects
taking part in the interaction. A single diagram is not sufficient to describe the dynamic aspect of
an entire system so a set of diagrams are used to capture is as a whole.
The interaction diagrams are used when we want to understand the message flow and the
structural organization. Now message flow means the sequence of control flow from one object
to another and structural organization means the visual organization of the elements in a system.
In a brief the following are the usages of interaction diagrams:

To model flow of control by time sequence.

To model flow of control by structural organizations.

For forward engineering.

For reverse engineering.

Activity Diagram:

Overview:
Activity diagram is another important diagram in UML to describe dynamic aspects of the
system.
Activity diagram is basically a flow chart to represent the flow form one activity to another
activity. The activity can be described as an operation of the system.
So the control flow is drawn from one operation to another. This flow can be sequential,
branched or concurrent. Activity diagrams deals with all type of flow control by using different
elements like fork, join etc.

Purpose:
The basic purposes of activity diagrams are similar to other four diagrams. It captures the
dynamic behaviour of the system. Other four diagrams are used to show the message flow from

one object to another but activity diagram is used to show message flow from one activity to
another.
Activity is a particular operation of the system. Activity diagrams are not only used for
visualizing dynamic nature of a system but they are also used to construct the executable system
by using forward and reverse engineering techniques. The only missing thing in activity diagram
is the message part.
It does not show any message flow from one activity to another. Activity diagram is some time
considered as the flow chart. Although the diagrams looks like a flow chart but it is not. It shows
different flow like parallel, branched, concurrent and single.
So the purposes can be described as:

Draw the activity flow of a system.

Describe the sequence from one activity to another.

Describe the parallel, branched and concurrent flow of the system.

How to draw Activity Diagram?

Activity diagrams are mainly used as a flow chart consists of activities performed by the system.
But activity diagram are not exactly a flow chart as they have some additional capabilities. These
additional capabilities include branching, parallel flow, swimlane etc.
Before drawing an activity diagram we must have a clear understanding about the elements used
in activity diagram. The main element of an activity diagram is the activity itself. An activity is a
function performed by the system. After identifying the activities we need to understand how
they are associated with constraints and conditions.
So before drawing an activity diagram we should identify the following elements:

Activities

Association

Conditions

Constraints

Once the above mentioned parameters are identified we need to make a mental layout of the
entire flow. This mental layout is then transformed into an activity diagram.
The following is an example of an activity diagram for order management system. In the diagram
four activities are identified which are associated with conditions. One important point should be
clearly understood that an activity diagram cannot be exactly matched with the code. The activity
diagram is made to understand the flow of activities and mainly used by the business users.
The following diagram is drawn with the four main activities:

Send order by the customer

Receipt of the order

Confirm order

Dispatch order

After receiving the order request condition checks are performed to check if it is normal or
special order. After the type of order is identified dispatch activity is performed and that is
marked as the termination of the process.

Where to use Activity Diagrams?

The basic usage of activity diagram is similar to other four UML diagrams. The specific usage is
to model the control flow from one activity to another. This control flow does not include
messages.
The activity diagram is suitable for modeling the activity flow of the system. An application can
have multiple systems. Activity diagram also captures these systems and describes flow from one
system to another. This specific usage is not available in other diagrams. These systems can be
database, external queues or any other system.
Now we will look into the practical applications of the activity diagram. From the above
discussion it is clear that an activity diagram is drawn from a very high level. So it gives high
level view of a system. This high level view is mainly for business users or any other person who
is not a technical person.

This diagram is used to model the activities which are nothing but business requirements. So the
diagram has more impact on business understanding rather implementation details.
Following are the main usages of activity diagram:

Modeling work flow by using activities.

Modeling business requirements.

High level understanding of the system's functionalities.

Investigate business requirements at a later stage.

Assignment No: 5
Purpose: Implement a Strategy design pattern
Map the participants for the strategy design pattern from a given problem
description andimplement with a suitable object oriented language

Theory:
In Strategy pattern, a class behavior or its algorithm can be changed at run time. This type of
design pattern comes under behavior pattern.
In Strategy pattern, we create objects which represent various strategies and a context object
whose behavior varies as per its strategy object. The strategy object changes the executing
algorithm of the context object.
Implementation

We are going to create a Strategy interface defining an action and concrete strategy classes
implementing the Strategy interface. Context is a class which uses a Strategy.
StrategyPatternDemo, our demo class, will use Context and strategy objects to demonstrate
change in Context behaviour based on strategy it deploys or uses.

Step 1

Create an interface.
Strategy.java
publicinterfaceStrategy{
publicintdoOperation(int num1,int num2);
}

Step 2

Create concrete classes implementing the same interface.

OperationAdd.java
publicclassOperationAddimplementsStrategy{
@Override
publicintdoOperation(int num1,int num2){
return num1 + num2;
}
}

OperationSubstract.java
publicclassOperationSubstractimplementsStrategy{
@Override
publicintdoOperation(int num1,int num2){
return num1 - num2;
}
}

OperationMultiply.java
publicclassOperationMultiplyimplementsStrategy{
@Override
publicintdoOperation(int num1,int num2){

return num1 * num2;

}
}

Step 3

Create Context Class.

Context.java
publicclassContext{
privateStrategystrategy;
publicContext(Strategy strategy){
this.strategy= strategy;
}
publicintexecuteStrategy(int num1,int num2){
returnstrategy.doOperation(num1, num2);
}
}

Step 4

Use the Context to see change in behaviour when it changes its Strategy.
StrategyPatternDemo.java
publicclassStrategyPatternDemo{
publicstaticvoid main(String[]args){
Contextcontext=newContext(newOperationAdd());
System.out.println("10 + 5 = "+context.executeStrategy(10,5));
context=newContext(newOperationSubstract());
System.out.println("10 - 5 = "+context.executeStrategy(10,5));
context=newContext(newOperationMultiply());
System.out.println("10 * 5 = "+context.executeStrategy(10,5));
}
}

Step 5

Verify the output.

10 + 5 = 15
10 - 5 = 5
10 * 5 = 50

Assignment No: 6
Purpose: Implement a State design pattern
Map the participants for the state design pattern from a given problem description
and
implement with a suitable object oriented language

In State pattern a class behavior changes based on its state. This type of design pattern comes
under behavior pattern.
In State pattern, we create objects which represent various states and a context object whose
behavior varies as its state object changes.
Implementation

We are going to create a State interface defining an action and concrete state classes
implementing the State interface. Context is a class which carries a State.
StatePatternDemo, our demo class, will use Context and state objects to demonstrate change in
Context behavior based on type of state it is in.

Step 1

Create an interface.
State.java
public interface State {
public void doAction(Context context);
}

Step 2

Create concrete classes implementing the same interface.

StartState.java
public class StartState implements State {
public void doAction(Context context) {
System.out.println("Player is in start state");
context.setState(this);
}
public String toString(){
return "Start State";
}
}

StopState.java
public class StopState implements State {
public void doAction(Context context) {

System.out.println("Player is in stop state");

context.setState(this);
}
public String toString(){
return "Stop State";
}
}

Step 3

Create Context Class.

Context.java
public class Context {
private State state;
public Context(){
state = null;
}
public void setState(State state){
this.state = state;
}
public State getState(){
return state;
}
}

Step 4

Use the Context to see change in behaviour when State changes.

StatePatternDemo.java
public class StatePatternDemo {
public static void main(String[] args) {
Context context = new Context();
StartStatestartState = new StartState();
startState.doAction(context);
System.out.println(context.getState().toString());
StopStatestopState = new StopState();
stopState.doAction(context);
System.out.println(context.getState().toString());
}
}

Step 5

Verify the output.

Player is in start state
Start State
Player is in stop state
Stop Stat

Assignment No: 7
Purpose: Understand the concept of Test driven Development
Implement a design level class diagram (given as an input) with Test Driven
Developmentapproach.

What is Test-Driven Development (TDD)?

Test-driven development starts with developing test for each one of the features. The test might
fail as the tests are developed even before the development. Development team then develops
and refactors the code to pass the test.
Test-driven development is related to the test-first programming evolved as part of extreme
programming concepts.

Test-Driven Development Process:

Add a Test

Run all tests and see if the new one fails

Write some code

Run tests and Refactor code

Repeat

Example:

Context of Testing:

Valid inputs

Invalid inputs

Errors, exceptions, and events

Boundary conditions

Everything that might break

Benefits of TDD:

Much less debug time

Code proven to meet requirements

Tests become Safety Net

Near zero defects

Shorter development cycles

Assignment No: 8
Objective: Understand and implement the Concept of a reusable
component
Implement a reusable component in form of jar file (or in equivalent form for other
OO languages). Use this component in a separate client implementation by
importing the component as a jar file (or equivalent form for other OO language).

Theory:
What is Software Component Reuse?

Software component reuse is the software engineering practice of creating new software
applications from existing components, rather than designing and building them from scratch.
Reusable components can be requirements specifications, design documents, source code, user
interfaces, user documentation, or any other items associated with software. All products
resulting from the software development life cycle have the potential for reuse.

Business Case for Software Component Reuse

Reusable components are easier to maintain (over time) and typically have a higher quality value
(more robust and fewer errors). The practice of component reuse supports the motivation for
development of specialized GIS applications. The business case is reduced application
development time, reduced application cost, and improved application quality. Assuming the
motivation for use and development of specialized GIS application software is one or several of
the following:
o To reduce time
o To reduce effort
o To save dollars or earn dollars
o To improve quality
Then, the easiest way to accomplish these goals includes one or both of the following:
o Improve staff effectiveness (produce more with less through applied use of
technology or incentives)
o Decrease production workload (produce less new output by reusing previously
produced materials to meet an equivalent or increased demand)
Examples are provided below.
o Replace manual drafting of multiple copies of a map with reprographics
technology or create a reusable electronic map and produce copies by replotting
the data (reuse of previously produced data)
o Replace production of GIS application source code for multiple applications (by
potentially multiple staff) by sharing and reusing software components of
previously produced applications

Obstacles to Software Reuse

Frequent architecture and system changes.

Organizational and cultural issues; reuse requires a fairly drastic change.

Lack of automation tools to assist with specific reuse mechanisms.

Higher up-front investments.

Organization size and amount of application development performed will be proportional

to payback. Smaller organizations will not benefit as much from code reuse.

Too large of a project or effort is often attempted initially.

Experience has shown that it requires three to five years to implement a formal reuse
program across a large corporation.

Initially, the end-to-end software life cycle will be longer.

Lack of component indexing and searching mechanisms.

Developing a componentization scheme or architecture reflecting which components

need to be built and which components should be acquired from other providers in the
industry. If a component is expected or will be available soon from an outside source,
then a wait versus build decision needs to be made.

Characteristics Needed for Qualification as a Reusable Component

In order for a component (specification, design, code) to be reusable, it needs to have certain
qualities that contribute to its reusability. Reusability is defined as the extent to which a software
component can be used with or without changes in multiple software systems, versions, or
implementations (McClure 97). A list of those characteristics generally sought after to promote
reusability as presented by McClure are as follows:
o General with build-in adaptability/specialization
o Widely applicable
o Modular/self-contained
o Complete and consistent
o Machine independent
o Implementation/application independent
o Data model independent
o Reliable
o Robust (good error/exception handling built in)
o Understandable/well documented
o Adaptable/extensible
o Standardized

o Portable (across hardware and operating systems)

o Certified/testable
o Maintainable
o Encapsulated (details are isolated and hidden from user)

Guidelines for Creating a Reusable Component

McClure has also provided the software industry with techniques for building reusable
components independent of whether or not an object-oriented language is available. This makes
the technique applicable to GIS applications development in the entire line of Esri development
languages, to include traditional proprietary languages, such as AML or Avenue, as well as the
Open Development Environment languages, such as Visual Basic, C++, or TclTk. The techniques
for creating components most applicable to reuse, as presented by McClure, are as follows:
1. Generalize
2. Standardize
3. Automate
4. Certify
5. Document

How to Build Reusable Components

Listed below are several practical guidelines and advice to assist developers in the creation of
new reusable components:

Collaborate with multiple software engineers throughout the design and definition
phases.

Install a reuse analysis stage into all detailed design work, so that the opportunities for
reuse can be effectively assessed.

Before building a new component, always check to make sure it does not exist. Always
attempt reuse before creating a new component.

Strive for a clearly defined, single purpose per component.

Document all component interface requirements, also known as parameter lists or

function signatures, in the design phase. Do not attempt to start at the coding phase and
"design as you go." Remember that component reuse requires much more up-front
planning. More design time and less construction time should be expected and planned
for by project managers.

With the inputs, results, or outputs and a description of a component, another software
developer should be able to use that component without ever knowing what the code does
inside the component. The component should pass this "self test."

Strive for loosely coupled and highly cohesive components.

Develop components with overall future use in mind, not just a single project.

Always put extra effort into error handling and making components robust.

Develop a certification program and communicate the certification criteria to all

component developers.

Use consistent design styles.

Implement and use naming conventions.

When creating documentation, think of explaining the component to a developer

unfamiliar with the internal workings or a developer who will truly never look at the code
of the component.

Thoroughly test the component.