1.

INTRODUCTION

1.1 Purpose:

1.2 Scope:

1.3 Motivation:
1.4 Overview:

2. LITERATURE SURVEY
Literature survey is the most important step in software development process.
Before developing the tool it is necessary to determine the time factor, economy n
company strength. Once these things r satisfied, ten next steps are to determine which
operating system and language can be used for developing the tool. Once the
programmers start building the tool the programmers need lot of external support.
This support can be obtained from senior programmers, from book or from websites.
Before building the system the above consideration r taken into account for
developing the proposed system.

3. SYSTEM ANALYSIS

3.1 Introduction:
The phase in the system development life cycle that has crucial importance is
the phase of the system study and the problem formulation. It is said that unless we
understand the problem thoroughly, he will create problems rather than solving it.
This phase includes the study of the existing system.
The first step in planning a software project is to prepare a concise statement
of the problems to be solved and the constraints that exist for it solution/The problem
statement should include a description of the present situation and goals to be
achieved by the new system. The purpose is to get an idea about the operations and
the interactions of the system, its drawbacks and to identify further requirements.
1
 The analyst has to use various techniques to study the existing system. This
includes interview of the personal related to the system, study of the literature
available about the existing system, observation

3.2 Existing system:

3.2.1 Disadvantages:

3.3 Proposed system:

3.3.1 Advantages

3.4 Feasibility Study

Feasibility study aim is to objectively and rationally uncover the strengths
and weaknesses of the existing business or proposed venture, opportunities and threats
as presented by the environment, the resources required to carry through, and
ultimately the prospects for success. In its simplest term, the two criteria to judge
feasibility are cost required and value to be attained.

The different types of feasibility studies are as follows

1. Economical feasibility.

2. Operational feasibility.

2
3. Technical feasibility..

3.4.1 Economic Feasibility:

This study is carried out to check the economic impact that the system will
have on the organization. The amount of fund that the company can pour into the
research and development of the system is limited. The expenditures must be justified.
Thus the developed system as well within the budget and this was achieved because
most of the technologies used are freely available. Only the customized products had
to be purchased.

3.4.2 Operational Feasibility:

Operational feasibility is a measure of how well a proposed system solves the

problems, and takes advantage of the opportunities identified during scope definition
and how it satisfies the requirements identified in the requirements analysis phase of
system development.

The proposed system is operationally feasible so that the end user can easily
access the developed system. Since the system is developed as windows application
the navigation of the system is based on the user actions performed.

3.4.3 Technical Feasibility:

Technical feasibility is carried out to determine whether the company has the
capability, in terms of software, hardware, personnel and expertise, to handle the
completion of the project. Evaluating the technical feasibility is the trickiest part of a
feasibility study. Earlier no system existed to cater to the needs of detecting false data.

The current system developed is technically feasible. It is windows based user

interface developed with the support of java language. Thus it provides an easy access
to the users. Therefore, it provides the technical guarantee of accuracy, reliability and
security. The work for the project is done with the current equipment and existing
software technology.
3
 4. SYSTEM REQUIREMENTS AND SPECIFICATIONS

4.1 INTRODUCTION:
The designing of the software requirements specifications (SRS) has been
specified in the standards. A well designed, well-written SRS accomplishes four
major goals. It provides feedback to the customer. An SRS is the customer’s
assurance that the development organization understands the issues or problems to be
solved and the software behavior necessary to address those problems. Therefore, the
SRS should be written in natural language (versus a formal language, explained later
in this article),in an unambiguous manner that may also include charts, data flow
diagrams, decision tables, and soon. It decomposes the problem into component parts.
The simple act of writing down software requirements in a well-designed format
organizes information, and help break down the problems into its components parts. It

4
serves as an input to the design specification. The SRS serves as the parent document
to subsequent documents, such as the software design specification and statement of
work. It serves as a product validation check.

4.2. Purpose
We experimentally evaluate the performance and quality of the retrieval
algorithms. Algorithm computes the IR score for each document, and returns the true
top-k to the user. Therefore; this algorithm is guaranteed to generate a perfect ranking
at the expense of a significant cost of downloading all documents before ranking
them.

4.3 Functional Requirements

Descriptions of data to be entered into the system

Descriptions of operations performed by each screen

Descriptions of work-flows performed by the system

Descriptions of system reports or other outputs

Who can enter the data into the system?

How the system meets applicable regulatory requirements

The functional specification is designed to be read by a general audience. Readers

should understand the system, but no particular technical knowledge should be
required to understand the document.

4.4 Non-Functional Requirements

