TREKKER

A project report submitted in partial fulfillment of the Academic

requirements
for the award of the Degree of

BACHELOR OF ENGINEERING
in
INFORMATION TECHNOLOGY

By

G.A.SHRADDHA SHARANYA 2451-15-737-085

MAHVEEN MOHSIN 2451-15-737-086

V.LAHARI 2451-15-737=088
Under the guidance of
Mr. D.MUNINDER
Associate Professor, Dept. of I.T
MVSR Engineering College
Nadergul, Hyderabad.

DEPARTMENT OF INFORMATION TECHNOLOGY

MVSR ENGINEERING COLLEGE
(Affiliated to Osmania University, Hyderabad. Recognized by AICTE)
Nadergul, Saroornagar Mandal, Hyderabad-501510
2018-2019
 TREKKER
A project report submitted in partial fulfillment of the Academic
requirements
for the award of the Degree of

BACHELOR OF ENGINEERING
IN
INFORMATION TECHNOLOGY

By

G.A.SHRADDHA SHARANYA 2451-15-737-085

MAHVEEN MOHSIN 2451-15-737-086

V.LAHARI 2451-15-737-088
Under the guidance of
Mr. D.MUNINDER
Assistant Professor, Dept. of I.T
MVSR Engineering College
Nadergul, Hyderabad.

DEPARTMENT OF INFORMATION TECHNOLOGY

MVSR ENGINEERING COLLEGE
(Affiliated to Osmania University, Hyderabad. Recognized by AICTE)
Nadergul, Saroornagar Mandal, Hyderabad-501510
2018-2019
 CERTIFICATE

This is to certify that the project entitled, “TREKKER” is being submitted by

G.A.SHRADDHA SHARANYA , MAHVEEN MOHSIN and V.LAHARI in partial
fulfillment of the academic requirements for the award of the degree of Bachelor of
Engineering in Information Technology to the Osmania University, is a record of bona
fide work carried out by him under my guidance and supervision. The results obtained in
the project have not been submitted to any other industry or institute for the award of any
degree.

Internal Guide Head of the Department

 ACKNOWLEDGEMENT

We with extreme jubilance and deepest gratitude, would like to thank

D.MUNINDER , Assistant Professor, Department of Information Technology, MVSR
Engineering College, for his constant encouragement and facilities provided to us to
complete our project in time.

With immense pleasure, we record our deep sense of gratitude to our beloved Head
of the department Dr. Ch. Samson, Department of Information Technology, MVSR
Engineering College, for permitting us to carry out this project.

We are sincerely thankful to Dr. G.Kanaka Durga, Principal, M V S R Engineering

College for his inspiration, continuous support and facilities provided us to do this
project.

We would like to extend our gratitude to Mr. V. Ashwini Kumar, Associate

Professor, Department of Information Technology, M V S R Engineering College, for his
valuable suggestions and timely help during the course of the project.

We express, from the bottom of my heart, my deepest gratitude to my parents and

family for the support, dedication, comprehension and love.

Finally, we express our heartfelt thanks to each and every one who directly and
indirectly helped us in successful completion of this project work.

G.A SHRADDHA SHARANYA (2451-15-737-085)

MAHVEEN MOHSIN (2451-15-737-086)

V.LAHARI (2451-15-737-088)
 Abstract

Bus tracking is an application that tracks a bus and gathers the distance to each station
along its route. Tracking System with an installed Android App on any SMART phone to
enable the Administrator/User to track the vehicle's location. There are two applications
one for server and the other for the client. Buses driver carry Android Mobiles to track
their positions. By this positions to server are periodically updated. Client application
displays map showing the position of bus. It shows where buses are on a map and provide
users the updated information at different time interval. The server will monitor location
and will store its data in the database. It is a real-time system as this method
automatically sends the information on the GPS system to a central computer or
system/SMART phone. Since this is an android application we use Cloud server database
for the backend. The users can get flexibility of planning travel using the app, to decide
on which bus to take or when to catch the bus. The waiting time of the user can be
reduced. Simple mode of communication is the key feature of the Bus Tracking system.
This application can be easily extended for central tracking system to keep track of all the
public vehicles. The different queries and efficient route management can be easily done
through central server system.
 CONTENTS

1. Introduction

1.1. Introduction To Project 1

1.2. Overview Of The Project 1
1.3. Purpose Of The Project 2
1.4. Scope Of The Project 2

2. System Analysis

2.1. Introduction 3
2.2. Analysis Model 3
2.3. Existing System 5
2.4. PROPOSED SYSTEM 5
2.5. Hardware & Software Requirements 5
2.6. Design And Implementation Constraints 6

3. Literature Survey

3.1. Introduction To Java 7

3.2. Java Development Environment 9
3.3. Android 10

3.3.1 Creating an Android Project 13

3.3.2 Running the Application 14
3.3.3 Creating an avd 15

3.3.4 Running your application 15

3.3.5 Creating a run configuration 16

3.4 Android Designing 17

4. System design

4.1. Introduction 34
4.2. Software design 35
 4.3. Input/output designs 35
4.3.1 Input Design 35
4.3.2 Output Design 35

4.4. Workflow 36

4.5. UML Concepts 37

4.5.1 Things in the UML 37

4.5.2 Relationships in the UML 39

4.5.3 Diagrams 40

4.6. UML diagrams 50

5. System description

5.1 Study of the System 56

5.2 Module Description 57

6 System testing
6.1. Introduction 58

6.2. Strategic approach of software testing 59

 6.3. Software testing 59
6.4. Testing phases 60
6.5. Testing activities 60
6.6. Unit testing 60

6.6.1. Equivalence testing 61

6.6.2. Boundary testing 61

6.6.3. Path testing 62

6.6.4 State based testing 62

6.6.5 Integration testing 62

6.7. Test case design 63

6.7.1 White-box testing 63
6.7.2 Black-box testing 63
6.7.3 Project specific test cases 63

6.8. Test Approach 65

6.8.1 Bottom up Approach 65

6.8.2 Top down Approach 65

6.9 Project Testing 65

7 Conclusion 66

8 Future scope 67

9 References 68
 Chapter 1

Introduction
 1.Introduction

The safety of private and public vehicles is a major concern nowadays so having GPS
vehicle tracking system ensures their safety while travelling. Vehicle tracking systems
are commonly used by fleet operators for fleet management functions such as routing,
dispatch, on-board information and security. Other applications include monitoring
driving behavior, such as an employer of an employee, or a parent with a teen driver.

1.1 Introduction To The Project:

Vehicle tracking system were first implemented for the shipping industry because
people wanted to know where each vehicle was at any given time. These days, however,
with technology growing at a fast pace, automated vehicle tracking system is being used
in variety of ways to track and display vehicle locations in a variety of ways to track
and display vehicle locations in real time. The paper proposes a vehicle tracking system
using GPS/GSM/GPRS technology and Smartphone application to provide better
service and cost effective solution for users.

1.2 Overview Of The Project:

Android is a software stack for mobile devices that includes an operating system,
middleware and key applications. The Android SDK provides the tools and APIs
necessary to begin developing applications on the Android platform using the Java
programming language. The Android SDK includes a comprehensive set of
development tools. Requirements include Java Development Kit, the officially
supported integrated development environment is Eclipse (3.2 or later) using the
Android Development Tools Plug in, though developers may use any text editor to edit
Java and XML files then use command line tools to create, build and debug Android
applications. This application has two form one for driver and user. Driver is the person
who drives the vehicle .user is the person who needs to know the status of the vehicle.
Vehicle tracking systems are commonly used by fleet operators for fleet management
functions such as routing, dispatch, on-board information and security.

1
1.3 Purpose Of The Project :

Android platform Android requires an open source development which is probably the
most feasible and a present user friendly approach. This application also deals with
Location Based Services, which are used to track the current location of the bus as well
as give an estimate remaining time for the tracked bus to reach its destination using the
client –server technology. It also display the required maps with the help of GPS.

1.4 Scope Of The Project:

The proposed system provides the user to find exact location of the bus from where they
are. The bus routes are displayed in the user interface so the users can select the bus
route which they want to travel. The position of the bus is displayed in the Google map.
The distance between the bus and the user is also displayed so this application helps the
students/staffs to be aware of where the bus is exactly. Depending on the information
like distance and position displayed in the Google map the user can plan and start
accordingly.

2
 Chapter 2

System Analysis
 2.System Analysis

System analysis is an explicit formal inquiry carried out to help someone. Identify a
better course of action and make a better decision than he might otherwise have made.
The characteristic attributes of a problem situation where systems analysis is called
upon are complexity of the issue and uncertainty of the outcome of any course of action
that might reasonably be taken.

2.1. Introduction:
After analyzing the requirements of the task to be performed, the next step is to analyze
the problem and understand its context. The first activity in the phase is studying the
existing system and other is to understand the requirements and domain of the new
system. Both the activities are equally important, but the first activity serves as a basis
of giving the functional specifications and then successful design of the proposed
system. Understanding the requirements of a new system is more difficult and requires
creative thinking and understanding of existing running system is also difficult,
improper understanding of present system can lead diversion from solution.

