A

Software Design Specification

for
Project title
in partial fulfillment
for the award of the Degree of
Bachelors of Technology
in Department of Computer Science & Engineering

Submitted To:

Submitted By:

Mohit Khandelwal

Abhinav Malik

Project In-charge

Ashish Chandrawat

CS & IT Department

Mohit Kumar Meena

IET Alwar
Department of Computer Science & Engineering
Institute of Engineering and Technology
Alwar
October 2014

Candidates Declaration
We hereby declare that the work, which is being presented in this report, entitled
Implementation of Travelling Salesman Problem in partial fulfillment for the award of
Degree of Bachelor of Technology in department of Computer Science & Engineering,
Institute of Engineering and Technology affiliated to, Rajasthan Technical University is a
record of our own investigations carried under the Guidance of Mr. Mohit Khandelwal,
Department of Computer Science & Engineering, IET Alwar.
We have not submitted the matter presented in this report any where for the award of any other
Degree.

Abhinav Malik (11EIACS001)

Ashish Chandrawat (11EIACS018)

Mohit Kumar Meena (11EIACS058)

Computer Science & Engineering,

Counter Signed by

Mr. Mohit Khandelwal

Preface

The Traveling Salesman Problem (TSP) is one of these problems, which is generally regarded as
the most intensively studied problem in computational mathematics.
Assuming a traveling salesman has to visit a number of given cities, starting and ending at the
same city. This tour, which represents the length of the travelled path, is the TSP formulation. As
the number of cities increases, the determination of the optimal tour (in this case a Hamiltonian
tour), becomes inexorably complex. A TSP decision problem is generally classified as NPComplete problem.
This paper describes the process of UML modeling for solving the traveling salesman problem
using branch and bound algorithm. The analysis and problem solving in this way has many
advantages just because it provides a clear definition of requirements and specific plan that we
will later use to create specific applications. This is a good way to resolve because the UML
describes the source code, models help to visualize the system as it is or what it should be and
allow you to determine the structure and behavior of the system. Static and dynamic diagrams
implemented in developing tools for modeling, as well as a description of specific applications
and testing are mentioned. With this approach we describe modeling tool that can be used in the
development of specific solutions and a way of establishing explicit links between concepts and
execution code.

Acknowledgement

It is a matter of great pleasure and privilege for us to present this report of our minor project,
Implementation of Travelling Salesman Problem that we are developing for fulfillment of
our Bachelor of Technology in Computer Science and Engineering. We have received enormous
help, guidance and advice from many people and we feel that it will be not be right to mention a
line about at least some of them. The authors would like to express their utmost gratitude to the
Institute of Engineering and Technology, Alwar for providing opportunity to author to pursue
for the degree of Bachelor of Technology.
We are grateful to Dr. V.K. Agarwal (Chairman, IET Group of Institution) and Dr. Manju
Agarwal (Executive Director, IET Group of Institutions) for providing us the opportunity to
study in this institution as well as providing us with all the necessary facilities.
Our principal Dr. Anil Kumar Sharma (Institute of Engineering & Technology, Alwar) has
been source of inspiration to us in our work sincerely. We are also thankful to Dr. Basant
Kumar Verma (H.O.D., CSE) and Mr. Mohit Khandelwal (Project In-charge) for their
encouragement and guidance. Their words of encouragement led us to finish our work
successfully.
We are also thankful to our project guide Mr. Vedant Rastogi (Computer Science Department)
and also to all faculty members of Computer Science & Engineering Department and all other
for help given to us directly or indirectly for the success of this minor project.

TableofContents
TableofContents..........................................................................................................................iv
1. Introduction..............................................................................................................................1
1.1

BackgroundStudy........................................................................................................................1

1.2

ProjectScope...............................................................................................................................1

2. OverallDescription..................................................................................................................2
2.1

ProductPerspective......................................................................................................................2

2.2

ProductFeatures..........................................................................................................................2

2.3

UserClassesandCharacteristics..................................................................................................2

2.4

OperatingEnvironment................................................................................................................3

2.5

DesignandImplementationConstraints......................................................................................4

2.6

AssumptionsandDependencies...................................................................................................4

2.7

UserInterfaces.............................................................................................................................4

2.7.1

Home Screen..............................................................................................................4

2.7.2

User Input..................................................................................................................5

2.7.3

Optimal Path..............................................................................................................5

2.8

HardwareInterfaces.....................................................................................................................5

2.8.1

Central Processing Unit (CPU)..................................................................................5

2.8.2

Memory......................................................................................................................5

2.8.3

Hard disk....................................................................................................................5

2.9

SoftwareInterfaces......................................................................................................................5

2.10

CommunicationsInterfaces..........................................................................................................5