Non-Functional requirements describe how the product should be implemented. A
Non-Functional requirement is a requirement that specifies criteria that can be used to
judge the operation of a system, rather than specific behaviors. Non-Functional
requirements are often called qualities of a system. The major Non-Functional
requirements of the system are as follows.

5
4.5 Software and Hardware specifications

5. SYSTEM DESIGN
5.1 System Specification:

The purpose of the design phase is to plan a solution of the problem specified
by the requirement document .the phase is the first step to moving from the problem
domain to the solution domain. In other words starting with what is need full of
designing to take us toward how to satisfy the needs. The design of the system is
perhaps the most critical factor of affection the quality of the software, the output of
this phase is design document.
System design also called top level design aims to identifies the modules
should be in the system, the specification of these modules, and how they interact
with each other to produce the desired results .at the end of the system design all the
major data structures, file formats, output formats and major modules in the system
and their specification are decided.

5.2 UML Diagrams

5.2.1 UML Architecture

Any real world system is used by different users. The users can be developers,
testers, business people, analysts and many more. So before designing a system the
architecture is made with different perspectives in mind. The most important part is to
visualize the system from different viewer’s perspective. The better understand the
better we make the system. UML plays an important role in defining different
perspectives of a system. These perspectives are:
6
  Design
 Implementation

 Process

 Deployment

And the centre is the Use Case view which connects all these four. A Use case
represents the functionality of the system. So the other perspectives are connected
with use case.

 Design of a system consists of classes, interfaces and collaboration. UML

provides class diagram, object diagram to support this.
 Implementation defines the components assembled together to make a
complete physical system. UML component diagram is used to support
implementation perspective.

 Process defines the flow of the system. So the same elements as used in
Design are also used to support this perspective.

 Deployment represents the physical nodes of the system that forms the
hardware. UML deployment diagram is used to support this perspective.

5.2.2 UseCase Diagram

Overview
To model a system the most important aspect is to capture the dynamic
behavior. To clarify a bit in details, dynamic behavior means the behavior of
the system when it is running operating. So only static behavior is not
sufficient to model a system rather dynamic behavior is more important than
static behavior. In UML there are five diagrams available to model dynamic
nature and use case diagram is one of them. Now to discuss that the use case
diagram is dynamic in nature there should be some internal or external factors
for making the interaction. These internal and external agents are known as
actors. So use case diagrams are consists of actors, use cases and their

7
 relationships. The diagram is used to model the system/subsystem of an
application. A single use case diagram captures a particular functionality of a
system. So to model the entire system numbers of use case diagrams are used.

Fig:5.2.2 Use case diagram

5.2.3 Class diagram

A class diagram is a picture for describing generic descriptions of possible

systems. Class diagrams and Collaboration diagrams are alternate representations of
object models. Class diagrams contain classes and object diagrams contain objects,
but it is possible to mix classes and objects when dealing with various kinds of
metadata, so the separation is not rigid.

Class diagrams are more prevalent than object diagrams. Normally you will
build class diagrams plus occasional object diagrams illustrating complicated data
structures or message-passing structures.

Class diagrams contain icons representing classes, interfaces, and their

relationships. You can create one or more class diagrams to depict the classes at the
top level of the current model; such class diagrams are themselves contained by the
top level of the current model. You can also create one or more class diagrams to
depict classes contained by each package in your model; such class diagrams are
themselves contained by the package enclosing the classes they depict; the icons
representing logical packages and classes in class diagrams.

One can change properties or relationships by editing the specification or

modifying the icon on the diagram. The associated diagrams or specifications are
automatically updated.

8
Class Diagram

Fig: 5.2.3 Class diagram

5.2.4 Sequence diagram

A sequence diagram is a graphical view of a scenario that shows object

interaction in a time-based sequence, what happens next. Sequence diagrams establish
the roles of objects and help provide essential information to determine class
responsibilities and interfaces. This type of diagram is best used during early analysis
phases in design because they are simple and easy to comprehend. Sequence diagrams
are normally associated with use cases.

Sequence diagrams are closely related to collaboration diagrams and both are
alternate representations of an interaction. There are two main differences between
sequence and collaboration diagrams: sequence diagrams show time-based object
interaction while collaboration diagrams show how objects associate with each other.
A sequence diagram has two dimensions: typically, vertical placement represents time
and horizontal placement represents different objects.

Fig:5.2.4 Sequence diagram