2.2. Analysis Model:

The model that is basically being followed is the SPIRAL MODEL, which states that
the phases are organized in a linear order. First of all the feasibility study is done. Once
that part is over the requirement analysis and project planning begins. If system exists
one and modification and addition of new module is needed, analysis of present system
can be used as basic model.

The design starts after the requirement analysis is complete and the coding begins after
the design is complete. Once the programming is completed, the testing is done. In this
model the sequence of activities performed in a software development project are: -

 Requirement Analysis
 Project Planning
 System design
 Detail design
 Coding
3
  Unit testing
 System integration & testing

Here the linear ordering of these activities is critical. End of the phase and the output of
one phase is the input of other phase. The output of each phase is to be consistent with
the overall requirement of the system. SPIRAL MODEL was defined by Barry Boehm
in his 1988 article, “A spiral Model of Software Development and Enhancement. This
model was not the first model to discuss iterative development, but it was the first
model to explain why the iteration models.

As originally envisioned, the iterations were typically 6 months to 2 years long. Each
phase starts with a design goal and ends with a client reviewing the progress thus far.
Analysis and engineering efforts are applied at each phase of the project, with an eye
toward the end goal of the project.

The following diagram shows how a spiral model acts like:

Fig 2.2: Spiral Model

4
2.3 Existing System:
The existing system has some of the drawbacks like the exact position of the vehicle
cannot be retrieved.

 This application mainly used only by owners and administrator.

 The bus location cannot be retrieved from anywhere.

 The movement of the bus is also not visible in the Google map

2.4 Proposed System:

The proposed system provides the user to find exact location of the bus from where they
are. The bus routes are displayed in the user interface so the users can select the bus
route which they want to travel. The position of the bus is displayed in the Google map.
The distance between the bus and the user is also displayed so this application helps the
students/staffs to be aware of where the bus is exactly. Depending on the information
like distance and position displayed in the Google map the user can plan and start
accordingly. The proposed system provides following advantages:

1. It provides exact position in Google map.

2. The details of the bus can be seen by everyone at anytime and anywhere.

3. This also enhances security because the movement of the bus is always available.

2.5 Hardware & Software Specifications:

The hardware and software specifications are as follows

Hardware Requirements:

 Operating System : Pentium based systems with a minimum of p4

 RAM : 1GB (minimum)

 Hard Disk : 40GB or above

5
Software Requirements

IDE: Eclipse

OS: Windows XP and above

SDK: Android 2.2 and above

For the base SDK package, at least 600MB of disk space is needed.

For each platform downloaded into the SDK, an additional 100MB is needed

2.6 Design and Implementation Constraints:

All modules are coded thoroughly based on requirements from software organization.
The software is designed in such a way that the user can easily interact with the screen.
Software is designed in such a way that it can be extended to the real time business.

6
 Chapter 3
Literature Survey
 3.Literature Survey
Literature survey helps to provide solutions with an easy way. And it also provides
some knowledge regarding the technology

3.1 Introduction to Java:

Initially the language was called as “oak” but it was renamed as “java” in 1995.The
primary motivation of this language was the need for a platform-independent (i.e.
architecture neutral) language. Java is a programmer’s language. Java is cohesive and
consistent.

Finally Java is to Internet Programming where c was to System Programming.

Importance of Java to the Internet:

Java has had a profound effect on the Internet. This is because; java expands the
Universe of objects that can move about freely in Cyberspace. In a network, two
categories of objects are transmitted between the server and the personal computer.
They are passive information and Dynamic active programs in the areas of Security and
probability. But Java addresses these concerns and by doing so, has opened the door to
an exciting new form of program called the Applet.

Java Architecture:

Java architecture provides a portable, robust, high performing environment for

development. Java provides portability by compiling the byte codes for the Java Virtual
Machine, which is then interpreted on each platform by the run-time environment. Java
is a dynamic system, able to load code when needed from a machine in the same room
or across the planet

Compilation of code:

When you compile the code, the Java compiler creates machine code (called byte code)
for a hypothetical machine called Java Virtual Machine (JVM). The JVM is supposed to
execute the byte code. The code is written and compiled for one machine and
interpreted on all machines .This machine is called Java Virtual Machine.

7
Compiling and interpreting java source code:

Java
Pc Java Byte interpreter
compiler code

Macintosh Java
compiler interpreterm
Platform
Source independ acintosh
code ent
SPARC Java
Compiler interpreter(
SPARC)

FIG 3.1 JAVA ARCHITECTURE

In reality Java interpreter could be an Intel Pentium windows 95 or sun SPARCstation

running Solaris or Apple Macintosh running system and all could receive code from any
computer through internet and run the Applets.

Java is a powerful but lean object-oriented programming language. It has generated a

lot of excitement because it makes it possible to program for Internet by creating
Applets. Programs that can be embedded in web page. The context of an applet can be
an animation with sound, an interactive game or a ticker tape. With constantly updated
stock prices. Applets can be just little decorations to liven up web page, or they can be
serious applications like Word processor or Spreadsheet.

But Java is more than a programming language for writing Applets. It is being used
more and more for writing standalone applications as well Java is simple, elegant, and
powerful and easy-to-use.

Java is actually a platform consisting of 3 components:

Java Programming Language.

Java Library of Classes and Interfaces.

Java Virtual Machine

8
Features of Java:

Java is portable

One of the biggest advantages Java offers is that it is portable. An application written in
Java will run on all the major platforms. Any computer with a Java-based browser can
run the applications or Applets written in the Java-Programming-Language. A
programmer no longer has to write one program to run on a Macintosh, another
program to run on a Windows-machine still another to run on a UNIX-machine and so
on. In other words, with Java developers write their programs only once.

The Virtual Machine is what gives Java is cross platform capabilities. Rather being
compiled into machine language, which is different for each OS’s and computer
architecture, Java code is compiled into Byte codes. With other languages, the program
code is compiled into a language that the computer can understand.

Java is object-oriented

The Java programming language is OBJECT-ORIENTED, which makes program

design focus on what you are dealing with, rather than on how you are going to do
something. This makes it more useful for programming in sophisticated projects,
because one can break the things into understandable components. A big benefit is that
these components can then be reused.

The class paradigm allows one to encapsulate data so that specific data values are those
using the data cannot see the function implementation. Encapsulation makes it possible
to make the changes in code without breaking other programs that use that code.

If for example, the implementation of a function is changed, the change is invisible to

any programmer who invokes that function, and does not affect his/her program, except
hopefully to improve it.

3.2 Java Development Environment

To code, edit, debug and test the java programs, one needs to have a java development
environment. At the minimum this will consists of a java compiler interpreter and applet
viewer where applets can be tested. Sun’s java development kit

9
(JDK) latest version is 2.2 can be freely downloaded from the Internet. Java compiler is
available on DOS, Win95, WIN’NT, Solaris and MAC etc.

Data flow diagram is a graphical tool used to describe analyze the movement of data
through a system manual or automated including the processes, stores of data, and
delays in the system.

3.3 Android
Android is a software stack for mobile devices that includes an operating system,
middleware and key applications. The android SDK provides the tools and APIs
necessary to begin developing applications on the Android platform using the Java
programming language.

Features

Application framework enabling reuse and replacement of components.

Dalvik virtual machine optimized for mobile devices.

Integrated browser based on the open source Web Kit engine.

Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the

OpenGL ES 1.0 specification (hardware acceleration optional).

SQLite for structured data storage.

Media support for common audio, video, and still image formats (MPEG4, H.264, MP3,
AAC, AMR, JPG, PNG, GIF)

GSM Telephony (hardware dependent).

Bluetooth, EDGE, 3G, and Wi-Fi (hardware dependent).

Camera, GPS, compass, and accelerometer (hardware dependent).

Rich development environment including a device emulator, tools for debugging,

memory and performance profiling, and a plug-in for the Eclipse IDE.

Android application Developers have full access to the same framework APIs used by
the core applications. The application architecture is designed to simplify the reuse of

10
components; any application can publish its capabilities and any other application may
then make use of those capabilities (subject to security constraints enforced by the
framework). This same mechanism allows components to be replaced by the user.

Libraries
Android includes a set of C/C++ libraries used by various components of the Android
system. These capabilities are exposed to developers through the Android application
framework. Some of the core libraries are listed below:

System C library - a BSD-derived implementation of the standard C system library (lib

c), tuned for embedded Linux-based devices

Media Libraries - based on Packet Video’s Open CORE; the libraries support playback
and recording of many popular audio and video formats, as well as static image files,
including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG

Surface Manager - manages access to the display subsystem and seamlessly

composites 2D and 3D graphic layers from multiple applications

Lib Web Core - a modern web browser engine which powers both the Android browser
and an embeddable web view

SGL - the underlying 2D graphics engine

3D libraries - an implementation based on OpenGL ES 1.0 APIs; the libraries use