3. OtherNonfunctionalRequirements.......................................................................................6
3.1

PerformanceRequirements..........................................................................................................6

3.2

SafetyRequirements....................................................................................................................6

3.3

SecurityRequirements.................................................................................................................6

3.4

SoftwareQualityAttributes.........................................................................................................6

4. DesignSpecifications...............................................................................................................6
4.1

Assumptions................................................................................................................................6

4.2

Constraints...................................................................................................................................6

4.3

SystemEnvironment....................................................................................................................7

4.4

DesignMethodology....................................................................................................................7

4.5

RiskandVolatileareas................................................................................................................7

5. Architecture..............................................................................................................................7
5.1

Overview.....................................................................................................................................7

5.2

Subsystem, Component, or Module 1 N...................................................................................7

5.3

Strategy 1N..............................................................................................................................7

6. UML diagrams.........................................................................................................................7
7. Database Schema.....................................................................................................................7
7.1

Tables, Fields and Relationships..................................................................................................7

7.1.1

Databases...................................................................................................................8

7.1.2

New Tables................................................................................................................8

8. Cost Estimation........................................................................................................................8
9. AppendixA:Glossary..............................................................................................................8
AppendixB:References................................................................................................................8

1.

Introduction

1.1

BackgroundStudy

Mathematical problems related to the Traveling Salesman Problem were studied in the 1800s by
the Irish mathematician Sir William Rowan Hamilton and by the British mathematician Thomas
Penyngton Kirkman.
TSPs were first studied in the 1930s by mathematician and economist Karl Menger in Vienna and
Harvard. Solution methods of TSP began to appear in papers in the mid-1950s; these papers used a
variety of minor variations of the term Traveling Salesman Problem. Dantzig, Fulkerson, and
Johnson referred to the traveling-salesman problem in 1954. Heller also used travelling
salesmans problem in 1954. Morton and Land preferred the travelling salesman problem in
1955 and they originally called it the laundry van problem. In the following decades, the problem
has been studied by many researchers from mathematics, computer science, chemistry, physics, and
other sciences.
Although TSP is easy to understand, it is very difficult to solve. Richard M. Karp showed in 1972
that the Hamiltonian cycle problem was NP-complete (non-deterministic polynomial-time hard),
which implies the NP-hardness of TSP. NP-hard, is a class of problems that are informally the
hardest problems in NP which means no polynomial-time algorithm is known for solving TSP. This
supplied a scientific explanation for the apparent computational difficulty of finding optimal tours.
The solution methods for TSP have become sophisticated, and solvable instances have become
larger and larger. Held and Karp solved a TSP uzsing 64 cities in 1971. Later in 1975, Camerini,
Fratta, and Maffioli solved a TSP with 67 cities. In 1977, Grotschel solved a TSP using 120 cities in
and around Germany.

In 1973 Lin and Kernighan obtained the data set from R. Habermann, and used 318 points that arose
in a drilling application, where the drill was a pulsed laser. This instance was first solved by H.
Crowder and M. W. Padberg in 1980. In 1987, Padberg and Rinaldi solved a TSP consisting of 532
AT&T switch locations in the USA. A TSP with 666 cities was first solved by Holland and
Groetschel, appearing in Olaf Holland's 1987 PhD Thesis. The data set consists of interesting cities
from around the world and the inter-city distances are specified by a function that approximates the
great circle distances on the globe.

1.2

ProjectScope

Suppose a salesperson needs to travel from a city to all the other cities exactly once to sell his
products and return back to the city he started from. He wants to do this while traveling the
minimum total distance. This project helps to answer that question using the Traveling Salesman
Problem (TSP).

2.

OverallDescription

2.1

ProductPerspective

TSP is an application of graph theory. In terms of graph theory, given a list of cities and their pairwise distance, the task is to find a shortest possible tour (Hamiltonian Cycle) that visits every city
exactly once. Even though TSP is easy to understand, it is very difficult to solve. Researchers have
proven that Traveling Salesman Problem is NP-complete.
This project involves a study of the history and growth of TSP, an analysis of solution methods of
TSP, a discussion of other applications of TSP, an implementation of TSP using MATLAB, and an
introduction to related problems such as Chinese Postman Problem. One of the main objectives of
this project is to use MATLAB to implement some solution methods of TSP.

There are many different problems in graph theory that have attracted much attention. One such
problem is the Traveling Salesman Problem (TSP), which refers to a salesman who wants to find a
shortest possible tour that visits every city exactly once and returns back to the city from which he
started. In terms of graph theory, given a list of nodes (cities) and their pair-wise distance, the task is
to find the shortest possible tour that visits every node exactly once. The distance between every
pair of cities is symmetric, because the direction of traversal of the given arc does not matter. Since
the start node and the end nodes are the same the tour creates a Hamiltonian cycle, which is a cycle
in the graph that visits each vertex exactly once.