9
5.2.5 Collaboration diagram
Class diagrams indicates what classes are part of the system, what they offer,
how they relate, But they don’t tell us how they communicate. Collaboration diagrams
show (used to model) How objects interact and their roles. They are very similar to
sequence diagrams Sequence Diagrams are arranged according to Time. Collaboration
Diagrams represent the structural organization of object.
Collaboration diagrams are used to show how objects interact to perform the
behavior of a particular use case, or a part of a use case. Along with sequence
diagrams, collaborations are used by designers to define and clarify the roles of the
objects that perform a particular flow of events of a use case. They are the primary
source of information used to determining class responsibilities and interfaces.
Unlike a sequence diagram, a collaboration diagram shows the relationships
among the objects. Sequence diagrams and collaboration diagrams express similar
information, but show it in different ways. Collaboration diagrams show the
relationships among objects and are better for understanding all the effects on a given
object and for procedural design.
Because of the format of the collaboration diagram, they tend to better suited
for analysis activities. Specifically, they tend to be better suited to depicting simpler
interactions of smaller numbers of objects. As the number of objects and messages
grows, the diagram becomes increasingly hard to read. In addition, it is difficult to
show additional descriptive information such as timing, decision points, or other
unstructured information that can be easily added to the notes in a sequence diagram.

Fig: 5.2.5 Collaboration diagram

5.2.6 State chart diagram

A State chart diagram describes a state machine. Now to clarify it state

machine can be defined as a machine which defines different states of an object and
these states are controlled by external or internal events.

10
 Fig: 5.2.6 State Chart diagram

5.2.7 Activity diagram

Activity diagrams provide a way to model the workflow of a business process.

You can also use activity diagrams to model code-specific information such as a class
operation. Activity diagrams are very similar to a flowchart because you can model a
workflow from activity to activity. An activity diagram is basically a special case of a
state machine in which most of the states are activities and most of the transitions are
implicitly triggered by completion of the actions in the source activities. The main
difference between activity diagrams and state charts is activity diagrams are activity
centric, while state charts are state centric. An activity diagram is typically used for

11
modeling the sequence of activities in a process, whereas a state chart is better suited
to model the discrete stages of an object’s lifetime.

Fig:5.2.7 Activity diagram

5.3 Module description

Distributed Cut Detection:

The algorithm allows each node to detect DOS events and a subset of
nodes to detect CCOS events. The algorithm we propose is distributed and
asynchronous: it involves only local communication between neighboring nodes, and
is robust to temporary communication failure between node pairs. A key component
of the DCD algorithm is a distributed iterative computational step through which the
nodes compute their (fictitious) electrical potentials. The convergence rate of the
computation is independent of the size and structure of the network.

CUT:

Wireless sensor networks (WSNs) are a promising technology for monitoring large
regions at high spatial and temporal resolution. In fact, node failure is expected to be quite
common due to the typically limited energy budget of the nodes that are powered by small
batteries. Failure of a set of nodes will reduce the number of multi-hop paths in the
network. Such failures can cause a subset of nodes – that have not failed – to become
disconnected from the rest, resulting in a “cut”. Two nodes are said to be disconnected if
there is no path between them.

SOURCE NODE:

We consider the problem of detecting cuts by the nodes of a wireless network.

We assume that there is a specially designated node in the network, which we call the
source node. The source node may be a base station that serves as an interface
between the network and its users. Since a cut may or may not separate a node from

12
the source node, we distinguish between two distinct outcomes of a cut for a
particular node.

CCOS AND DOS:

When a node u is disconnected from the source, we say that a DOS

(Disconnected from Source) event has occurred for u. When a cut occurs in the
network that does not separate a node u from the source node, we say that CCOS
(Connected, but a Cut Occurred Somewhere) event has occurred for u. By cut
detection we mean (i) detection by each node of a DOS event when it occurs, and (ii)
detection of CCOS events by the nodes close to a cut, and the approximate location of
the cut.

NETWORK SEPERATION:

Failure of a set of nodes will reduce the number of multi-hop paths in the
network. Such failures can cause a subset of nodes – that have not failed – to become
disconnected from the rest, resulting in a “cut”. Because of cut, some nodes may
separated from the network, that results the separated nodes can’t receive the data
from the source node

13
 6. IMPLEMENTATION

6.1 Technology Description

6.2 Sample Code

7. SYSTEM TESTING
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.

14
 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.

7.1 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 by moving outward along
the spiral to integration testing, 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. Finally we arrive
at system testing, where the software and other system elements are tested as a whole.

7.2 Testing Methodologies

 Black box Testing: is the testing process in which tester can perform testing
on an application without having any internal structural knowledge of
application.
 White box Testing: is the testing process in which tester can perform testing
on an application with having internal structural knowledge.
 Gray Box Testing: is the process in which the combination of black box and
white box tonics’ are used.
Levels of Testing

15
 Module1 Module2 Module3
Units Units Units

i/p Integration o/p i/p Integration o/p

System Testing: Presentation + business +Databases

UAT: user acceptance testing