either hardware 3D acceleration (where available) or the included, highly optimized 3D
software rasterizer

Free Type - bitmap and vector font rendering

SQLite - a powerful and lightweight relational database engine available to all

applications.

11
Android Runtime
Android includes a set of core libraries that provides most of the functionality available
in the core libraries of the Java programming language.

Every Android application runs in its own process, with its own instance of the Dalvik
virtual machine. Dalvik has been written so that a device can run multiple VMs
efficiently. The Dalvik VM executes files in the Dalvik Executable format which is
optimized for minimal memory footprint. The VM is register-based, and runs classes
compiled by a Java language compiler that have been transformed into the. .Dex format
by the included "dx" tool.

The Dalvik VM relies on the Linux kernel for underlying functionality such as
threading and low-level memory management.

An Android code editor that helps you write valid XML for your Android manifest and
resource files. It will even export your project into a signed APK, which can be
distributed to users.

To begin developing Android applications in the Eclipse IDE with ADT, you first need
to download the Eclipse IDE and then download and install the ADT plugin.

Developing in eclipse with ADT:

The Android Development Tools (ADT) plug-in for Eclipse adds powerful extensions
to the Eclipse integrated development environment. It allows you to create and debug
Android applications easier and faster. If you use Eclipse, the ADT plug-in gives you an
incredible boost in developing Android applications:

It gives you access to other Android development tools from inside the Eclipse IDE. For
example, ADT lets you access the many capabilities of the DDMS tool: take
screenshots, manage port-forwarding, set breakpoints, and view thread and process
information directly from Eclipse.

12
It provides a New Project Wizard, which helps you quickly create and set up all of the
basic file needed for a new Android application. It automates and simplifies the process
of building your Android application.

3.3.1 CREATING AN ANDROID PROJECT:

The ADT plugin provides a New Project Wizard that you can use to quickly
create a new Android project (or a project from existing code). To create a new project:

Select File > New > Project.

Select Android > Android Project, and click Next.

Select the contents for the project:

Enter a Project Name. This will be the name of the folder where your project is created.

Under Contents, select Create new project in workspace. Select your project
workspace location.

Under Target, select an Android target to be used as the project's Build Target. The
Build Target specifies which Android platform you'd like your application built against.

Unless you know that you'll be using new APIs introduced in the latest SDK, you
should select a target with the lowest platform version possible, such as Android 1.1.

Under Properties, fill in all necessary fields.

Enter an Application name. This is the human-readable title for your application — the
name that will appear on the Android device.

Enter a Package name. This is the package namespace (following the same rules as for
packages in the Java programming language) where all your source code will reside.

Select Create Activity (optional, of course, but common) and enter a name for your
main Activity class.

Enter a Min SDK Version. This is an integer that indicates the minimum API Level
required to properly run your application. Entering this here automatically sets the min
Sdk Version attribute in the <uses-sdk> of your Android Manifest file. If you're unsure

13
of the appropriate API Level to use, copy the API Level listed for the Build Target
you selected in the Target tab.

4. Click Finish.

Once you complete the New Project Wizard, ADT creates the following
folders and files in your new project:

src/ Includes your stub Activity Java file. All other Java files for your application go
here.

<Android Version>/ (e.g., Android 1.1/)

Includes the android.jar file that your application will build against. This is determined
by the build target that you have chosen in the New Project Wizard.

gen/ This contains the Java files generated by ADT, such as your R.java file and
interfaces created from AIDL files.

assets/ This is empty. You can use it to store raw asset files.

res/ A folder for your application resources, such as drawable files, layout files,
string values.

AndroidManifest.xml It is the file from which execution of project starts.

Default Properties

This file contains project settings, such as the build target. This files is integral
to the project, as such, it should be maintained in a Source Revision Control system. It
should never be edited manually — to edit project properties, right-click the project
folder and select "Properties".

3.3.2 Running the Application:

Before you can run your application on the Android Emulator, you must create an
Android Virtual Device (AVD). An AVD is a configuration that specifies the Android
platform to be used on the emulator. You can read more in the Android Virtual Devices
document, but if you just want to get started, follow the simple guide below to create an
AVD.

If you will be running your applications only on actual device hardware, you do not
need an AVD — see Developing on a Device for information on running your
application.