2.2

ProductFeatures

The purpose of the project is to introduce computation, modify and write code using MATLAB,
implement and compare various algorithms, and heuristic solutions to solve TSP.

This project will concentrate on solving the problem of travelling salesman by reducing his
time and effort.

2.3

This will reduce the distance he has to cover in minimum span of time.

UserClassesandCharacteristics

There will be 2 classes as follows:

1. Salesman
2. System
As indicated above, there are two classes which will be interacting with each other. Salesman class
will carry the attributes and methods of a salesman and System class will carry the attributes and
methods of the algorithm, which will be used for calculating the optimal path i.e. shortest tour.
Attributes of Salesman Class are:

Name_of_salesman (name of the salesperson)

Number_of_products (how many products he has to deliver)

Number_of_cities (number of cities he has to visit inorder to deliver the product)

Optimal_path

Attribute of System Class are:

list_of_cities (all the cities among which we will calculate the pair-wise distance)

Method of System Class are:

optimal_path() (will generate the optimal path using the pair-wise distance between the
cities)

2.4

OperatingEnvironment

Server Side:
Software Requirement:
Software

Version

Operating System

Windows 7

Reason
Version 7.9 does not run on
Windows earlier than XP.
Saving workspace vari-ables
and their values to a MATLAB

MATLAB Compiler Runtime

V 7.5 or later

script
conv2 function

perfor-mance

improvements with three inputs

(MCR)
Hardware Requirement:
Hardware
Processor
Disk Space

Minimum Requirement
Intel Pentium 4
5 GB to accommodate the

Optimal Requirement
Dual Core / Core 2 duo
10 GB

server software installation and

RAM

log files.
1 GB

2 GB

Client Side:
Client
Java
.NET

2.5

Development Environment
JRE/JDK 1.6 or higher
.NET Framework 2.0, 3.0, 3.5, and 4.0

DesignandImplementationConstraints

The primary design constraint is the mobile platform. Since the application is designated for
Android mobile handsets, limited screen size and resolution will be a major design consideration.
Creating a user interface which is both effective and easily navigable will pose a difficult challenge.
Other constraints such as limited memory and processing power are also worth considering.

2.6

AssumptionsandDependencies

In this application we are assuming the distance of 10 cities as raw data for the calculation purpose.
We also must assume that if there are two cities, city A and city B for example, it costs the same
amount of money to travel from A to B as it does from B to A. Because algorithm is dependent on
the pairwise distance between the cities. User will select the cities through which he has to pass and
based on the algorithm shortest path will be calculated.

2.7

UserInterfaces

The interface will meet the following requirements to conform to the users needs. It will be simple
and easy to understand. Controls which allow the user to interact with the application will be clear
and imply their functionality within the application. The interface will include user inputs as well as
two graphics, outlined below. The graphics displayed to the user will provide a visual representation
of the output produced.
2.7.1

HomeScreen

This is the starting page of the application in which user will give the number of cities.

2.7.2

UserInput

In this graphic user enter the detail of the city which he want to travel.
2.7.3

OptimalPath

According to the user input system will calculate the optimal path i.e. shortest path and provides to
the user.

2.8

HardwareInterfaces

2.8.1

Central Processing Unit (CPU)

Computers with more CPU cores can outperform those with a lower core count, but results will
vary with the MATLAB application. MATLAB automatically uses multithreading to exploit the
natural parallelism found in many MATLAB applications. But not all MATLAB functions are
multithreaded, and the speed-up varies with the algorithm.

MATLAB performance is dependent on the presence of floating-point hardware. On many CPUs,

the number of Floating-Point Units (FPUs) equals the number of CPU cores. However, on some
processors, a single FPU may be shared between multiple CPU cores.
2.8.2

Memory

Computer can suffer performance degradation due to thrashing when MATLAB and the programs
run concurrently with it use more than the available physical memory and computer must resort to
virtual memory.
2.8.3

Hard disk

The hard disk speed is a significant factor in MATLAB start-up time. Once MATLAB is running,
disk speed is only a factor if a MATLAB application's performance profile is dominated by file I/O,
or if system is using virtual memory.

2.9

SoftwareInterfaces

On Windows computers, using 64-bit Windows and the 64-bit version of MATLAB is the right
choice for most situations, because it can access the larger amounts of memory in modern
computers, and support for 32-bit Windows will end in the next couple of years.

2.10 CommunicationsInterfaces
There is no requirement associated with any communication functions required by this application,
including e-mail, web browser.

3.

OtherNonfunctionalRequirements

3.1