Figure 7.1 STLC (Software Testing Life Cycle)

Test Planning
1. Test Plan is defined as a strategic document which describes the procedure
how to perform various testing on the total application in the most efficient
way.
2. This document involves the scope of testing,
3. Objective of testing,
4. Areas that need to be tested,
5. Areas that should not be tested,
6. Scheduling Resource Planning,
7. Areas to be automated, various testing tools used….

Test Development
1. Test case Development (check list)
2. Test Procedure preparation (Description of the Test cases).
3. Implementation of test cases, observing the result.
Result Analysis
1. Expected value: is nothing but expected behavior of application.
16
 2. Actual value: is nothing but actual behavior of application
Bug Tracing: Collect all the failed cases, prepare documents.
Reporting: Prepare document (status of the application)

7.3 Test Types

7.3.1 Unit Testing

Unit testing involves the design of test cases that validate that the internal
program logic is functioning properly, and that program inputs produce valid outputs.
All decision branches and internal code flow should be validated. It is the testing of
individual software units of the application .it is done after the completion of an
individual unit before integration. This is a structural testing, that relies on knowledge
of its construction and is invasive. Unit tests perform basic tests at component level
and test a specific business process, application, and/or system configuration. Unit
tests ensure that each unique path of a business process performs accurately to the
documented specifications and contains clearly defined inputs and expected results.

Unit testing is usually conducted as part of a combined code and unit test
phase of the software lifecycle, although it is not uncommon for coding and unit
testing to be conducted as two distinct phases.

Test Strategy Approach

Field testing will be performed manually and functional tests will be written in detail.

Test objectives

 All field entries must work properly.

 Pages must be activated from the identified link.
 The entry screen, messages and responses must not be delayed.
17
Features to be tested

 Verify that the entries are of the correct format

 No duplicate entries should be allowed
All links should take the user to the correct page.

7.3.2 Integration Testing

Integration tests are designed to test integrated software components to

determine if they actually run as one program. Testing is event driven and is more
concerned with the basic outcome of screens or fields. Integration tests demonstrate
that although the components were individually satisfaction, as shown by successfully
unit testing, the combination of components is correct and consistent. Integration
testing is specifically aimed at exposing the problems that arise from the
combination of components.

Software integration testing is the incremental integration testing of two or more

integrated software components on a single platform to produce failures caused by
interface defects.

The task of the integration test is to check that components or software

applications, e.g. components in a software system or – one step up – software
applications at the company level – interact without error.

Test Results: All the test cases mentioned above passed successfully. No defects
encountered.

Integration testing is classifies in two types…

1. Top-Down Integration Testing.

2. Bottom-Up Integration Testing.

In Top-Down Integration Testing modules are integrated by moving downward

through the control hierarchy, beginning with the main control module.
18
In Bottom-Up Integration Testing each sub module is tested separately and then the
full system is tested.

Integration testing in this project: In this project integrating all the modules forms the
main system. Means I used Bottom-Up Integration Testing for this project.

When integrating all the modules I have checked whether the integration effects
working of any of the services by giving different combinations of inputs with which
the two services run perfectly before Integration.

7.3.3 System Testing

System testing ensures that the entire integrated software system meets
requirements. It tests a configuration to ensure known and predictable results. An
example of system testing is the configuration oriented system integration test.
System testing is based on process descriptions and flows, emphasizing pre-driven
process links and integration points.

7.3.4 Functional Testing

Functional tests provide systematic demonstrations that functions tested are

available as specified by the business and technical requirements, system
documentation, and user manuals.

Functional testing is centered on the following items:

Valid Input : identified classes of valid input must be accepted.

Invalid Input : identified classes of invalid input must be rejected.

Functions : identified functions must be exercised.

Output : identified classes of application outputs must be exercised.

Systems/Procedures : interfacing systems or procedures must be invoked.

Organization and preparation of functional tests is focused on requirements,

key functions, or special test cases. In addition, systematic coverage pertaining to
identify Business process flows; data fields, predefined processes, and successive

19
processes must be considered for testing. Before functional testing is complete,
additional tests are identified and the effective value of current tests is determined.

7.3.5 Acceptance Testing

User Acceptance Testing is a critical phase of any project and requires

significant participation by the end user. It also ensures that the system meets the
functional requirements.

7.4 TEST CASES

20
7.5 Screen Shots

8. CONCLUSION AND FUTURE ENHANCEMENT

8.1 Conclusion
8.2 Future enhancement

BIBLIOGRAPHY
References

Links
http://java.sun.com

http://www.sourcefordgde.com

http://www.networkcomputing.com/

http://www.roseindia.com/

http://www.java2s.com/

21
22