14
3.3.3 Creating an AVD:
With ADT 0.9.3 and above, the Android SDK and AVD Manager provides a simple
graphical interface for creating and managing AVDs. (If you're using ADT version
0.9.1 or older, you must use the android tool to create your AVDs

To create an AVD with the AVD Manager:

Select Window > Android SDK and AVD Manager, or click the Android
SDK and AVD Manager icon (a black device) in the Eclipse toolbar.

In the Virtual Devices panel, you'll see a list of existing AVDs. Click New to
create a new AVD.

Fill in the details for the AVD.

Give it a name, a platform target, an SD card image (optional), and a skin

(HVGA is default).

Click Create AVD.

Your AVD is now ready and you can close the AVD Manager. In the next section,
you'll see how the AVD is used when launching your application on an emulator.

For more information about AVDs, read the Android Virtual Devices documentation.

3.3.4 Running Your Application:

To run (or debug) your application, select Run > Run (or Run > Debug) from the
Eclipse main menu. The ADT plugin will automatically create a default launch
configuration for the project.

When you choose to run or debug your application, Eclipse will perform the following:

Compile the project (if there have been changes since the last build).

Create a default launch configuration (if one does not already exist for the project).

15
Install and start the application on an emulator or device (based on the Deployment Target
defined by the run configuration).

By default, Android application run configurations use an "automatic target" mode for selecting
a device target.

3.3.5 Creating A Run Configuration:

The run configuration specifies the project to run, the Activity to start, the emulator
options to use, and so on. When you first run a project as an Android Application, ADT
will automatically create a run configuration. The default run configuration will launch
the default project Activity and use automatic target mode for device selection (with no
preferred AVD). If the default settings don't suit your project, you can customize the
launch configuration or even create a new.

To create or modify a launch configuration, follow these steps as appropriate for your
Eclipse version:

Open the run configuration manager.

In Eclipse 3.3 (Europa), select Run > Open Run Dialog (or Open Debug
Dialog). In Eclipse 3.4 (Ganymede), select Run > Run Configurations (or Debug
Configurations)

Expand the Android Application item and create a new configuration or open an
existing one.

To create a new configuration:

Select Android Application and click the New launch configuration icon above the list
(or, right-click Android Application and click New).

Enter a Name for your configuration.

In the Android tab, browse and select the project you'd like to run with the
configuration.

To open an existing configuration, select the configuration name from the list nested
below Android Application.

16
3.4 Android Designing:
Designing for performance:
An Android application should be fast. Well, it's probably more accurate to say that it
should be efficient. That is, it should execute as efficiently as possible in the mobile
device environment, with its limited computing power and data storage, smaller screen,
and constrained battery life.

As you develop your application, keep in mind that, while the application may perform
well enough in your emulator, running on your dual-core development computer, it will
not perform that well when run a mobile device — even the most powerful mobile
device can't match the capabilities of a typical desktop system. For that reason, you
should strive to write efficient code, to ensure the best possible performance on a
variety of mobile devices.

Generally speaking, writing fast or efficient code means keeping memory allocations to
a minimum, writing tight code, and avoiding certain language and programming idioms
that can subtly cripple performance. In object-oriented terms, most of this work takes
place at the method level, on the order of actual lines of code, loops, and so on.

Introduction:

There are two basic rules for resource-constrained systems:

Don't do work that you don't need to do.

Don't allocate memory if you can avoid it.

All the tips below follow from these two basic tenets.

Some would argue that much of the advice on this page amounts to "premature
optimization." While it's true that micro-optimizations sometimes make it harder to
develop efficient data structures and algorithms, on embedded devices like handsets you
often simply have no choice. For instance, if you bring your assumptions about VM
performance on desktop machines to Android, you're quite likely to write code that

17
exhausts system memory. This will bring your application to a crawl — let alone what it
will do to other programs running on the system!

That's why these guidelines are important. Android's success depends on the user
experience that your applications provide, and that user experience depends in part on
whether your code is responsive and snappy, or slow and aggravating. Since all our
applications will run on the same devices, we're all in this together, in a way. Think of
this document as like the rules of the road you had to learn when you got your driver's
license: things run smoothly when everybody follows them, but when you don't, you get
your car smashed up.

Before we get down to brass tacks, a brief observation: nearly all issues described
below are valid whether or not the VM features a JIT compiler. If I have two methods
that accomplish the same thing, and the interpreted execution of foo () is faster than bar
(), then the compiled version of foo() will probably be as fast or faster than compiled
bar(). It is unwise to rely on a compiler to "save" you and make your code fast enough.

Avoid creating objects:

Object creation is never free. A generational GC with per-thread allocation pools for
temporary objects can make allocation cheaper, but allocating memory is always more
expensive than not allocating memory.

If you allocate objects in a user interface loop, you will force a periodic garbage
collection, creating little "hiccups" in the user experience.

Thus, you should avoid creating object instances you don't need to. Some examples of
things that can help:

When extracting strings from a set of input data, try to return a substring of the original
data, instead of creating a copy. You will create a new String object, but it will share the
char[] with the data.

If you have a method returning a string, and you know that its result will always be
appended to a String Buffer anyway, change your signature and implementation so

18
that the function does the append directly, instead of creating a short-lived temporary
object.

A somewhat more radical idea is to slice up multidimensional arrays into parallel single
one-dimension arrays: An array of ints is a much better than an array of Integers, but
this also generalizes to the fact that two parallel arrays of ints are also a lot more
efficient than an array of (int, int) objects. The same goes for any combination of
primitive types.

If you need to implement a container that stores tuples of (Foo, Bar) objects, try to
remember that two parallel Foo[] and Bar[] arrays are generally much better than a
single array of custom (Foo, Bar) objects. (The exception to this, of course, is when
you're designing an API for other code to access; in those cases, it's usually better to
trade correct API design for a small hit in speed. But in your own internal code, you
should try and be as efficient as possible.)

Generally speaking, avoid creating short-term temporary objects if you can. Fewer
objects created mean less-frequent garbage collection, which has a direct impact on user
experience.

Use native methods:

When processing strings, don't hesitate to use specialty methods like String index Of (),
String last Index Of (), and their cousins. These are typically implemented in C/C++
code that easily runs 10-100x faster than doing the same thing in a Java loop.

The flip side of that advice is that punching through to a native method is more
expensive than calling an interpreted method. Don't use native methods for trivial
computation, if you can avoid it.

19
Prefer Virtual Over Interface:

Suppose you have a HashMap object. You can declare it as a HashMap or as a

generic Map:

Map myMap1 = new HashMap();

HashMap myMap2 = new HashMap();

Which is better?

Conventional wisdom says that you should prefer Map, because it allows you to change
the underlying implementation to anything that implements the Map interface.
Conventional wisdom is correct for conventional programming, but isn't so great for
embedded systems. Calling through an interface reference can take 2x longer than a
virtual method call through a concrete reference.

If you have chosen a HashMap because it fits what you're doing, there is little value in
calling it a Map. Given the availability of IDEs that refractor your code for you, there's
not much value in calling it a Map even if you're not sure where the code is headed.
(Again, though, public APIs are an exception: a good API usually trumps small
performance concerns.)

Prefer static over virtual:

If you don't need to access an object's fields, make your method static. It can be called
faster, because it doesn't require a virtual method table indirection. It's also good
practice, because you can tell from the method signature that calling the method can't
alter the object's state.

Avoid internal getters/setters:

In native languages like C++ it's common practice to use getters (e.g. i = getCount())
instead of accessing the field directly (i = mCount). This is an excellent habit for C++,
because the compiler can usually inline the access, and if you need to restrict or debug
field access you can add the code at any time.

20
On Android, this is a bad idea. Virtual method calls are expensive, much more so than
instance field lookups. It's reasonable to follow common object-oriented programming
practices and have getters and setters in the public interface, but within a class you
should always access fields directly.

Cache Field Lookup:

Accessing object fields is much slower than accessing local variables. Instead of
writing:

for (int i = 0; i < this.mCount; i++)

dumpItem(this.mItems[i]);

You should write:

int count = this.mCount;

Item[] items = this.mItems;

for (int i = 0; i < count; i++)

dumpItems(items[i]);

(We're using an explicit "this" to make it clear that these are member variables.)

A similar guideline is never call a method in the second clause of a "for" statement. For
example, the following code will execute the getCount() method once per iteration,
which is a huge waste when you could have simply cached the value as an int:

for (int i = 0; i < this.getCount(); i++)

dumpItems(this.getItem(i));

It's also usually a good idea to create a local variable if you're going to be accessing an
instance field more than once. For example:

21
protected void drawHorizontalScrollBar(Canvas canvas, int width, int height) {

if (isHorizontalScrollBarEnabled()) {

int size = mScrollBar.getSize(false);

if (size <= 0) {

size = mScrollBarSize;

mScrollBar.setBounds(0, height - size, width, height);

mScrollBar.setParams(

computeHorizontalScrollRange(),

computeHorizontalScrollOffset(),

computeHorizontalScrollExtent(), false);

mScrollBar.draw(canvas);

That's four separate lookups of the member field mScrollBar. By caching mScrollBar in
a local stack variable, the four member field lookups become four stack variable
references, which are much more efficient.

Incidentally, method arguments have the same performance characteristics as local

variables.

Declare Constants Final:

Consider the following declaration at the top of a class:

22
static int intVal = 42;

static String strVal = "Hello, world!";

The compiler generates a class initializer method, called <clinit>, that is executed when
the class is first used. The method stores the value 42 into intVal, and extracts a
reference from the classfile string constant table for strVal. When these values are
referenced later on, they are accessed with field lookups.

We can improve matters with the "final" keyword:

static final int intVal = 42;

static final String strVal = "Hello, world!";

The class no longer requires a <clinit> method, because the constants go into classfile
static field initializes, which are handled directly by the VM. Code accessing intVal will
use the integer value 42 directly, and accesses to strVal will use a relatively inexpensive
"string constant" instruction instead of a field lookup.

Declaring a method or class "final" does not confer any immediate performance
benefits, but it does allow certain optimizations. For example, if the compiler knows
that a "getter" method can't be overridden by a sub-class, it can inline the method call.

You can also declare local variables final. However, this has no definitive performance
benefits. For local variables, only use "final" if it makes the code clearer (or you have
to, e.g. for use in an anonymous inner class).

Designing For Responsiveness:

It's possible to write code that wins every performance test in the world, but still sends
users in a fiery rage when they try to use the application. These are the applications that
aren't responsive enough — the ones that feel sluggish, hang or freeze for significant
periods, or take too long to process input.

23
In Android, the system guards against applications that are insufficiently responsive for
a period of time by displaying a dialog to the user, called the Application Not
Responding (ANR) dialog. The user can choose to let the application continue, but the
user won't appreciate having to act on this dialog every time he or she uses your
application. So it's important to design responsiveness into your application, so that the
system never has cause to display an ANR to the user.

Generally, the system displays an ANR if an application cannot respond to user input.
For example, if an application blocks on some I/O operation (frequently a network
access), then the main application thread won't be able to process incoming user input
events. After a time, the system concludes that the application has hung, and displays
the ANR to give the user the option to kill it.

Similarly, if your application spends too much time building an elaborate in-memory
structure, or perhaps computing the next move in a game, the system will conclude that
your application has hung. It's always important to make sure these computations are
efficient using the techniques above, but even the most efficient code still takes time to
run.

In both of these cases, the fix is usually to create a child thread, and do most of your
work there. This keeps the main thread (which drives the user interface event loop)
running, and prevents the system from concluding your code has frozen. Since such
threading usually is accomplished at the class level, you can think of responsiveness as
a class problem. (Compare this with basic performance, which was described above as a
method-level concern.)This document discusses how the Android system determines
whether an application is not responding and provides guidelines for ensuring that your
application is responsive.

What Triggers ANR:

In Android, application responsiveness is monitored by the Activity Manager and

Window Manager System services. Android will display the ANR dialog for a
particular application when it detects one of the following conditions:

No response to an input event (e.g. key press, screen touch) within 5 seconds

24
A Broadcast Receiver hasn't finished executing within 10 seconds

How to Avoid ANR:

Android applications normally run entirely on a single (i.e. main) thread. This means
that anything your application is doing in the main thread that takes a long time to
complete can trigger the ANR dialog because your application is not giving itself a
chance to handle the input event or Intent broadcast.

Therefore any method that runs in the main thread should do as little work as possible.
In particular, Activities should do as little as possible to set up in key life-cycle methods
such as on Create () and on Resume (). Potentially long running operations such as
network or database operations, or computationally expensive calculations such as
resizing bitmaps should be done in a child thread (or in the case of databases operations,
via an asynchronous request). However, this does not mean that your main thread
should block while waiting for the child thread to complete — nor should you call
Thread. Wait () or Thread. Sleep ().

Instead of blocking while waiting for a child thread to complete, your main thread
should provide a Handler for child threads to post back to upon completion. Designing
your application in this way will allow your main thread to remain responsive to input
and thus avoid ANR dialogs caused by the 5 second input event timeout. These same
practices should be followed for any other, as it will spawn a new screen that will steal
focus from whatever application the user is currently has running. If your application
has something to show the user in response to an Intent broadcast, it should do so using
the Notification Manager. threads that display UI, as they are also subject to the same
timeouts.

The specific constraint on Intent Receiver execution time emphasizes what they were
meant to do: small, discrete amounts of work in the background such as saving a setting
or registering a Notification. So as with other methods called in the main thread,
applications should avoid potentially long-running operations or calculations in
Broadcast Receivers. But instead of doing intensive tasks via child threads (as the life of
a Broadcast Receiver is short), your application should start a Service if a potentially

25
long running action needs to be taken in response to an Intent broadcast. As a side note,
you should also avoid starting an Activity from an Intent Receive.

Reinforcing Responsiveness:

Generally, 100 to 200ms is the threshold beyond which users will perceive lag (or lack
of "snappiness," if you will) in an application. As such, here are some additional tips
beyond what you should do to avoid ANR that will help make your application seem
responsive to users.

If your application is doing work in the background in response to user input, show that
progress is being made (Progress Bar and Progress Dialog are useful for this). For
games specifically, do calculations for moves in a child thread.

If your application has a time-consuming initial setup phase, consider showing a splash
screen or rendering the main view as quickly as possible and filling in the information
asynchronously. In either case, you should indicate somehow that progress is being
made, lest the user perceive that the application is frozen.

Designing for Seamlessness:

Even if your application is fast and responsive, certain design decisions can still cause
problems for users — because of unplanned interactions with other applications or
dialogs, inadvertent loss of data, unintended blocking, and so on. To avoid these
problems, it helps to understand the context in which your applications run and the
system interactions that can affect your application. In short, you should strive to
develop an application that interacts seamlessly with the system and with other
applications.

A common seamlessness problem is when an application's background process — for

example, a service or broadcast receiver — pops up a dialog in response to some event.
This may seem like harmless behavior, especially when you are building and testing
your application in isolation, on the emulator. However, when your application is run on
an actual device, your application may not have user focus at the time your background
process displays the dialog. So it could end up that your application would

26
display it's dialog behind the active application, or it could take focus from the current
application and display the dialog in front of whatever the user was doing (such as
dialing a phone call, for example). That behavior would not work for your application
or for the user.

To avoid these problems, your application should use the proper system facility for
notifying the user — the Notification classes. Using notifications, your application can
signal the user that an event has taken place, by displaying an icon in the status bar
rather than taking focus and interrupting the user.

Another example of a seamlessness problem is when an activity inadvertently loses

state or user data because it doesn't correctly implement the on Pause () and other
lifecycle methods. Or, if your application exposes data intended to be used by other
applications, you should expose it via a Content Provider, rather than (for example)
doing so through a world-readable raw file or database.

What those examples have in common is that they involve cooperating nicely with the
system and other applications. The Android system is designed to treat applications as a
sort of federation of loosely-coupled components, rather than chunks of black-box code.
This allows you as the developer to view the entire system as just an even-larger
federation of these components. This benefits you by allowing you to integrate cleanly
and seamlessly with other applications, and so you should design your own code to
return the favor.

This document discusses common seamlessness problems and how to avoid them. It
covers these topics:

Don’t Drop Data:

Always keep in mind that Android is a mobile platform. It may seem obvious to say it,
but it's important to remember that another Activity (such as the "Incoming Phone Call"
app) can pop up over your own Activity at any moment. This will fire the
onSaveInstanceState () and on Pause() methods application being killed.

27
If the user was editing data in your application when the other Activity appeared, your
application will likely lose that data when your application is killed. Unless, of course,
you save the work in progress first. The "Android Way" is to do just that: Android
applications that accept or edit input should override the onSaveInstanceState () method
and save their state in some appropriate fashion. When the user revisits the application,
she should be able to retrieve her data.

A classic example of a good use of this behaviour is a mail application. If the user was
composing an email when another Activity started up, the application should save the
in-process email as a draft.

Don’t Expose Raw Data:

If you wouldn't walk down the street in your underwear, neither should your data.
While it's possible to expose certain kinds of application to the world to read, this is
usually not the best idea. Exposing raw data requires other applications to understand
your data format; if you change that format, you'll break any other applications that
aren't similarly updated.

The "Android Way" is to create a Content Provider to expose your data to other
applications via a clean, well-thought-out, and maintainable API. Using a Content
Provider is much like inserting a Java language interface to split up and componentized
two tightly-coupled pieces of code. This means you'll be able to modify the internal
format of your data without changing the interface exposed by the Content Provider,
and this without affecting other applications.

Don’t Interrupt The User:

If the user is running an application (such as the Phone application during a call) it's a
pretty safe bet he did it on purpose. That's why you should avoid spawning activities
except in direct response to user input from the current Activity.

That is, don't call start Activity () from Broadcast Receivers or Services running in the
background. Doing so will interrupt whatever application is currently running, and
result in an annoyed user. Perhaps even worse, your Activity may become a "keystroke
bandit" and receive some of the input the user was in the middle of

28
providing to the previous Activity. Depending on what your application does, this could
be bad news.

Instead of spawning Activity UIs directly from the background, you should instead use
the Notification Manager to set Notifications. These will appear in the status bar, and
the user can then click on them at his leisure, to see what your application has to show
him.

(Note that all this doesn't apply to cases where your own Activity is already in
the foreground: in that case, the user expects to see your next Activity in response to
input.)

Go a Lot to Do? Do it in a Thread:

If your application needs to perform some expensive or long-running computation, you

should probably move it to a thread. This will prevent the dreaded "Application Not
Responding" dialog from being displayed to the user, with the ultimate result being the
fiery demise of your application.

By default, all code in an Activity as well as all its Views run in the same thread. This is
the same thread that also handles UI events. For example, when the user presses a key, a
key-down event is added to the Activity's main thread's queue. The event handler
system needs to dequeue and handle that event quickly; if it doesn't, the system
concludes after a few seconds that the application is hung and offers to kill it for the
user.

If you have long-running code, running it inline in your Activity will run it on the event
handler thread, effectively blocking the event handler. This will delay input processing,
and result in the ANR dialogs. To avoid this, move your computations to a thread.

Don’t over load a single activity screen:

Any application worth using will probably have several different screens. When
designing the screens of your UI, be sure to make use of multiple Activity object
instances.

29
Depending on your development background, you may interpret an Activity as similar
to something like a Java Applet, in that it is the entry point for your application.
However, that's not quite accurate: where an Applet subclass is the single entry point for
a Java Applet, an Activity should be thought of as one of potentially several entry points
to your application. The only difference between your "main" Activity and any others
you might have is that the "main" one just happens to be the only one that expressed an
interest in the "android.intent.action.MAIN" action in your Android Manifest..xml file.

So, when designing your application, think of your application as a federation of

Activity objects. This will make your code a lot more maintainable in the long run, and
as a nice side effect also plays nicely with Android's application history and "back
stack" model.

Extended system themes:

When it comes to the look-and-feel of the user interface, it's important to blend in
nicely. Users are jarred by applications which contrast with the user interface they've
come to expect. When designing your UIs, you should try and avoid rolling your own as
much as possible. Instead, use a Theme. You can override or extend those parts of the
theme that you need to, but at least you're starting from the same UI base as all the other
applications.

Design your UI to work with multiple screen resolutions:

Different Android-powered devices will support different screen resolutions. Some will
even be able to change resolutions on the fly, such as by switching to landscape mode.
It's important to make sure your layouts and drawables are flexible enough to display
properly on a variety of device screens.

Fortunately, this is very easy to do. In brief, what you must do is provide different
versions of your artwork (if you use any) for the key resolutions, and then design your
layout to accommodate various dimensions. (For example, avoid using hard-coded
positions and instead use relative layouts.) If you do that much, the system handles the
rest, and your application looks great on any device.

30
Assume the network is slow:

Android devices will come with a variety of network-connectivity options. All will have
some data-access provision, though some will be faster than others. The lowest common
denominator, however, is GPRS, the non-3G data service for GSM networks. Even 3G-
capable devices will spend lots of time on non-3G networks, so slow networks will
remain a reality for quite a long time to come.

That's why you should always code your applications to minimize network accesses and
bandwidth. You can't assume the network is fast, so you should always plan for it to be
slow. If your users happen to be on faster networks, then that's great — their experience
will only improve. You want to avoid the inverse case though: applications that are
usable some of the time, but frustratingly slow the rest based on where the user is at any
given moment are likely to be unpopular.

One potential gotcha here is that it's very easy to fall into this trap if you're using the
emulator, since the emulator uses your desktop computer's network connection. That's
almost guaranteed to be much faster than a cell network, so you'll want to change the
settings on the emulator that simulate slower network speeds. You can do this in
Eclipse, in the "Emulator Settings" tab of your launch configuration or via a command-
line option when starting the emulator.

Don’t assume touch screen or key board:

Android will support a variety of handset form-factors. That's a fancy way of saying
that some Android devices will have full "QWERTY" keyboards, while others will have
40-key, 12-key, or even other key configurations. Similarly, some devices will have
touch-screens, but many won't.

When building your applications, keep that in mind. Don't make assumptions about
specific keyboard layouts -- unless, of course, you're really interested in restricting your
application so that it can only be used on those devices.

31
Do converse the device battery:

A mobile device isn't very mobile if it's constantly plugged into the wall. Mobile
devices are battery-powered, and the longer we can make that battery last on a charge,
the happier everyone is — especially the user. Two of the biggest consumers of battery
power are the processor, and the radio; that's why it's important to write your
applications to do as little work as possible, and use the network as infrequently as
possible.

Minimizing the amount of processor time your application uses really comes down to
writing efficient code. To minimize the power drain from using the radio, be sure to
handle error conditions gracefully, and only fetch what you need. For example, don't
constantly retry a network operation if one failed. If it failed once, it's likely because the
user has no reception, so it's probably going to fail again if you try right away; all you'll
do is waste battery power.

Users are pretty smart: if your program is power-hungry, you can count on them
noticing. The only thing you can be sure of at that point is that your program won't stay
installed very long.

32
 Chapter 4
System Design
 4.System Design
Design involves identification of classes, their relationships as well as their
collaboration. Classes are divided into entity classes, interface classes and control
classes.

4.1. Introduction:
Software design sits at the technical kernel of the software engineering process and is
applied regardless of the development paradigm and area of application. Design is the
first step in the development phase for any engineered product or system. The
designer’s goal is to produce a model or representation of an entity that will later be
built. Beginning, once system requirement have been specified and analyzed, system
design is the first of the three technical activities -design, code and test that is required
to build and verify software.

The importance can be stated with a single word “Quality”. Design is the place where
quality is fostered in software development. Design provides us with representations of
software that can assess for quality. Design is the only way that we can accurately
translate a customer’s view into a finished software product or system. Software design
serves as a foundation for all the software engineering steps that follow. Without a
strong design we risk building an unstable system – one that will be difficult to test, one
whose quality cannot be assessed until the last stage.

During design, progressive refinement of data structure, program structure, and

procedural details are developed reviewed and documented. System design can be
viewed from either technical or project management perspective. From the technical
point of view, design is comprised of four activities – architectural design, data
structure design, interface design and procedural design.

System design is transition from a user oriented document to programmers or data base
personnel. The design is a solution, how to approach to the creation of a new system.
This is composed of several steps. It provides the understanding and procedural details
necessary for implementing the system recommended in the feasibility study. Designing
goes through logical and physical stages of development, logical design

34
reviews the present physical system, prepare input and output specification, details of
implementation plan and prepare a logical design walkthrough.

The database tables are designed by analyzing functions involved in the system and
format of the fields is also designed. The fields in the database tables should define their
role in the system. The unnecessary fields should be avoided because it affects the
storage areas of the system. Then in the input and output screen design, the design
should be made user friendly. The menu should be precise and compact.

4.2 Software Design:

In designing the software following principles are followed:

1. Modularity and partitioning: software is designed such that, each system should
consists of hierarchy of modules and serve to partition into separate function.

2. Coupling: modules should have little dependence on other modules of a system.

3. Cohesion: modules should carry out in a single processing function.

4. Shared use: avoid duplication by allowing a single module is called by other that
need the function it provides

4.3 Input/Output Designs:

4.3.1 Input Design:

Considering the requirements, procedures to collect the necessary input data is most
efficiently designed. The input design has been done keeping in view that, the
interaction of the user with the system being the most effective and simplified way.

Also the measures are taken for the following

Controlling the amount of input

Avoid unauthorized access to the Universal Dossier

Eliminating extra steps

Keeping the process simple

At this stage the input forms and screens are designed.

4.3.2 OUTPUT DESIGN:

All the screens of the system are designed with a view to provide the user with easy
operations in simpler and efficient way, minimum key strokes possible.

35
Instructions and important information is emphasized on the screen. Almost every
screen is provided with no error and important messages and option selection facilitates.
Emphasis is given for speedy processing and speedy transaction between the screens.
Each screen assigned to make it as much user friendly as possible by using interactive
procedures. So to say user can operate the system without much help from the operating
manual.

Fig 4.4 :Workflow

36
4.5 UML Concepts:
The Unified Modelling Language (UML) is a standard language for writing software
blue prints. The UML is a language for

Visualizing

Specifying

Constructing

Documenting the artifacts of a software intensive system.

The UML is a language which provides vocabulary and the rules for combining words
in that vocabulary for the purpose of communication. A modelling language is a
language whose vocabulary and the rules focus on the conceptual and physical
representation of a system. Modelling yields an understanding of a system.

Building Blocks of the UML:

The vocabulary of the UML encompasses three kinds of building blocks:

Things

Relationships

Diagrams

Things are the abstractions that are first-class citizens in a model; relationships tie these
things together; diagrams group interesting collections of things.

4.5.1 THINGS IN THE UML:

There are four kinds of things in the UML:

Structural things

Behavioral things

Grouping things

Annotational things

Structural things are the nouns of UML models. The structural things used in the
project design are:

First, a class is a description of a set of objects that share the same attributes,
operations, relationships and semantics.

37
 Window

origin

size

open()

close()

move()

display()

Fig: Classes

Second, a use case is a description of set of sequence of actions that a system

performs that yields an observable result of value to particular actor.

Fig: Use Cases

Third, a node is a physical element that exists at runtime and represents a

computational resource, generally having at least some memory and often processing
capability.

Fig: Nodes

Behavioural things are the dynamic parts of UML models. The behavioural thing used
is:

Interaction:

An interaction is a behaviour that comprises a set of messages exchanged among

a set of objects within a particular context to accomplish a specific purpose. An

38
interaction involves a number of other elements, including messages, action sequences
(the behaviour invoked by a message, and links (the connection between objects).

Fig: Messages

4.5.2 Relationships In The Uml:

There are four kinds of relationships in the UML:

Dependency

Association

Generalization

Realization

A dependency is a semantic relationship between two things in which a change to one

thing may affect the semantics of the other thing (the dependent thing).

Fig: Dependencies

An association is a structural relationship that describes a set links, a link being a

connection among objects. Aggregation is a special kind of association, representing a
structural relationship between a whole and its parts.

Fig: Association

A generalization is a specialization/ generalization relationship in which objects of the

specialized element (the child) are substitutable for objects of the generalized element
(the parent).

Fig: Generalization

39
A realization is a semantic relationship between classifiers, where in one classifier
specifies a contract that another classifier guarantees to carry out.

Fig: Realization

4.5.3 Diagrams:
Sequence Diagrams:

UML sequence diagrams are used to represent the flow of messages, events and actions
between the objects or components of a system. Time is represented in the vertical
direction showing the sequence of interactions of the header elements, which are
displayed horizontally at the top of the diagram.

Sequence Diagrams are used primarily to design, document and validate the
architecture, interfaces and logic of the system by describing the sequence of actions
that need to be performed to complete a task or scenario. UML sequence diagrams are
useful design tools because they provide a dynamic view of the system behaviour which
can be difficult to extract from static diagrams or specifications.

Actor

Represents an external person or entity that interacts with the system

Object

Represents an object in the system or one of its components

40
Unit

Represents a subsystem, component, unit, or other logical entity in the system (may or
may not be implemented by objects)

Separator

Represents an interface or boundary between subsystems, components or units (e.g., air

interface, Internet, network)

Group

Groups related header elements into subsystems or components

Sequence Diagram Body Elements

Action

Represents an action taken by an actor, object or unit

Asynchronous Message

An asynchronous message between header elements

41
Block

A block representing a loop or conditional for a particular header element

Call Message

A call (procedure) message between header elements

Create Message

A "create" message that creates a header element (represented by lifeline going from
dashed to solid pattern)

Diagram Link

Represents a portion of a diagram being treated as a functional block. Similar to a

procedure or function call that abstracts functionality or details not shown at this level.
Can optionally be linked to another diagram for elaboration.

42
Else Block Represents an "else" block portion of a diagram block

Message

A simple message between header elements

Return Message

A return message between header elements

Use Case Diagram

A use case diagram is a graph of actors set of use cases enclosed by a system boundary,
communication associations between the actors and users and generalization among use
cases. The use case model defines the outside(actors) and inside(use case) of the
system’s behaviour. Use case diagram is quite simple in nature and depicts two types of
elements: one representing the business roles and the other representing the business
processes.

Figure 3.1: an actor in a use case diagram

43
To identify an actor, search in the problem statement for business terms that portray
roles in the system. For example, in the statement "patients visit the doctor in the clinic
for medical tests," "doctor" and "patients" are the business roles and can be easily
identified as actors in the system.

Add Bucket

Add Folder

View & Download

Dat a

Admin

Deactivate
Users

Sent Alert
Message

Fig: Use case

Use case: A use case in a use case diagram is a visual representation of a distinct
business functionality in a system. The key term here is "distinct business
functionality." To choose a business process as a likely candidate for modelling as a use
case, you need to ensure that the business process is discrete in nature.

44
As the first step in identifying use cases, you should list the discrete business functions
in your problem statement. Each of these business functions can be classified as a
potential use case. Remember that identifying use cases is a discovery rather than a
creation. As business functionality becomes clearer, the underlying use cases become
more easily evident. A use case is shown as an ellipse in a use case diagram

Fig: use cases in a use case diagram

Above figure shows two uses cases: "Make appointment" and "Perform medical tests"
in the use case diagram of a clinic system. As another example, consider that a business
process such as "manage patient records" can in turn have sub-processes like "manage
patient's personal information" and "manage patient's medical information."
Discovering such implicit use cases is possible only with a thorough understanding of
all the business processes of the system through discussions with potential users of the
system and relevant domain knowledge.

Activity Diagram

Activity diagrams represent the business and operational workflows of a system. An

Activity diagram is a dynamic diagram that shows the activity and the event that causes
the object to be in the particular state.

So, what is the importance of an Activity diagram, as opposed to a State diagram? A

State diagram shows the different states an object is in during the lifecycle of its
existence in the system, and the transitions in the states of the objects. These transitions
depict the activities causing these transitions, shown by arrows.

An Activity diagram talks more about these transitions and activities causing the
changes in the object states.

Defining an Activity diagram

Let us take a look at the building blocks of an Activity diagram.

45
Elements of an Activity diagram

An Activity diagram consists of the following behavioural elements:

Initial Activity: This shows the starting point or first activity of the flow. Denoted by a
solid circle. This is similar to the notation used for Initial State.

Activity: Represented by a rectangle with rounded (almost oval) edges.

Decisions: Similar to flowcharts, a logic where a decision is to be made is depicted by a

diamond, with the options written on either sides of the arrows emerging from the
diamond, within box brackets.

Signal: When an activity sends or receives a message, that activity is called a signal.
Signals are of two types: Input signal (Message receiving activity) shown by a concave
polygon and Output signal (Message sending activity) shown by a convex polygon.

Concurrent Activities: Some activities occur simultaneously or in parallel. Such

activities are called concurrent activities. For example, listening to the lecturer and
looking at the blackboard is a parallel activity. This is represented by a horizontal split

46
(thick dark line) and the two concurrent activities next to each other, and the horizontal
line again to show the end of the parallel activity.

Final Activity: The end of the Activity diagram is shown by a bull's eye symbol, also
called as a final activity.

Class Diagram

An object is any person, place, thing, concept, event, screen, or report applicable to your
system. Objects both know things (they have attributes) and they do things (they have
methods).

A class is a representation of an object and, in many ways; it is simply a template from

which objects are created. Classes form the main building blocks of an object-oriented
application. Although thousands of students attend the university, you would only
model one class, called Student, which would represent the entire collection of students.

Responsibilities

Classes are typically modeled as rectangles with three sections: the top section for the
name of the class, the middle section for the attributes of the class, and the bottom
section for the methods of the class. Attributes are the information stored about an
object, while methods are the things an object or class do. For example, students have
student numbers, names, addresses, and phone numbers. Those are all examples of the
attributes of a student. Students also enroll in courses, drop courses, and request
transcripts. Those are all examples of the things a student does, which get implemented

47
(coded) as methods. You should think of methods as the object-oriented equivalent of
functions and procedures.

Object Diagram
An object diagram in the Unified Modeling Language (UML), is a diagram that shows a
complete or partial view of the structure of a modeled system at a specific time.

An Object diagram focuses on some particular set of objects instances and attributes,
and the links between the instances. A correlated set of object diagrams provides insight
into how an arbitrary view of a system is expected to evolve over time. Object diagrams
are more concrete than class diagrams, and are often used to provide examples, or act as
test cases for the class diagrams. Only those aspects of a model that are of current
interest need be shown on an object diagram. State chart diagram

State chart 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. State chart
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 State chart diagram we must have clarified the following points:

Identify important objects to be analyzed.

Identify the states.

Identify the events.

Deployment Diagram

Deployment diagrams are used to visualize the topology of the physical components of
a system where the software components are deployed.So deployment diagrams are
used to describe the static deployment view of a system. Deployment diagrams consist
of nodes and their relationships.

The purpose of deployment diagrams can be described as:

48
The name Deployment itself describes the purpose of the diagram. Deployment
diagrams are used for describing the hardware components where software components
are deployed.

Visualize hardware topology of a system.

Describe the hardware components used to deploy software components.

Describe runtime processing nodes.

Servlet,Jsp(J2EE)

ServletEngine

Application

Actor Hospitality

JSPEngine

Database

Fig: Deployment Diagram

49
4.6 UML Diagrams:

4.6.1 Driver Module:

Use Case Diagram:

Fig: Use Case Diagram

50
Sequence Diagram:

Fig: Sequence Diagram

51
Activity Diagram:

Fig: Activity Diagram

52
State chart Diagram:

Fig: State chart Diagram

53
Class Diagram:

Fig: Class Diagram

54
Collaboration Diagram:

Fig: Collaboration Diagram

55
 Chapter 5
System Description
 5.System Description
This system provides the well GUI to the users and this is very easy to implement. It is
user interactive and easy to use.

5.1 Study Of The System:

In the flexibility of uses the interface has been developed a graphics concepts in mind,
associated through a browser interface. The GUI’s at the top level has been categorized
as follows

Administrative User Interface Design

The Operational and Generic User Interface Design

The administrative user interface concentrates on the consistent information that is

practically, part of the organizational activities and which needs proper authentication
for the data collection. The Interface helps the administration with all the transactional
states like data insertion, data deletion, and data updating along with executive data
search capabilities.

The operational and generic user interface helps the users upon the system in
transactions through the existing data and required services. The operational user
interface also helps the ordinary users in managing their own information helps the
ordinary users in managing their own information in a customized manner as per the
assisted flexibilities.

5.2 Module Description:

Bus Driver:

Registration /Login

Start Tracking

Stop Tracking
User:

1. Registration/Login

2. View Buses

3. View Bus Location on Google Map.

56
5.2.5 Statistics:
In this module user can see available space to further upload data, and also the used
space in a graphical representation using pie-chart. Different colors are used to
represent both used and remaining space of the bucket in cloud. Each user is given a
space of 20MB. This module helps user to know about the space available in cloud to
store data.

57
 Chapter 6
System Testing
 6.System Testing
Testing is a process, which reveals errors in the program. It is the major quality measure
employed during software development. During testing, the program is executed with a
set of test cases and the output of the program for the test cases is evaluated to
determine if the program is performing as it is expected to perform.

6.1. Introduction:
Software testing is a critical element of software quality assurance and represents the
ultimate review of specification, design and coding. In fact, testing is the one step in the
software engineering process that could be viewed as destructive rather than
constructive.

A strategy for software testing integrates software test case design methods into a well-
planned series of steps that result in the successful construction of software. Testing is
the set of activities that can be planned in advance and conducted systematically. The
underlying motivation of program testing is to affirm software quality with methods that
can economically and effectively apply to both strategic to both large and small-scale
systems.

6.2. Strategic Approach To Software Testing:

The software engineering process can be viewed as a spiral. Initially system engineering
defines the role of software and leads to software requirement analysis where the
information domain, functions, behavior, performance, constraints and validation
criteria for software are established. Moving inward along the spiral, we come to design
and finally to coding. To develop computer software we spiral in along streamlines that
decrease the level of abstraction on each turn.

A strategy for software testing may also be viewed in the context of the spiral. Unit
testing begins at the vertex of the spiral and concentrates on each unit of the software as
implemented in source code. Testing progress is done by moving outward along the
spiral to integration testing, where the focus is on the design and the construction of the
software architecture. Talking another turn on outward on the spiral we encounter
validation testing where requirements established as part of software requirements
analysis are validated against the software that has been constructed.

58
Finally we arrive at system testing, where the software and other system elements are
tested as a whole.

UNIT TESTING

MODULE TESTING

SUB-SYSTEM TESING
Component Testing

SYSTEM TESTING

Integration Testing

ACCEPTANCE TESTING

User Testing

6.3 Software Testing:

Software testing is a critical element of software quality and assurance and represents
ultimate review of specifications, design and coding. Testing is an exposure of the
system to trial input to see whether it produces correct output.

6.4 Testing Phases:

Software testing includes the following:

1. Test activities are determined and test data selected

2. The test is conducted and test results are compared with the expected results.

59
6.5 Testing Activities

INSPECTING COMPONENTS: This finds faults in the individual component through

the manual inspection of its source code.

UNIT TESTING: This find faults by isolating an individual component using test stubs
and drivers and by exercising the components using a test case.

INTEGRATION TESTING: This finds faults by integrating several components

together. System testing, which focuses on the complete system, its functional and non-
functional requirements and its target environment.

6.6 Unit Testing

Unit testing focuses on the building blocks of the software system, that is, objects and
subsystems. They are three motivations behind focusing on components. First, unit
testing reduces the complexity of the overall test activities, allowing us to focus on
smaller units of the system. Unit testing makes it easier to pinpoint and correct faults
given that few computers are involved in this test. Unit testing allows parallelism in the
testing activities; that is each component can be tested independently of one another.

The specific candidates for unit testing are chosen from the object model and the system
decomposition of the system. In principle, all the objects developed during the
development process should be tested. Which is often not feasible because of time and
budget?

Many unit testing techniques have been devised. Some of them are:

6.6.1 Equivalence Testing

It is a black box testing technique that minimizes the number of test cases. The possible
inputs are partitioned into equivalence classes, and a test case is selected for each class.
The assumption of equivalence testing is that the system usually behaves in similar
ways for all members of a class. To test the behaviour associated with an

60
equivalence class, we only need to test one member of the class. Equivalence testing
consists of two steps: identification of the equivalence classes and selection of the test
inputs.

The following criteria are used for the equivalence testing:

COVERAGE: Every possible input belongs to one of the equivalent classes.

DISJOINTEDNESS: No input belongs to one of the equivalent classes.

REPRESENTATION: If the execution demonstrates an error when a particular

member of an equivalence class is used as input, then the same error can be detected by
using any other member of the class as input.

6.6.2 Boundary Testing:

Boundary testing is a special case of equivalence testing and focuses on the conditions
at the boundary of the equivalence classes. Rather than selecting any element in the
equivalence class, boundary testing requires that the element be selected from the
“edges” of the equivalence class.

A disadvantage of equivalence class and boundary testing is that these techniques do

not explore combination of test input data.

6.6.3 Path Testing:

Path testing is a white box testing technique that identifies faults in the implementation
of the component. The assumption behind path is that, by exercising all possible paths
through the code at least once, most faults will trigger failures. The identification of
paths requires knowledge of the source code and data structures.

The path testing technique was developed for imperative languages. Object oriented
language introduce several difficulties when using path testing.

POLYMORPHISM: Polymorphism enables messages to be bound to different methods

bases on the class of the target. Although this enables developers to reuse code across a
large number of classes, it is also introduce more cases to test.

61
Shorter Methods: Methods in object oriented language have the tendency to be shorter
then procedures and functions in imperative languages. This decreases the likelihood of
control flow faults, which can be uncovered using the path testing technique

6.6.4 State Based Testing:

Object oriented languages introduce the opportunity for new types of faults in object-
oriented systems.

State based testing is a recent testing technique, which focuses on object-oriented

systems. Most testing technique, which focuses on selecting a number of test inputs for
a given state of the system, exercising a component or a system, and comparing the
observed outputs with java. State based testing focuses on comparing the resulting state
of the system with the expected state. In the context of a class, state-based testing
consists of deriving test cases from the UML state chart diagram for the class.

6.6.5 Integration Testing:

It detects faults that have not been detected during unit testing, by focusing on small
group of components.

6.7 Test Case Design:

The design of tests for software and other engineering products can be as challenging as
the initial design of the product. Test case methods provide the developer with a
systematic approach to testing. Moreover, these methods provide a mechanism that can
help to ensure the completeness of tests and provide the highest like hood for
uncovering errors in software.

Any Engineered product can be tested in either of the two ways:

Knowing the specified function that a product has been designed to perform, tests can
be conducted. These tests demonstrate whether each function is full operational and at
the same time searches for errors in each function.

62
Knowing the internal workings of a product, tests can be conducted to ensure that
internal operations are performed according to specifications and all internal
components hence been adequately exercised.

Test case design methods are divided into two types:

White-box testing

Black-box testing

6.7.1 White-Box Testing:

White –box testing, sometimes called glass-box testing is a test, case designed method
that uses the control structure of the procedural design to derive test cases. Using white-
box testing methods, the s/w engineer can derive test cases that guarantee that all
independent paths within a module have been exercised at least once. Exercise all
logical decisions on their true and false sides. Execute all loops at their boundaries and
within their operational bounds. Exercise internal data structures to ensure their validity.

Basis path testing is a white-box testing technique. The basis path method enables the
test case designer to derive a logical complexity measure of a procedural design and use
this measure as a guide for defining a basis set are guaranteed to exercise every
statement in the program at least one time during testing.

6.7.2 Black-Box Testing:

Black-box testing ,also called behavioural testing, focuses on the functional
requirements of the s/w. Black-box testing enables the software engineer to derive sets
of input conditions that will fully exercise all functional requirements of a program. It is
a complementary approach that is likely to uncover a different class of errors that white-
box methods could not.

Black-box testing attempted to find errors in the following categories.

Incorrect or missing functions.

Interface errors.

Errors in data structures or external data base access.

Behavior or performance errors.

Initialization and termination errors.

63
Black-box testing purposely disregards control structure; attention is focused on
information domain. By applying black-box techniques, we derive a set of cases that
satisfies the criteria test cases that reduce, by a count that is greater than one, the
number of additional test cases that must be designed to achieve reasonable testing. Test
cases that tell us something about the presence or absence of classes of errors, rather
than an error associated only with the specified test.

64
6.8 Test Approach:
Testing can be done in two ways

6.8.1 Bottom Up Approach:

Testing can be performed starting from smallest and lowest level modules and
proceeding one at a time. For each module in the bottom up testing a short program
executes the module and provides the needed data so that the module is asked to
perform the way it will when embedded with in the larger system. When bottom level
modules are tested attention turns to those on the next level hat use the lower level one
they are tested individually and then linked with the previously examined lower level
modules.

6.8.2 Top Down Approach:

This type of testing starts from upper level modules. Since the detailed activities
usually performed in the lower level routines are not provided stubs are written. A stub
is a module shell called by upper level module and that when reached properly will
return a message to the calling module indicating that proper interaction occurred. No
attempt is made to verify the correctness of the lower level module.

6.9 Project Testing

Testing related to Amazon leaflet android app is done successfully. It includes
validating credentials which involves checking access key and secret key of the cloud.
If both are correct then it gets connected to the cloud. In this project each user is
assigned with a folder to store his data. This folder name should be unique. This is also
tested, if same name is given by another user then it displays bucket name already exist.

65
Chapter 8
Conclusion
 8.Conclusion

The Smart college bus tracking system uses the wireless communication technique and
was successfully designed and tested for real time data. The system has the advantages
of small size, low costs, full-featured and powerful expansibility. It can be easily
installed and used in the buses to ease the burden of transport department as the
educational institutions have large number of buses. This system is based on embedded
system and can also be developed on android platform.

This is an intelligent and sophisticated mobile vehicle checking system that could keep-
up with fast infrastructural growth and road infrastructure development.

66
 Chapter 9
Future Scope
 9.Future Scope
In present system we use cloud to store and retrieve data. If one user stores data in cloud
only he can access it as he stores the data in his bucket. This can be extended in such a
way that data sharing can be implemented. If one user stores data in bucket and give his
private key to another user then he should be able to use data present in the user’s
bucket. This can be implemented depending on the cloud service provider as he is
responsible for providing security.

67
Chapter 10
References
 10.References

1. Kunal Maurya , Mandeep Singh , Neelu Jain “Real Time Vehicle Tracking System using
GSM and GPS technology. An anti theft tracking System”, International Journal of Electronics
and Computer Science Engineering ,ISSN 2277-1956/V1N3-1103-1107

2. Reynolds, J.C. ; Denaro, R.P. ; Kalafus, R.M.“GPS-based vessel position monitoring and
display system” ,Position Location and Navigation Symposium, 1990. Record. The 1990's - A
Decade of Excellence in the Navigation Sciences. IEEE PLANS 1990.

3. Ananthanarayanan, N., "Intelligent vehicle monitoring system using wireless

communication," Advances in Technology and Engineering (ICATE), 2013 International
Conference on , vol., no., pp.1,5, 23-25 Jan. 2013

4. Yunck, T.P.; Melbourne, W.G.; Thoenton, C.L., "GPS-Based Satellite Tracking System for
Precise Positioning," Geoscience and Remote Sensing, IEEE Transactions on , vol.GE-23, no.4,
pp.450,457, July 1985

5. Rude, M ; “A flexible, shock-absorbing bumper system with touch-sensing capability for

autonomous vehicles “ Intelligent Robots and Systems” 96, IROS 96, Proceedings of the 1996
IEEE/RSJ International Conference

6. Ramanath, T.S.; Sudharsan, A. ; Udhayaraj, U.F.; “Drunken driving and rash driving
prevention system” Mechanical and Electrical Technology (ICMET), 2010 2nd International
Conference

7. Karimi, H.A.; Lockhart, J.T., "GPS-based tracking systems for taxi cab fleet operations,"
Vehicle Navigation and Information Systems Conference, 1993., Proceedings of the IEEEIEE ,
vol., no., pp.679,682, 12-15 Oct 1993

8. Yagimli, M.; Varol, H.S., "A piezoelectric-based system design for sensing shocks " Recent
Advances in Space Technologies, 2009. RAST '09. 4th International Conference on , vol., no.,
pp.6,12, 11-13 June 2009

68
Appendices

List Of Figures

FIG2.2 Spiral Model 4

Fig 3.1 Java Architecture 8

Fig 4.4 System Work Flow 36

Fig 4.4 Use case Diagram 50

Fig 4.4 Sequence Diagram 51

Fig 4.4 Activity Diagram 52

Fig 4.4 State chart Diagram 53

Fig 4.4 Class Diagram 54

Fig 4.4 Collaboration Diagram 55

Fig 6.2 Strategic Approach To Software Testing 59

List of Tables

2.5 Hardware & Software Specifications 5

69