PerformanceRequirements

Some solution methods of TSP include:

Brute force method.

Approximations
o Nearest Neighbor (Greedy)
o Greedy Approach

Branch and Bound method.

Brute-force method always works if given enough time and care. Because of its nature, it is
convenient for relatively small number of nodes. We know that as the number of nodes increases the
number of tours increases factorially; therefore, using Brute-force method to solve TSP with a large
number of nodes can be frustrating and can even take years or centuries to solve. Brute-force
method is very inefficient as gets larger.
We can also think of solving TSP using a Nearest Neighbor heuristic. Heuristics are methods which
cannot guarantee to produce optimal solutions, but which, we hope, produces fairly good solutions.
By comparing the timings of Brute-force and Branch and Bound we can see that Branch and Bound
method solves fast in MATLAB. When we ran the MATLAB code using Brute-force method for n
=12 it took time to give results, while as for Branch and Bound it took only 43 second to produce
results.

3.2

SafetyRequirements

Software safety is a software quality assurance activity that focuses on the identification and
assessment of potential hazards that may affect software negatively and cause an entire system to
fail. If hazards can be identified early in the software engineering process, software design features
can be specified that will either eliminate or control potential hazards.
As such there are no safety requirements with this application, other than any normal hazards of a
computer or laptop.

3.3

SecurityRequirements

As such there is no need of high level security, this software does not have any security issue. It is a
simple software which generates a shortest possible path out of the cities entered by the user. No

user identity authentication is required here and there is no specific requirement regarding security
or privacy surrounding the use of the product or protection of data used or created by the software.

3.4

SoftwareQualityAttributes

SQA encompasses
(1) A quality management approach,
(2) Effective software engineering technology (methods and tools),
(3) Formal technical reviews that are applied throughout the software process,
(4) A multitier testing strategy,
(5) Control of software documentation and the changes made to it,
(6) A procedure to ensure compliance with software development standards (when applicable), and
(7) measurement and reporting mechanisms.
When we examine an item based on its measurable characteristics, two kinds of quality may be
encountered: quality of design and quality of conformance.
Quality of design refers to the characteristics that designers specify for an item. The grade of
materials, tolerances, and performance specifications all contribute to the quality of design. As
higher-grade materials are used, tighter tolerances and greater levels of performance are specified,
the design quality of a product increases, if the product is manufactured according to specifications.
Quality of conformance is the degree to which the design specifications are followed during
manufacturing. Again, the greater the degree of conformance, the higher is the level of quality of
conformance.
Quality of conformance is an issue focused primarily on implementation. If the implementation
follows the design and the resulting system meets its requirements and performance goals,
conformance quality is high.
User satisfaction = compliant product + good quality + delivery within budget and schedule.

4.

DesignSpecifications

4.1

Assumptions

One basic assumption in TSP is to assume that the salesman has to return to the node where he starts
the tour; this node is usually referred to as the base city or depot. This assumption is called a closed
tour. For a closed tour any node can be selected as the starting node, but for practical reasons node 1
is set to be the starting node. Node 1 is then the base city or depot.

4.2

Constraints

While constructing or developing the system there are a few aspects to consider such as the
reliability, accuracy, maintainability, usability and the like which form the non-functional
requirements of the system.

The operating system to be used should be either Windows 7 or of a higher version because
on April 14 2014, Microsoft ended mainstream support for Windows XP. So we have to use
Windows 7(or higher version). Also its processing speed is high than windows XP.

4.3

SystemEnvironment

4.4

DesignMethodology

4.5

RiskandVolatileareas

5.

Architecture

The architecture provides the top level design view of a system and provides a basis for more detailed design
work Provide or reference a detailed description and diagrams of the architecture..

5.1

Overview

This section provides a high level overview of the structural and functional decomposition of the system.
Focus on how and why the system was decomposed in a particular way rather than on details of the
particular components. Include information on the major responsibilities and roles the system (or portions)
must play.

5.2

Subsystem, Component, or Module 1 N

You only need to provide this level of detail for elements which are custom for this design. Do not go into
gory detail. Goal is to get 80% of the elements figured out ahead of time.
Describe an element (subsystem, component, module, etc.) from architecture in further detail. When
appropriate, include information on how the element is further broken down and the interactions and
relationships between these subcomponents.

5.3

Strategy 1N

Describe the strategy used or decision made. Include information on the alternatives considered and the
reasons for their rejection.

6.

UML diagrams

Describe all your UML diagrams in this section and explain the noun phrase analysis here.

7.

Cost Estimation

Do the cost estimation for your project, dont just give some random numbers, go through the cost estimation
theory in Pressman and than do it..

8.

AppendixA:Glossary

<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project in each SRS.>

AppendixB:References