1.1 Brief Information About The Project: Security Using Pre-Existing Routing For Mobile Ad-Hoc Nerwork

Security using pre-existing routing
for mobile ad-hoc nerwork
1. INTRODUCTION
1.1 Brief Information about the Project
MOBILE autonomous networked systems have seen increased usage by the
military and commercial sec-tors for tasks deemed too monotonous or hazardous
forhumans. An example of an autonomous networked systemis the Unmanned Aerial
Vehicle (UAV). These can be smallscale,networked platforms. Quadricopter swarms
area noteworthy example of such UAVs. Networked UAVshave particularly
demanding communication requirements,as data exchange is vital for the on-going
operation of the network. UAV swarms require regular network control
communication, resulting in frequent route changes due totheir mobility. This
topology generation service is offered by a variety of Mobile Ad hoc Network
(MANET) routing protocols [1].MANETs are dynamic, self-configuring, and
infrastructure-less groups of mobile devices. They are usually created for a specific
purpose. Each device within a MANET isknown as a node and must take the role of a
client and arouter. Communication across the network is achieved by forwarding
packets to a destination node; when a directsource-destination link is unavailable
intermediate nodesare used as routers.MANET communication is commonly wireless.
Wireless communication can be trivially intercepted by any node in range of
the transmitter. This can leave MANETs open to a range of attacks, such as the Sybil
attack androute manipulation attacks that can compromise the integrity of the network
[2].Eaves dropped communication may equip attackers with the means to compromise
the trust worthiness of a network.This is achieved by manipulating routing tables,
injecting false route data or modifying routes. Man in the middle(MitM) attacks can be
lauched by manipulating routing data to pass traffic through malicious nodes [3].
Secure routing protocols have been proposed to mitigate attacks against MANETs, but
these do not extend protection to other data.Autonomous systems require a significant
amount of communication [4]. Problem solving algorithms, such as Distributed Task
Allocation (DTA), are required to solvetask planning problems without human
intervention [4].As a result, these algorithms are vulnerable to packet loss and false
messages; partial data will lead to sub-optimal orfailed task assignments. The
flexibility and mobility of Mobile Ad hoc Networks (MANETs) have made them
increasing popular in a wide range of use cases.
1
1.2 Motivation and contribution of Project
This paper proposes a novel security protocol Security Using Pre-Existing
Routing for Mobile Ad hoc Networks(SUPERMAN). The protocol is designed to
address node authentication, network access control, and secure communication for
MANETs using existing routing protocols.SUPERMAN combines routing and
communication security at the network layer. This is in contrast to existing
approaches, which provide only routing or communication security, requiring multiple
protocols to protect the network.The remainder of this paper is organised as
follows:Section 2 analyses the problem in the context of previously published work.
Section 3 introduces SUPERMAN, providing a technical discussion of the protocol.
Section 4 outlinesthe characteristics chosen for modelling, and the results of
simulating SUPERMAN compared against selected secure.
1.3 Objective of the Project
MANETs are dynamic, self-configuring, and infrastructure-less groups of
mobile devices. They are usually createdfor a specific purpose. Each device within a
MANET is known as a node and must take the role of a client and arouter.
Communication across the network is achieved by forwarding packets to a destination
node; when a direct source-destination link is unavailable intermediate nodesare used
as routers.
MANET communication is commonly wireless. Wireless communication can be
trivially intercepted by anynode in range of the transmitter.
1.4 Organization of the Project
 Chapter2: Literature Survey: This chapter mainly consists of background of
the project, possible approaches, and the related base papers where this project
derived from.
 Chapter3: System Analysis: This chapter mainly consists of description of
existing system, proposed system, and requirement specifications.
 Chapter4: System Design: This chapter mainly consists of module
descriptions and algorithms with examples and unified modeling language
diagrams: use case diagrams, class diagrams, sequence diagrams, collaboration
diagrams, and activity diagrams.
 Chapter 5: Technology Description: This chapter mainly consists of
technology used in this project.
2
 Chapter 6: Sample code: This chapter mainly consists of sample code for few
module.
 Chapter 7: Testing: This chapter mainly consists of testing techniques and
test cases for modules and Test screenshots.
 Chapter 8:Screenshots: This chapter mainly consists of output screens of this
project
 Conclusion: Main conclusion of this project.
3
2. LITERATURE SURVEY
The literature review plays a very vital role in the research process. It is a basis
from where research thoughts are drawn and developed into concepts and finally
theories. It also provides the researcher a bird’s eye view about the research done in
that area so far. A survey gives an oversight of a field and is thus distinguishing from a
sort of study which consists of a microscopic examination of a turf; it is a map rather
than a detailed plan. Depending on what is observed in the literature review, a
researcher will understand where his/her research stands.
D. Smith, J. Wetherall proposed “A cluster-based approach to consensus
based distributed task allocation”[1]This paper presents a novel extension to the
Consensus-Based Bundle Algorithm (CBBA), which we have named Cluster-Formed
Consensus-Based Bundle Algorithm (CFCBBA). CF-CBBA is designed to reduce the
amount of communication required to complete a distributed task allocation process,
by partitioning the problem and processing it in parallel clusters. CF-CBBA has been
shown, in comparison with baseline CBBA, to require less communication when
allocating tasks. Three key aspects of task allocation have been investigated, (a) the
time taken to allocate tasks, (b) the amount of communication necessary to satisfy the
requirements of distributed task allocation algorithms such as CBBA, and (c) the
efficiency with which a collection of tasks (a mission) is completed by a group of
robots (a collective).
I. D. Chakeres and E. M. Belding-Royer proposed ”Aodv routing protocol
implementation design”[2]To date, the majority of ad hoc routing protocol
researchhas been done using simulation only. One of the most motivatingreasons to
use simulation is the difficulty of creatinga real implementation. In a simulator, the
code is containedwithin a single logical component, which is clearly definedand
accessible. On the other hand, creating an implementationrequires use of a system with
many components, includingmany that have little or no documentation. The
implementationdeveloper must understand not only the routingprotocol, but all the
system components and their complexinteractions. Further, since ad hoc routing
protocolsare significantly different from traditional routing protocols,a new set of
features must be introduced to support therouting protocol. In this paper we describe
the event triggersrequired for AODV operation, the design possibilitiesand the
4
decisions for our Ad hoc On-demand Distance Vector(AODV) routing protocol
implementation, AODV-UCSB.This paper is meant to aid researchers in developing
theirown on-demand ad hoc routing protocols and assist usersin determining the
implementation design that best fits theirneeds.
T. Clausen, P. Jacquet proposed “Optimized link state routing protocol
(olsr)”[3]In this paper we propose and discuss an optimized link state routing
protocol, named OLSR, for mobile wireless networks. The protocol is based on the
link state algorithm and it is proactive (or table-driven) in nature. It employs periodic
exchange of messages to maintain topology information of the network at each node.
OLSR is an optimization over a pure link state protocol as it compacts the size of
information sent in the messages, and furthermore, reduces the number of
retransmissions to flood these messages in an entire network. For this purpose, the
protocol uses the multipoint relaying technique to efficiently and economically flood
its control messages. It provides optimal routes in terms of number of hops, which are
immediately available when needed. The proposed protocol is best suitable for large
and dense ad hoc networks.
M. Hyland, B. E. Mullins proposed “Simulation-based performance
evaluation of mobile ad hoc routing protocols in a swarm of unmanned aerial
vehicles”[4] This paper evaluates the performance of several ad hoc routing protocols
in the context of a swarm of autonomous unmanned aerial vehicles (UAVs). It has
been proposed that a wireless network where nodes have on average 5.1774 log n
neighbors, where n is the total number of network nodes, has a high probability of
having no partitions. By decreasing transmission range and implementing multi-hop
routing between nodes, while ensuring network connectivity is maintained, spatial
multiplexing of the wireless channel is exploited. The proposed process is evaluated
using the OPNET network simulation tool for the Greedy Perimeter Stateless Routing
(GPSR), Optimized Link State Routing (OLSR), and Ad hoc On- demand Distance
Vector (AODV) routing protocols in the context of a swarm of UAVs.
J. Pojda, A. Wolff proposed “Performance analysis of mesh routing
protocols for uav swarming applications”[5] Unmanned Aerial Vehicles (UAVs)
are an emerging technology offering new opportunities for innovative applications and
efficient overall process management in the areas of public security, cellular networks
and surveying. A key factor for the optimizations yielded by this technology is an
advanced mesh network design for fast and reliable information sharing between
5
UAVs. In this paper, we analyze the performance of four available mesh routing
protocol implementations (open80211s, BATMAN, BATMAN Advanced and OLSR)
in the context of swarming applications for UAVs. The protocols are analyzed by
means of goodput in one static and one mobile scenario using the same embedded
hardware platform installed at UAVs in current research projects. Our results show
that layer-2 protocols suit better for mobile applications in comparison to layer-3. On
the other hand, they often cause routing flippings, which are unwanted route changes,
in static scenarios imposing a small performance decrease. Hence, given the
aforementioned routing protocols, we recommend to currently use open80211s or
batman-advanced to establish a reliable multi-hop mesh network for swarming
applications.
6
3. SYSTEM ANALYSIS
3.1 Existing System
In existing system, Reactive protocols such as Ad hoc On-demand Distance
Vector (AODV), plan routes when messages need to be sent, polling nearby nodes
in an attempt to find the shortest route to the destination node. Another system i.e.
Optimized Link State Routing (OLSR) takes a proactive approach, periodically
flooding the network to generate routing table entries that persist until the next
update. Both approaches are motion-tolerant and have been implemented in UAV
MANETS. Motion-tolerance and co-operative communication characteristics make
these protocols ideal for use in UAVs. In existing system, the flexibility and
mobility of Mobile Ad hoc Networks (MANETs) have made them increasing
popular in a wide range of use cases.To protect these networks, security protocols
have been developed to protect routing and application data.However, these
protocols only protect routes or communication, not both.Both secure routing and
communication security protocols must be implemented to provide full
protection.The use of communication security protocols originally developed for
wire line and Wi-Fi networks can also place a heavy burden on the limited network
resources of a MANET.
Disadvantages:
 The basic versions of AODV and OLSR lack security mechanisms
 Vulnerable to various attacks
 .Inability to distinguish legitimate nodes from malicious nodes
3.2 Proposed System
This paper proposes a novel security protocol, Security Using Pre-Existing
Routing for Mobile Ad hoc Networks (SUPERMAN). The protocol is designed to
address node authentication, network access control, and secure communication
for MANETs using existing routing protocols. SUPERMAN combines routing and
communication security at the network layer. This contrasts with existing
approaches, which provide only routing or communication security, requiring
multiple protocols to protect the network.
SUPERMAN is a framework that operates at the network layer (layer 3) of the OSI
model. It is designed to provide a fully secured communication framework for
7
MANETs, without requiring modification of the routing protocol which process
packets and provide confidentiality and integrity. SUPERMAN also provides node
authentication.
Advantages:
 Improve privacy of the network.
 Increase data integrity.
 Checks authenticity and integrity at each hop
Diffie-hellman key-exchange algorithm:
The Diffie-Hellman key-exchange algorithm provides a means of
generating symmetric keys dynamically and Is used to generate the SK keys. SKb keys
can simply be generated by means of random number generation or an equivalent
secure key generation service.
End-to-end Communication
• SKe keys are used to secure end-to-end communication with other nodes, with
one SKe key generated per node, for every other node also authenticated with
the network.
• SKp keys are used for point-to-point security and generated in the same
manner as SKe keys.
• It is important that SKe and SKp keys are different, as the network needs to
secure both the content of a packet and the route taken.
• A KDF can be used to generate these two keys in conjunction with the result of
the Diffie-Hellman algorithm, requiring a DKSp/DKSpriv pair, to minimize
the cost of security on the network and reduce the key re-use and, in turn the
lifetime of each key.
• These keys are generated when nodes receive DKSp’s from other
SUPERMAN nodes.
Point-to-point Communication
Secure footers are appended to all communication packets sent between
SUPERMAN nodes. Skbp and skp(x) keys are used in broadcast and unicast integrity
service provision respectively.
Broadcast
When a node initiates a broadcast, it uses the broadcast address for the
network. Instead of using a SKe or SKp ,which would only function between two
8
nodes,SKbe and SKbp are used. The packet is secured using the end-to-end and point-
to-point methods previously described.MANET routing protocols require broadcast
capabilities. Both OLSR and AODV require broadcast communication for routes
discovery. SUPERMAN provides broadcast com-munication security services to allow
it to service the specific needs of MANET routing protocols.
Authenticated Encryption with Associated Data (AEAD):
 Authenticated Encryption with Associated Data (AEAD) is an example of
such an algorithm.
 AEAD and related cryptographic algorithms provide confidentiality,
authenticity and integrity services.
 The end-to-end element of a SUPERMAN packet is not modified at any point
along a route.
 Its purpose is to provide confidentiality and source authentication services.
 End-to-end security provides security services between source and destination
nodes by using their shared SKe.
 Confidentiality and integrity are provided using an appropriate cryptographic
algorithm, which is used to generate an encrypted payload (EP).
3.3 Feasibility Study
The feasibility of the project is analyzed in this phase and business proposal is
put forth with a very general plan for the project and some cost estimates. During
system analysis the feasibility study of the proposed system is to be carried out. This is
to ensure that the proposed system is not a burden to the company. For feasibility
analysis, some understanding of the major requirements for the system is essential.
Three key considerations involved in the feasibility analysis are
 Economic Feasibility
 Technical Feasibility
 Social Feasibility
Economical 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.
9
Technical Feasibility
This study is carried out to check the technical feasibility, that is, the technical
requirements of the system. Any system developed must not have a high demand on
the available technical resources. This will lead to high demands on the available
technical resources. This will lead to high demands being placed on the client. The
developed system must have a modest requirement, as only minimal or null changes
are required for implementing this system.
Social Feasibility
The aspect of this study is to check the level of acceptance of the system by the
user. This includes the process of training the user to use the system efficiently. The
developed system is easily acceptable as all the methods employed are clear and easy
to understand.
3.4 Functional Requirements
 this system should provide a mechanism state of being free from danger or thread
 This system should be provide a encryption mechanism . encryption is the process
of convert plane text into cipher text.
 The system should provide protocol is a set of rules and guidelines for
communicating data.
3.5 Non Functional Requirements
 Security : The state of being free from danger or thread . here use manets for
providing security
 Efficiency : Efficiency is the ability to do things well, successfully, and without
waste. Here security using using pre existing for mobile adhoc network will
provides efficiency by using efficiency algorithems
 Integrity : Integrity, in the context of computer systems, refers to method of
ensuring that data is real, accurate and safeguarded from unauthorized user
modification . this project provides integrity for the system.
 Usability:
Insearch engine we access for quick query execution according to user need,
which is very helpful for getting the required result
 Performence:
10
The web search engines are composed by thousands of query processing nodes
and get result at user expected time.
3.6 Requirements Specification
3.6.1 Minimum Hardware Requirements
 System : Pentium IV 2.4 GHz.
 Hard Disk : 40 GB.
 RAM : 512 Mb.
3.6.2 Software Requirements

 Operating System : Windows XP/7.
 Coding Language : JAVA
 DataBase : MYSQL
11
4. SYSTEM DESIGN
4.1 Introduction
After analyzing the requirement 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 properties and requirements of a new system
is more difficult and requires creative thinking and understanding of existing running
system is more difficult, improper understanding of present system can lead diversion
from solution.
4.2 Process Architecture
12
Fig.4.2 process architecture security using pre-existing
routing for MANET
Description:SUPERMAN is a framework that operates at the networklayer (layer 3)
of the OSI model.
It is designed to provide afully secured communication framework for
MANETs, without requiring modification of the routing protocol.Fig. 1 shows the
flow of data from transport, through thenetwork layer (including SUPERMAN) to the
data linklayer. The dashed boxes represent elements of SUPERMAN that process
packets and provide confidentiality andintegrity. SUPERMAN also provides node
authentication.
4.3 MODULES DESCSRIPTION:
1.System Construction
In the first module, we develop the System Construction module with Source,
Router and Destination entities. The topology is the arrangement of nodes in the
simulation area. The routers are connected in MANET topology. In which each routers
are connected to each other via other routers (Path). In our simulation, we are using
multi-nodes as the router node and nodes as the client-server node. Totally we are
having multi-nodes in our network. Each host is connected via routers. Each host has
multiple paths to reach a single destination node in the network. The nodes are
connected by duplex link connection. The bandwidth for each link is 100 mbps and
delay time for each link is 10 ms. each edges uses Drop Tail Queue as the interface
between the nodes.
2.Key Management
In this module, we develop the Key management. Packet Type denotes the
function of the packet. Timestamps provide uniqueness, allowing detection of
replayedpackets and providing a basis for non-repudiation ofpreviously sent packets.
SUPERMAN relies on the dynamic generation of keys toprovide secure
communication.The Diffie-Hellman key-exchange algorithm provides ameans of
generating symmetric keys dynamically and isused to generate the SK keys. SKb keys
can simply be generatedby means of random number generation or anequivalent
secure key generation service.
3.Secure Node-to-Node Keys
SKe keys are used to secure end-to-end communicationwith other nodes, with
one SKe key generated per node, forevery other node also authenticated with the
13
network. SKpkeys are used for point-to-point security and generated inthe same
manner as SKe keys.It is important that SKe and SKp keys are different, asthe network
needs to secure both the content of a packetand the route taken.
A KDF can be used to generate these two keys in conjunctionwith the result of the
Diffie-Hellman algorithm,requiring a DKSp/DKSpriv pair, to minimise the cost of
securityon the network and reduce the key re-use and, inturn the lifetime of each
key.These keys are generated when nodes receive DKSp’sfrom other SUPERMAN
nodes.
4.Storage
SUPERMAN stores keys in each node’s security table. Thesecurity table
contains the security credentials of nodeswith which the node has previously directly
communicated. This table has n entries, wheren is the number of nodes that the node
in question has directlycommunicated with. Table has exchanged credentialswith two
other nodes, X and Y.The shared symmetric broadcast key (SKb) has two
derivedforms, the SKbe and SKbp. These are stored in the localsecurity table as a
separate broadcast address.
5.Communication Security
Once a node has joined the network, it may engage in securecommunication
with other nodes. Secure communicationunder SUPERMAN provides two types of
security;end-to-end and point-to-point.End-to-end security provides security services
betweensource and destination nodes by using their shared SKe.Confidentiality and
integrity are provided using an appropriatecryptographic algorithm, which is used to
generatean encrypted payload (EP).When protected, data is propagated over multiple
hops, itis authenticated at each hop. This is achieved using a hashingalgorithm, such as
HMAC. This is applied to the entirepacket to provide point-to-point integrity.
4.4 Data Dictionaries
Column name Datatype Constraint Description
Id Integer Primary Key Specifies ID
User name Varchar Not null Specifies user name

Password Varchar Not null Specifies password
Email Varchar Not null Specifies email
Phone number Varchar Not null Specifies phone number
14
Ip address Varchar Not null Specifies ipaddress
Mac address Varchar Not null Specifies mac address
Table 4.4.1: Data table for user details

Nodenum Varchar Not null Specifies nodenum
Attack Varchar Not null Specifies attack
Distance Varchar Not null Specifies distance
ip address Varchar Not null Specifies ip address
Mac address Varchar Not null Specifie mac address
Table 4.4.2: Data table of node details
Source Varchar Not null Specifies source
Key Varchar Not null Specifies key
Route path Varchar Not null Specifies route path
Destination Varchar Not null Specifies destination
Timestamp Varchar Not null Specifies timestamp
Timestamp Varchar Not null Specifies timestamp
Table 4.4.3: Data table for path details
Column name Data type Constraint Description
Source Varchar Not null Specifies source
Destination Varchar Not null Specifies destination
Attack node Varchar Not null Specifies attack node
Table 4.4.4: Data table of attack details
4.5 UML Diagrams
The unified modeling language allows the software engineer to express an analysis
model using the modeling notation that is governed by a set of syntactic semantic and
pragmatic rules.A UML system is represented using five different views that describe
the system from distinctly different perspective. UML is specifically constructed
through two different domains.UML Analysis modeling, this focuses on the user
model and structural model views of the system.UML design modeling, which focuses
on the behavioral modeling, implementation modeling and environmental model
views.
These are divided into the following types.
 Use case diagram
 Class diagram
15
 Sequence diagram
 Collaboration diagram
 Activity diagram
4.5.1 Use case Diagram

Use Case diagrams identify the functionality provided by the system (use
cases), the users who interact with the system (actors), and the association between the
users and the functionality. Use Cases are used in the Analysis phase of software
development to articulate the high-level requirements of the system. The primary goals
of Use Case diagrams include:
 Providing a high-level view of what the system does.
 Identifying the users ("actors") of the system.
 Determining areas needing human-computer interfaces.
Graphical Notation: The basic components of Use Case diagrams are the Actor, the
Use Case, and the Association.
Actor An Actor, as mentioned, is a user of the

system, and is depicted using a stick
figure. The role of the user is written
beneath the icon. Actors are not limited
Actor Role Name
to humans. If a system communicates
with another application, and expects
input or delivers output, then that
application can also be considered an
actor.
Use Case A Use Case is functionality provided by

the system, Use Cases are depicted with
an ellipse. The name of the use case is
Use Case Name
written within the ellipse.
Directed These Associations are used to link

Associatio Actors with Use Cases, and indicate that
n an Actor participates in the Use Case in
16
some form.
Behind each Use Case is a series of actions to achieve the proper functionality,
as well as alternate paths for instances where validation fails, or errors occur. These
actions can be further defined in a Use Case description. Because this is not addressed
in UML, there are no standards for Use Case descriptions. However, there are some
common templates can follow, and whole books on the subject writing of Use Case
description.
login
superman
upload file and encrypt data
source
choose destination
find shortest path

destination
checking attack
received file
Fig 4.5.1: Use case diagram for security using pre existing routing for MANET
Description
The above diagram is usecase diagram here it describes the relationship
between usecases and actors.in the above diagrame source and destination are
actors.Here first user should be registered after that user login to the systems and
choose the file to destination .encrypt the file send to destination.and here superman
checks the attacks and finds shortest path for destination.
Use case Templates
17
Usecase name Login
Participating actors User
Flow of Events 1. The user login into the system

2. the user logins in the system by using entering
the details .
3. user details stores in database.
Entry condition Source should login into the system

Exit condition Successfully registered.
Table 4.5.1.1: Use case template for login
Usecase name Upload file and encrypt
Participating actors Source
Flow of Events 1.first user will be registered.after it has to login
into the system.
2.then user will be upload the file for sharing file
to destination.so that file encrypted by the user.
Entry condition Source should be choose the file.
Exit condition Successfully file uploads and encrypt.
Table 4.5.1.2: Use case template for upload file and encrypt
Usecase name Choose destination
Flow of Events 1.After encrypting data source will be choose the
destination.
2.So source will sends the data to destination
Entry condition system should choose the destination
Exit condition Successfully chosed destination.
18
Table 4.5.1.3: Use case template for choose destination
Usecase name Find shortest path
Flow of Events 1.After chooseing Table
destination source will be sends the file to 4.5.1.4:
destination. Use case
2.The system will finds

the shortest path to destination.
3.By using that shortest
path data will be sends to the destination
Entry condition The system should performe sending data after it
finds shortest path.
Exit condition Successfully finds shortest path.
template for find shortest path
Usecase name Receive file

Participating Destination
actors
Flow of Events 1.after sending data to destination.the destination
receives the file.
2.in that processes any attack will occurs in that
path.security using pre existing routing for mobile
adhoc network will be recovers the path and data
receives succusfully
Entry ondition Sytem should find shorest path.
Exit condition Successfully received file.
Table 4.5.1.5: Use case template for receive file

4.5.2 Class Diagram
Class diagrams identify the class structure of a system, including the properties
and methods of each class. Also depicted are the various relationships that can exist
between classes, such as an inheritance relationship. Part of the popularity of Class
diagrams stems from the fact that many CASE tools, such as Rational XDE, will auto-
generate code in a variety of languages, these tools can synchronize models and code,
reducing the workload, and can also generate Class diagrams from object-oriented
code.
19
Graphical Notation: The elements on a Class diagram are classes and the
relationships between them.
Class Classes are the building blocks in object-

oriented programming. A Class is depicted
using a rectangle divided into three sections.
The top section is the name of the Class. The
middle section defines the properties of the
Class. The bottom section lists the methods of
the class.
Associatio An Association is a generic relationship

n between two classes, and is modeled by a line
connecting the two classes. This line can be
qualified with the type of relationship, and can
also feature multiplicity rule (e.g. one-to-one,
one-to-many, many-to-many) for the
relationship.
source
registration()
login()
source ip() destination
upload file()
source ip
encrypt data()
destination ip
choose destination()
no of packets
find shortestpath()
1 1 data packets
no of nodes
no data packets
receive file()
check for attack()
superman solve issues()
data sent()
Fig 4.5.2: class diagram for security using pre existing routing for MANET
20
Description
In the above class diagram describes the relationship between
source,destination . The source will performes all the tasks.it will sends data to the
destination.destination will receives successfully.
4.5.3 Sequence diagram

Sequence diagrams document the interactions between classes to achieve a
result, such as a use case. Because UML is designed for object-oriented programming,
these communications between classes are known as messages. The Sequence diagram
lists objects horizontally, and time vertically, and models these messages over time.
Graphical Notation in a Sequence diagram, classes and actors are listed as columns,
with vertical lifelines indicating the lifetime of the object over time.
Object Objects are instances of classes, and are

arranged horizontally. The pictorial
representation for an Object is a class (a
rectangle) with the name prefixed by the
object name (optional) and a semi-colon.
Lifeline The Lifeline identifies the existence of the
object over time. The notation 2for a
Lifeline is a vertical dotted line extending
from an object.
Activation Activations, modelled as rectangular
boxes on the lifeline, indicate when the
object is performing an action.
Message Messages, modeled as horizontal arrows

between Activations, indicate the
communications between objects.
21
source destination
upload file
shortest oath selection
file send
checking attack resolving
file received
Fig 4.5.3: sequence diagram for security using pre existing routing for MANET
Description
In the above sequence diagram the source will be login into the system and
uploads file and finds shortest path after that it will sends the data to destination.here
destination will be checks the stacking after that it will be receives file.
4.5.4 Collaboration Diagram
Like the other Behavioral diagrams, Collaboration diagrams model the
interactions between objects. This type of diagram is a cross between an object
diagram and a sequence diagram. Unlike the Sequence diagram, which models the
interaction in a column and row type format, the Collaboration diagram uses the free-
form arrangement of objects as found in an Object diagram. This makes it easier to see
all interactions involving a particular object.
Graphical Notation
Object Objects are instances of classes, and are one of the entity
types that can be involved in communications. An Object
is drawn as a rectangular box, with the class name inside
prefixed with the object name (optional) and a semi-
colon.
22
Actor Actors can also communicate with Objects, so they too

can be listed on Collaboration diagrams. An Actor is
depicted by a stick figure.
Messag Messages, modeled as arrows between objects, and

e labeled with an ordering number. Indicate the
communications between objects.
1: upload file
2: shortest path selection
3: file send
source destination
4: checking attacks and resolving

5: file received
Fig4.5.4:collaboration diagram for security using pre existing routing for

MANET
Description
In the above Collaboration diagram, the source uploads the file. and finds
shortest path selection and sends the file to destination .checking the attack and
resolving.finally destination will receives the file.
5.5 Activity Diagram
This shows the flow of events within the system. The activities that occur within a
use case or within an objects behavior typically occur in a sequence .an activity
diagram is designed to be simplified look at what happens during an operations or a
process.
Each activity is represented by a rounded rectangle the processing within an activity
goes to compilation and then an automatic transmission to the next activity occurs. An
arrow represents the transition from one activity to the next. An activity diagram
describes a system in terms of activities. Activities are the state that represents the
execution of a set of operations. These are similar to flow chart diagram and dataflow.
23
Starting point This is starting point of process.
Action An action represents the execution of an

atomic action, typically the invocation of an
operation. An action is a simple action with an
entry action whose only exit transition is
triggered by the implicit event of completing
the execution of the entry action.
24
Activity1
25
End point An end point represents the last or "final"
activity of the enclosing composite activity.
There may be more than one final point at
any level signifying that the composite
activity can end in different ways or
conditions. When a final activity is reached
and there are no other enclosing activity it
means that the entire activity has completed
its transitions and no more transitions can
occur.
Decision An activity diagram expresses decision

when guard conditions are used to indicate
different possible transitions that depend on
Boolean conditions of the owning object.
Synchronization The fork will divide the state into multiple

bar states and the join will merge the multiple
states into single states.
Swim lane The swim lane will divide the business

objects into meaning full order.
Transition A transition is a directed relationship

between a source state vertex and a target
state vertex. It may be part of a compound
transition, which takes the static machine
from one static configuration to another,
representing the complete response of the
static machine to a particular event instance.
26
source login
check no unotherized
yes user
upload file
encrypt file
choose
destination
find shortest
path and send
no superman solv e in the

check attack
issue in attack node
yes
destination
4.5.5: activity diagram for sec urity using pre existing routing for MANET
Description
In the above activity diagram , the source uploads the file and finds
shortest path selection and sends the file to destination .checking the attack and
resolving.finally destination will receives the file.
5. TECHNOLOGY DESCRIPTION
5.1 Introduction to Java
Java Technology
Java technology is both a programming language and a platform.
The Java Programming Language
The Java programming language is a high-level language that can be
characterized by all of the following buzzwords:
 Simple
 Architecture neutral
 Object oriented
 Portable
27
 Distributed
 High performance
 Interpreted
 Multithreaded
 Robust
 Dynamic
 Secure
With most programming languages, you either compile or interpret a program
so that you can run it on your computer. The Java programming language is unusual in
that a program is both compiled and interpreted. With the compiler, first you translate
a program into an intermediate language called Java byte codes —the platform-
independent codes interpreted by the interpreter on the Java platform. The interpreter
parses and runs each Java byte code instruction on the computer. Compilation happens
just once; interpretation occurs each time the program is executed. The following
figure illustrates how this works.
Fig: Generating class file
User can think of Java byte codes as the machine code instructions for the Java
Virtual Machine (Java VM). Every Java interpreter, whether it’s a development tool or
a Web browser that can run applets, is an implementation of the Java VM. Java byte
codes help make “write once, run anywhere” possible. User can compile your program
into byte codes on any platform that has a Java compiler. The byte codes can then be
run on any implementation of the Java VM. That means that as long as a computer has
a Java VM, the same program written in the Java programming language can run on
Windows 2000, a Solaris workstation, or on an iMac.
28
Fig: Compiling java program

The Java Platform
A platform is the hardware or software environment in which a program runs.
We’ve already mentioned some of the most popular platforms like Windows 2000,
Linux, Solaris, and MacOS. Most platforms can be described as a combination of the
operating system and hardware. The Java platform differs from most other platforms
in that it’s a software-only platform that runs on top of other hardware-based
platforms.
The Java platform has two components:
 The Java Virtual Machine (Java VM)
 The Java Application Programming Interface (Java API)
You’ve already been introduced to the Java VM. It’s the base for the Java platform
and is ported onto various hardware-based platforms.
The Java API is a large collection of ready-made software components that provide
many useful capabilities, such as graphical user interface (GUI) widgets. The Java API
is grouped into libraries of related classes and interfaces; these libraries are known as
packages. The next section, What Can Java Technology Do? Highlights what
functionality some of the packages in the Java API provide.
The following figure depicts a program that’s running on the Java platform. As the
figure shows, the Java API and the virtual machine insulate the program from the
hardware.
Fig: Java API
29
Native code is code that after you compile it, the compiled code runs on a specific
hardware platform. As a platform-independent environment, the Java platform can be
a bit slower than native code. However, smart compilers, well-tuned interpreters, and
just-in-time byte code compilers can bring performance close to that of native code
without threatening portability.
What Can Java Technology Do?

The most common types of programs written in the Java programming
language are applets and applications. An applet is a program that adheres to certain
conventions that allow it to run within a Java-enabled browser.
However, the Java programming language is not just for writing cute, entertaining
applets for the Web. The general-purpose, high-level Java programming language is
also a powerful software platform. Using the generous API, you can write many types
of programs.
An application is a standalone program that runs directly on the Java platform. A
special kind of application known as a server serves and supports clients on a network.
Examples of servers are Web servers, proxy servers, mail servers, and print servers.
Another specialized program is a servlet. Java Servlets are a popular choice for
building interactive web applications, replacing the use of CGI scripts. Servlets are
similar to applets in that they are runtime extensions of applications. Instead of
working in browsers, though, servlets run within Java Web servers, configuring or
tailoring the server.
Every full implementation of the Java platform gives you the following features:
 The essentials: Objects, strings, threads, numbers, input and output, data
structures, system properties, date and time, and so on.
 Applets: The set of conventions used by applets.
 Networking: URLs, TCP (Transmission Control Protocol), UDP (User Data
gram Protocol) sockets, and IP (Internet Protocol) addresses.
 Internationalization: Help for writing programs that can be localized for users
worldwide. Programs can automatically adapt to specific locales and be
displayed in the appropriate language.
 Security: Both low level and high level, including electronic signatures, public
and private key management, access control, and certificates.
30
 Software components: Known as JavaBeansTM, can plug into existing
component architectures.
 Object serialization: Allows lightweight persistence and communication via
Remote Method Invocation (RMI).
 Java Database Connectivity (JDBCTM): Provides uniform access to a wide
range of relational databases.
The Java platform also has APIs for 2D and 3D graphics, accessibility, servers,
collaboration, telephony, speech, animation, and more. The following figure depicts
what is included in the Java 2 SDK.
Fig: Java Database Connectivity

How Will Java Technology Change?
Java is likely to make your programs better and requires less effort than other
languages. We believe that Java technology will help us do the following:
 Get started quickly: Although the Java programming language is a powerful

object-oriented language, it’s easy to learn, especially for programmers already
familiar with C or C++.
 Write less code: Comparisons of program metrics (class counts, method
counts, and so on) suggest that a program written in the Java programming
language can be four times smaller than the same program in C++.
 Write better code: The Java programming language encourages good coding
practices, and its garbage collection helps you avoid memory leaks. Its object
orientation, its JavaBeans component architecture, and its wide-ranging, easily
extendible API let you reuse other people’s tested code and introduce fewer
bugs.
31
 Develop programs more quickly: Your development time may be as much as
twice as fast versus writing the same program in C++. Why? You write fewer
lines of code and it is a simpler programming language than C++.
 Avoid platform dependencies with 100% Pure Java: You can keep your
program portable by avoiding the use of libraries written in other languages.
The 100% Pure JavaTMProduct Certification Program has a repository of
historical process manuals, white papers, brochures, and similar materials
online.
 Write once, run anywhere: Because 100% Pure Java programs are compiled
into machine-independent byte codes, they run consistently on any Java
platform.
 Distribute software more easily: You can upgrade applets easily from a
central server. Applets take advantage of the feature of allowing new classes to
be loaded “on the fly,” without recompiling the entire program.
ODBC
Microsoft Open Database Connectivity (ODBC) is a standard programming
interface for application developers and database systems providers. Before ODBC
became a de facto standard for Windows programs to interface with database systems,
programmers had to use proprietary languages for each database they wanted to
connect to. Now, ODBC has made the choice of the database system almost irrelevant
from a coding perspective, which is as it should be. Application developers have much
more important things to worry about than the syntax that is needed to port their
program from one database to another when business needs suddenly change.
Through the ODBC Administrator in Control Panel, you can specify the
particular database that is associated with a data source that an ODBC application
program is written to use. Think of an ODBC data source as a door with a name on it.
Each door will lead you to a particular database. For example, the data source named
Sales Figures might be a SQL Server database, whereas the Accounts Payable data
source could refer to an Access database. The physical database referred to by a data
source can reside anywhere on the LAN.
The ODBC system files are not installed on your system by Windows 95. Rather, they
are installed when your setup a separate database application, such as SQL Server
Client or Visual Basic 4.0. When the ODBC icon is installed in Control Panel, it uses a
file called ODBCINST.DLL. It is also possible to administer your ODBC data sources
32
through a stand-alone program called ODBCADM.EXE. There is a 16-bit and a 32-bit
version of this program and each maintains a separate list of ODBC data sources.
From a programming perspective, the beauty of ODBC is that the application
can be written to use the same set of function calls to interface with any data source,
regardless of the database vendor. The source code of the application doesn’t change
whether it talks to Oracle or SQL Server. We only mention these two as an example.
There are ODBC drivers available for several dozen popular database systems. Even
Excel spreadsheets and plain text files can be turned into data sources. The operating
system uses the Registry information written by ODBC Administrator to determine
which low-level ODBC drivers are needed to talk to the data source (such as the
interface to Oracle or SQL Server). The loading of the ODBC drivers is transparent to
the ODBC application program. In a client/server environment, the ODBC API even
handles many of the network issues for the application programmer.
The advantages of this scheme are so numerous that you are probably thinking
there must be some catch. The only disadvantage of ODBC is that it isn’t as efficient
as talking directly to the native database interface. ODBC has had many detractors
make the charge that it is too slow. Microsoft has always claimed that the critical
factor in performance is the quality of the driver software that is used. In our humble
opinion, this is true. The availability of good ODBC drivers has improved a great deal
recently. And anyway, the criticism about performance is somewhat analogous to
those who said that compilers would never match the speed of pure assembly
language. Maybe not, but the compiler (or ODBC) gives you the opportunity to write
cleaner programs, which means you finish sooner. Meanwhile, computers get faster
every year.
JDBC
In an effort to set an independent database standard API for Java; Sun
Microsystems developed Java Database Connectivity, or JDBC. JDBC offers a generic
SQL database access mechanism that provides a consistent interface to a variety of
RDBMSs. This consistent interface is achieved through the use of “plug-in” database
connectivity modules, or drivers. If a database vendor wishes to have JDBC support,
he or she must provide the driver for each platform that the database and Java run on.
To gain a wider acceptance of JDBC, Sun based JDBC’s framework on
ODBC. As you discovered earlier in this chapter, ODBC has widespread support on a
33
variety of platforms. Basing JDBC on ODBC will allow vendors to bring JDBC
drivers to market much faster than developing a completely new connectivity solution.
JDBC was announced in March of 1996. It was released for a 90 days public
review that ended June 8, 1996. Because of user input, the final JDBC v1.0
specification was released soon after.
The remainder of this section will cover enough information about JDBC for
you to know what it is about and how to use it effectively. This is by no means a
complete overview of JDBC. That would fill an entire book.
JDBC Goals
Few software packages are designed without goals in mind. JDBC is one that, because
of its many goals, drove the development of the API. These goals, in conjunction with
early reviewer feedback, have finalized the JDBC class library into a solid framework
for building database applications in Java.
The goals that were set for JDBC are important. They will give you some insight
as to why certain classes and functionalities behave the way they do. The eight design
goals for JDBC are as follows:
1. SQL Level API

The designers felt that their main goal was to define a SQL interface for Java.
Although not the lowest database interface level possible, it is at a low enough
level for higher-level tools and APIs to be created. Conversely, it is at a high
enough level for application programmers to use it confidently. Attaining this goal
allows for future tool vendors to “generate” JDBC code and to hide many of
JDBC’s complexities from the end user.
2. SQL Conformance
SQL syntax varies as you move from database vendor to database vendor. In an
effort to support a wide variety of vendors, JDBC will allow any query statement
to be passed through it to the underlying database driver. This allows the
connectivity module to handle non-standard functionality in a manner that is
suitable for its users.
3. JDBC must be implemental on top of common database interfaces
34
The JDBC SQL API must “sit” on top of other common SQL level APIs. This
goal allows JDBC to use existing ODBC level drivers by the use of a software
interface. This interface would translate JDBC calls to ODBC and vice versa.
4. Provide a Java interface that is consistent with the rest of the Java system
Because of Java’s acceptance in the user community thus far, the designers feel
that
they should not stray from the current design of the core Java system.
5. Keep it simple
This goal probably appears in all software design goal listings. JDBC is no
exception. Sun felt that the design of JDBC should be very simple, allowing for
only one method of completing a task per mechanism. Allowing duplicate
functionality only serves to confuse the users of the API.
6. Use strong, static typing wherever possible
Strong typing allows for more error checking to be done at compile time; also, less
error appear at runtime.
7. Keep the common cases simple
Because more often than not, the usual SQL calls used by the programmer are
simple SELECT’s, INSERT’s, DELETE’s and UPDATE’s, these queries should
be simple to perform with JDBC. However, more complex SQL statements should
also be possible.
Finally, we decided to proceed the implementation using Java Networking.
And for dynamically updating the cache table we go for MSAccess database.
Java ha two things: a programming language and a platform.
Java is a high-level programming language that is all of the

following
Simple Architecture-neutral
Object-oriented Portable
Distributed High-performance
Interpreted multithreaded
Robust Dynamic
Secure
35
Java is also unusual in that each Java program is both compiled and
interpreted. With a compile you translate a Java program into an
intermediate language called Java byte codes the platform-independent code
instruction is passed and run on the computer.
Compilation happens just once; interpretation occurs each time the program
is executed. The figure illustrates how this works.
JavaProgram Interpreter
Compilers My Program
Fig: Process of Compilation and Interpretation
You can think of Java byte codes as the machine code instructions for the
Java Virtual Machine (Java VM). Every Java interpreter, whether it’s a Java
development tool or a Web browser that can run Java applets, is an
implementation of the Java VM. The Java VM can also be implemented in
hardware.
Java byte codes help make “write once, run anywhere” possible. You can
compile your Java program into byte codes on my platform that has a Java
compiler. The byte codes can then be run any implementation of the Java
VM. For example, the same Java program can run Windows NT, Solaris, and
Macintosh.
 JFree Chart
JFreeChart is a free 100% Java chart library that makes it easy for developers to
display professional quality charts in their applications. JFreeChart's extensive feature
set includes:
36
A consistent and well-documented API, supporting a wide range of chart types;
A flexible design that is easy to extend, and targets both server-side and client-side
applications;
Support for many output types, including Swing components, image files
(including PNG and JPEG), and vector graphics file formats (including PDF, EPS and
SVG);
JFreeChart is "open source" or, more specifically, free software. It is distributed under
the terms of the GNU Lesser General Public License(LGPL), which permits use in
proprietary applications.
1. Map Visualizations
Charts showing values that relate to geographical areas. Some examples
include: (a) population density in each state of the United States, (b) income per capita
for each country in Europe, (c) life expectancy in each country of the world. The tasks
in this project include:
Sourcing freely redistributable vector outlines for the countries of the world,
states/provinces in particular countries (USA in particular, but also other areas);
Creating an appropriate dataset interface (plus default implementation), a
rendered, and integrating this with the existing XYPlot class in JFreeChart;
Testing, documenting, testing some more, documenting some more.
2. Time Series Chart Interactivity

Implement a new (to JFreeChart) feature for interactive time series charts --- to
display a separate control that shows a small version of ALL the time series data, with
a sliding "view" rectangle that allows you to select the subset of the time series data to
display in the main chart.
3. Dashboards
There is currently a lot of interest in dashboard displays. Create a flexible
dashboard mechanism that supports a subset of JFreeChart chart types (dials, pies,
thermometers, bars, and lines/time series) that can be delivered easily via both Java
web Start and an applet.
37
4. Property Editors
The property editor mechanism in JFreeChart only handles a small subset of the
properties that can be set for charts. Extend (or re implement) this mechanism to
provide greater end-user control over the appearance of the charts.
5.2 J2ME (Java 2 Micro edition):-
Sun Microsystems defines J2ME as "a highly optimized Java run-time
environment targeting a wide range of consumer products, including pagers, cellular
phones, screen-phones, digital set-top boxes and car navigation systems." Announced
in June 1999 at the JavaOne Developer Conference, J2ME brings the cross-platform
functionality of the Java language to smaller devices, allowing mobile wireless devices
to share applications. With J2ME, Sun has adapted the Java platform for consumer
products that incorporate or are based on small computing devices.
1.General J2ME architecture
Fig: General J2ME architecture

J2ME uses configurations and profiles to customize the Java Runtime
Environment (JRE). As a complete JRE, J2ME is comprised of a configuration, which
determines the JVM used, and a profile, which defines the application by adding
domain-specific classes. The configuration defines the basic run-time environment as a
set of core classes and a specific JVM that run on specific types of devices. We'll
discuss configurations in detail in the profile defines the application; specifically, it
adds domain-specific classes to the J2ME configuration to define certain uses for
devices. We'll cover profiles in depth in the following graphic depicts the relationship
between the different virtual machines, configurations, and profiles. It also draws a
38
parallel with the J2SE API and its Java virtual machine. While the J2SE virtual
machine is generally referred to as a JVM, the J2ME virtual machines, KVM and
CVM, are subsets of JVM. Both KVM and CVM can be thought of as a kind of Java
virtual machine -- it's just that they are shrunken versions of the J2SE JVM and are
specific to J2ME.
2. Developing J2ME applications
Introduction In this section, we will go over some considerations you need to
keep in mind when developing applications for smaller devices. We'll take a look at
the way the compiler is invoked when using J2SE to compile J2ME applications.
Finally, we'll explore packaging and deployment and the role pre-verification plays in
this process.
3. Design considerations for small devices
Developing applications for small devices requires you to keep certain
strategies in mind during the design phase. It is best to strategically design an
application for a small device before you begin coding. Correcting the code because
you failed to consider all of the "gotchas" before developing the application can be a
painful process. Here are some design strategies to consider:
* Keep it simple. Remove unnecessary features, possibly making those features a
separate, secondary application.
* Smaller is better. This consideration should be a "no brainer" for all developers.
Smaller applications use less memory on the device and require shorter installation
times. Consider packaging your Java applications as compressed Java Archive (jar)
files.
* Minimize run-time memory use. To minimize the amount of memory used at run
time, use scalar types in place of object types. Also, do not depend on the garbage
collector. You should manage the memory efficiently yourself by setting object
references to null when you are finished with them. Another way to reduce run-time
memory is to use lazy instantiation, only allocating objects on an as-needed basis.
Other ways of reducing overall and peak memory use on small devices are to release
resources quickly, reuse objects, and avoid exceptions.
4. Configurations overview
39
The configuration defines the basic run-time environment as a set of core classes and a
specific JVM that run on specific types of devices. Currently, two configurations exist
for J2ME, though others may be defined in the future:
* Connected Limited Device Configuration (CLDC) is used specifically with the
KVM for 16-bit or 32-bit devices with limited amounts of memory. This is the
configuration (and the virtual machine) used for developing small J2ME applications.
Its size limitations make CLDC more interesting and challenging (from a development
point of view) than CDC. CLDC is also the configuration that we will use for
developing our drawing tool application. An example of a small wireless device
running small applications is a Palm hand-held computer.
* Connected Device Configuration (CDC) is used with the C virtual machine
(CVM) and is used for 32-bit architectures requiring more than 2 MB of memory. An
example of such a device is a Net TV box.
5. J2ME profiles
What is a J2ME profile?
As we mentioned earlier in this tutorial, a profile defines the type of device
supported. The Mobile Information Device Profile (MIDP), for example, defines
classes for cellular phones. It adds domain-specific classes to the J2ME configuration
to define uses for similar devices. Two profiles have been defined for J2ME and are
built upon CLDC: KJava and MIDP. Both KJava and MIDP are associated with
CLDC and smaller devices. Profiles are built on top of configurations. Because
profiles are specific to the size of the device (amount of memory) on which an
application runs, certain profiles are associated with certain configurations.
A skeleton profile upon which you can create your own profile, the Foundation
Profile, is available for CDC.
Profile 1: KJava
KJava is Sun's proprietary profile and contains the KJava API. The KJava
profile is built on top of the CLDC configuration. The KJava virtual machine, KVM,
accepts the same byte codes and class file format as the classic J2SE virtual machine.
KJava contains a Sun-specific API that runs on the Palm OS. The KJava API has a
great deal in common with the J2SE Abstract Windowing Toolkit (AWT). However,
because it is not a standard J2ME package, its main package is com.sun.kjava. We'll
40
learn more about the KJava API later in this tutorial when we develop some sample
applications.
Profile 2: MIDP
MIDP is geared toward mobile devices such as cellular phones and pagers. The
MIDP, like KJava, is built upon CLDC and provides a standard run-time environment
that allows new applications and services to be deployed dynamically on end user
devices. MIDP is a common, industry-standard profile for mobile devices that is not
dependent on a specific vendor. It is a complete and supported foundation for mobile
application
development. MIDP contains the following packages, the first three of which are core
CLDC packages, plus three MIDP-specific packages.
* java.lang
* java.io
* java.util
* javax.microedition.io
* javax.microedition.lcdui
* javax.microedition.midlet
* javax.microedition.rms
41
6. SAMPLE CODE
Upload code for login page
package supermen_security;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.swing.JOptionPane;
/**
*
* @author welcome
*/
public class login extends javax.swing.JFrame {
public static String susernames,mackadress,ipaddress;
/**
* Creates new form login
*/
public login() {
initComponents()}
/**
* This method is called from within the constructor to initialize the form.
* WARNING: Do NOT modify this code. The content of this method is always
* regenerated by the Form Editor.
*/
@SuppressWarnings("unchecked")
// <editor-fold defaultstate="collapsed" desc="Generated Code">
private void initComponents() {
jLabel1 = new javax.swing.JLabel();
jTextField1 = new javax.swing.JTextField();
42
jButton1 = new javax.swing.JButton();
jPasswordField1 = new javax.swing.JPasswordField();
setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE)
getContentPane().setLayout(new org.netbeans.lib.awtextra.AbsoluteLayout());
jLabel1.setFont(new java.awt.Font("Batang", 1, 18)); // NOI18N
jLabel1.setText("LOGIN");
getContentPane().add(jLabel1,new
org.netbeans.lib.awtextra.AbsoluteConstraints(180, 24, 85, 22));
jLabel2.setFont(new java.awt.Font("Vrinda", 2, 18)); // NOI18N
jLabel2.setText("username");
getContentPane().add(jLabel2,new org.netbeans.lib.awtextra.AbsoluteConstraints(30,
80, 130, 23));
jLabel3.setText("Password");
160, 130, 28));
getContentPane().add(jTextField1,new
jButton1.setFont(new java.awt.Font("Bell MT", 1, 18)); // NOI18N
jButton1.setText("Login");
jButton1.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jButton1ActionPerformed(evt); });
getContentPane().add(jButton1,new org.netbeans.lib.awtextra.AbsoluteConstraints(30,
250, 110, 30));
jButton2.setText("Registration");
jButton2ActionPerformed(evt); }});
getContentPane().add(jButton2,new
43
jButton3.setText("Reset");
jButton3ActionPerformed(evt);} });
jPasswordField1.addActionListener(new java.awt.event.ActionListener() {
jPasswordField1ActionPerformed(evt); }});
getContentPane().add(jPasswordField1,new
jLabel4.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/imagess/bbb.jpg"))); // NOI18N
jLabel4.setText("jLabel4");
4, 470, 300));
pack();
}// </editor-fold>
private void jButton1ActionPerformed(java.awt.event.ActionEvent evt) {
// TODO add your handling code here:
String username=jTextField1.getText();
String password=jPasswordField1.getText();
String Statuss="Yes";
if(username.equals("") || (password.equals("")))
{
JOptionPane.showMessageDialog(null, "Please Enter your Username and Password
");
}
else{
try {
Connection conn = dbcon.getConne();
Statement st = conn.createStatement();
44
ResultSet ss = st.executeQuery("select * from userreg where username='" +
username + "' and password='"+password+"' ");
if (ss.next()) {
susernames=ss.getString("username");
mackadress=ss.getString("idpadd");
mackadress=ss.getString("mackadd");
Statement st1 = conn.createStatement();
ResultSet ss1 = st1.executeQuery("select * from nodes where attack='" + Statuss + "'
");
if (ss1.next()) {
String attt=ss1.getString("nodenum");
Statement st2 =conn.createStatement();
int i = st2.executeUpdate("update nodes set attack='No' where nodenum='" + attt +
"'");
if (i != 0) {
new source().setVisible(true);
}}
else{
new source().setVisible(true);}}
else{
new registra().setVisible(true);
}
} catch (SQLException ex) {
Logger.getLogger(dbcon.class.getName()).log(Level.SEVERE, null, ex);}}}
new registra().setVisible(true);}
jTextField1.setText("");
jPasswordField1.setText("")}
private void jPasswordField1ActionPerformed(java.awt.event.ActionEvent evt) {
// TODO add your handling code here:}
/**
45
* @param args the command line arguments
*/
public static void main(String args[]) {
/* Set the Nimbus look and feel */
//<editor-fold defaultstate="collapsed" desc=" Look and feel setting code (optional) ">
/* If Nimbus (introduced in Java SE 6) is not available, stay with the default look and
feel.Fordetailssee
http://download.oracle.com/javase/tutorial/uiswing/lookandfeel/plaf.html
*/
try {
for(javax.swing.UIManager.LookAndFeelInfoinfo :
javax.swing.UIManager.getInstalledLookAndFeels()) {
if ("Nimbus".equals(info.getName())) {
javax.swing.UIManager.setLookAndFeel(info.getClassName());
break;
}
}
} catch (ClassNotFoundException ex) {
java.util.logging.Logger.getLogger(login.class.getName()).log(java.util.logging.Level.
SEVERE, null, ex);
} catch (InstantiationException ex) {
SEVERE, null, ex);
} catch (IllegalAccessException ex) {
SEVERE, null, ex);
} catch (javax.swing.UnsupportedLookAndFeelException ex)
SEVERE, null, ex);
}
//</editor-fold>
/* Create and display the form */
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
46
new login().setVisible(true);}});}
// Variables declaration - do not modify
private javax.swing.JButton jButton1;
private javax.swing.JLabel jLabel1;
private javax.swing.JPasswordField jPasswordField1;
private javax.swing.JTextField jTextField1;
// End of variables declaration
}
Source code for registration
package supermen_security;
import java.net.InetAddress;
import java.net.NetworkInterface;
import java.net.SocketException;
import java.net.UnknownHostException;
import java.sql.Connection;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.swing.JFrame;
import javax.swing.JOptionPane;
/**
*
* @author welcome
*/
public class registra extends javax.swing.JFrame {
* Creates new form registra
*/
public registra() {
47
initComponents();
}
* This method is called from within the constructor to initialize the form.
* WARNING: Do NOT modify this code. The content of this method is always
* regenerated by the Form Editor.
@SuppressWarnings("unchecked")
// <editor-fold defaultstate="collapsed" desc="Generated Code">
private void initComponents() {

username = new javax.swing.JTextField();
password = new javax.swing.JPasswordField();
emailid = new javax.swing.JTextField();
mobilee = new javax.swing.JTextField();
jLabel6.setIcon(new
setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);
getContentPane().setLayout(new org.netbeans.lib.awtextra.AbsoluteLayout());
jLabel1.setFont(new java.awt.Font("Batang", 1, 18)); // NOI18N
jLabel1.setText("REGISTRATION ");
30, 198, 26));
48
jLabel2.setText("Username");
getContentPane().add(jLabel2, new org.netbeans.lib.awtextra.AbsoluteConstraints(29,
105, 97, 23));
jLabel3.setText("Password");
150, 97, 30));
jLabel4.setText("Emailid");
210, 90, 30));
jLabel5.setText("Mobilenumber");
260, 120, 30));
getContentPane().add(username,new
org.netbeans.lib.awtextra.AbsoluteConstraints(250, 100, 150, -1));
getContentPane().add(password,new
getContentPane().add(emailid,new org.netbeans.lib.awtextra.AbsoluteConstraints(250,
200, 150, -1));
getContentPane().add(mobilee,new
jButton1.setText("Submit");
jButton1ActionPerformed(evt);}});
getContentPane().add(jButton1,new org.netbeans.lib.awtextra.AbsoluteConstraints(60,
330, 120, 30));
jButton2.setText("Reset");
49
jButton2ActionPerformed(evt);
}
});
jButton3.setText("Login");
jButton3ActionPerformed(evt);
}
});
jLabel7.setIcon(new
4, 510, 470));
pack();
}// </editor-fold>
String name=username.getText();
String passwordd=password.getText();
String emailidd=emailid.getText();
String mobileee=mobilee.getText()
try {
InetAddress ipAddr = InetAddress.getLocalHost();
System.out.println(ipAddr.getHostAddress());
NetworkInterface nwi = NetworkInterface.getByInetAddress(ipAddr);
byte[] mac = nwi.getHardwareAddress();
System.out.print("Current MAC address : ");
StringBuilder sb = new StringBuilder()
50
for (int i = 0; i < mac.length; i++) {
sb.append(String.format("%02X%s", mac[i], (i < mac.length - 1) ? "-" : ""));
}
System.out.println(sb.toString());
Connection conn = dbcon.getConne();
Statement st = conn.createStatement();
int j;
JFrame frame = new JFrame();
Object ipadd = JOptionPane.showInputDialog(frame, "Enter IP-
Address:"+ipAddr.getHostAddress());
Object mack = JOptionPane.showInputDialog(frame, "Enter Mack
Address:"+sb.toString());
j = st.executeUpdate("insert into userreg

(username,password,emailid,phone,idpadd,mackadd)values ('" + name + "', '" +
passwordd + "', '" + emailidd + "', '" + mobileee + "', '" + ipadd + "','" + mack + "')");
JOptionPane.showMessageDialog(null, "Register Succesfully");
new login().setVisible(true);
} catch (SocketException ex) {
Logger.getLogger(registra.class.getName()).log(Level.SEVERE, null, ex);
} catch (UnknownHostException ex) {
Logger.getLogger(registra.class.getName()).log(Level.SEVERE, null, ex);
} catch (SQLException ex) {
Logger.getLogger(dbcon.class.getName()).log(Level.SEVERE, null, ex);
}
}
username.setText("");
password.setText("");
emailid.setText("");
mobilee.setText("");
}
51
new login().setVisible(true);
}
* @param args the command line arguments
*/
public static void main(String args[]) {
/* Set the Nimbus look and feel */
//<editor-fold defaultstate="collapsed" desc=" Look and feel setting code (optional) ">
/* If Nimbus (introduced in Java SE 6) is not available, stay with the default look and
feel.
* For details see http://download.oracle.com/javase/tutorial/uiswing/lookandfeel/plaf
try {
for (javax.swing.UIManager.LookAndFeelInfo info :
javax.swing.UIManager.getInstalledLookAndFeels()) {
if ("Nimbus".equals(info.getName())) {
javax.swing.UIManager.setLookAndFeel(info.getClassName());
break;}
}
} catch (ClassNotFoundException ex) {
java.util.logging.Logger.getLogger(registra.class.getName()).log(java.util.logging.Lev
el.SEVERE, null, ex);
} catch (InstantiationException ex) {
} catch (IllegalAccessException ex) {
} catch (javax.swing.UnsupportedLookAndFeelException ex) {
el.SEVERE, null, ex); }
//</editor-fold>
/* Create and display the form */
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
52
new registra().setVisible(true);} });}
// Variables declaration - do not modify
private javax.swing.JTextField emailid;
53
7.TESTING
7.1 Introduction
In general, software engineers distinguish software faults from software
failures. In case of a failure, the software does not do what the user expects. A fault is
a programming error that may or may not actually manifest as a failure. A fault can
also be described as an error in the correctness of the semantic of a computer program.
A fault will become a failure if the exact computation conditions are met, one of them
being that the faulty portion of computer software executes on the CPU. A fault can
also turn into a failure when the software is ported to a different hardware platform or
a different compiler, or when the software gets extended. Software testing is the
technical investigation of the product under test to provide stakeholders with quality
related information.
System Testing and Implementation

The purpose is to exercise the different parts of the module code to detect
coding errors. After this the modules are gradually integrated into subsystems, which
are then integrated themselves too eventually forming the entire system. During
integration of module integration testing is performed. The goal of this is to detect
designing errors, while focusing the interconnection between modules. After the
system was put together, system testing is performed. Here the system is tested against
the system requirements to see if all requirements were met and the system performs
as specified by the requirements. Finally accepting testing is performed to demonstrate
to the client for the operation of the system.
For the testing to be successful, proper selection of the test case is essential.
There are two different approaches for selecting test case. The software or the module
to be tested is treated as a black box, and the test cases are decided based on the
specifications of the system or module. For this reason, this form of testing is also
called “black box testing”.
The focus here is on testing the external behavior of the system. In structural
testing the test cases are decided based on the logic of the module to be tested. A
common approach here is to achieve some type of coverage of the statements in the
code. The two forms of testing are complementary: one tests the external behavior, the
other tests the internal structure.
54
Testing is an extremely critical and time-consuming activity. It requires proper
planning of the overall testing process. Frequently the testing process starts with the
test plan. This plan identifies all testing related activities that must be performed and
specifies the schedule, allocates the resources, and specifies guidelines for testing. The
test plan specifies conditions that should be tested; different units to be tested, and the
manner in which the module will be integrated together. Then for different test unit, a
test case specification document is produced, which lists all the different test cases,
together with the expected outputs, that will be used for testing. During the testing of
the unit the specified test cases are executed and the actual results are compared with
the expected outputs. The final output of the testing phase is the testing report and the
error report, or a set of such reports. Each test report contains a set of test cases and the
result of executing the code with the test cases. The error report describes the errors
encountered and the action taken to remove the error.
Testing Techniques
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 conditions known as test cases and the output is evaluated to
determine whether the program is performing as expected. In order to make sure that
the system does not have errors, the different levels of testing strategies that are
applied at differing phases of software development are:
 Black Box Testing
In this strategy some test cases are generated as input conditions that fully
execute all functional requirements for the program. This testing has been uses to find
errors in the following categories:
 Incorrect or missing functions

 Interface errors
 Errors in data structure or external database access
 Performance errors
 Initialization and termination errors.
55
In this testing only the output is checked for correctness. The logical flow of the data is
not checked.
 White Box Testing

In this, the test cases are generated on the logic of each module by drawing
flow graphs of that module and logical decisions are tested on all the cases. It has
been uses to generate the test cases in the following cases:
 Guarantee that all independent paths have been executed.

 Execute all logical decisions on their true and false sides.
 Execute all loops at their boundaries and within their operational
 Execute internal data structures to ensure their validity.
Testing Strategies
 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.
This System consists of five modules. Those are system construction,key
management,secure node to node keys,storage,communication security
 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
56
testing is specifically aimed at exposing the problems that arise from the combination
of components.
 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.
 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 processes.
57
7.2 Sample Test Case Specifications
Test Test case name Input Expected Observed Result

case id Output Output
T1 User register Enter User register user register Pass
username,pa successful successful
ssword,emai
l,phone
number
T2 Enter Unsuccessful Unsuccessful Pass
User register Invalid User User
phone Registration Registration
number.
Enter Unsuccessful Unsuccessful Pass
User register Invalid User User
email id. Registration Registration
T3 User login Enter Unsuccessful Unsuccessful
invalid User Login User Login Pass
Username,p
assword.
User login Enter wrong Unsuccessful Unsuccessful
password User Login User Login Pass
T4 File selection Omit to It should ask to Asked to
choose the choose the file choose the Pass
file by a message file with a
massage
T5 Data Encryption Omit to It should Asked to Pass
encryption encrypt the encrypt the
the data data by a data by a
message message
Table 7.2: Sample Test Case Specifications
7.3 Test case screens

7.3.1 Test case T1
58
Test screen 7.3.1: User Register Successfully

7.3.2 Test case T2
Table 7.3.2: User Unsuccessful Registration
59
Test screen 7.3.2.1:Unsuccessful User Registration

7.3.3 Test case T3
Test screen 7.3.3: Unsuccessful User Login
60
Test screen 7.3.3.1: Unsuccessful User Login

7.3.4 Test case T4
Test screen 7.3.4: Omit To Choose The File

7.3.5 Test case T5
Test screen 7.3.5: Omit To Encryption The Data
61
8.SCREENSHOTS
8.1 User Registration Page
Screen 8.1: User Registration Page

Description: The above screenshot represents the user registration page. user can
register to the system by enter user username and password and email id and mobile
number.
8.2 IP Address 0f User
Screen 8.2: IP Address Of User

Description: The above screenshot represents the ip address to the user.system will
provide ip address to user.it stores the details of user by using this ip address.
62
8.3 Mac Address 0f The System
Screen 8.3: MAC Address For User

Descritption: the above screeshot shows the mac address of the system.it will be used
to prove unique address to user.
8.4 Register Succesfully
Screen 8.4: Register Succusfully

Description:the above screenshot shows the registration form for user.it will be helps
to registers the users
63
8.5 Login Page
Screen 8.5: Login Page

Description:the above screenshot represent the login page.this page will be used to
login the registerd user.
8.6 Choose File
Screen 8.6: Choose File

Descrption:this screenshot represent the choose file page.this page will be used for
choosing file for sending data.
64
8.7 Encrypt File
Screen 8.7: Encrypt File

Description:this screenshot represent the encrypt file page.this page will be helps to
encrypt the chosen file.
8.8 Choose Destination
Screen 8.8: Choose Destination

Description:this screenshot represent the chose destination for sending.this page will
be helps to choose the destination from the list of data.
65
8.9 Shortest Path
Screen 8.9: Shortest Path

Description:this screenshot represent the shortest path page.in this page have
collection of nodes.so here system finds the shortest path for sending data by using
this nodes.
8.10 Data Succesfully Send
Screen 8.10: Data Successfully Send

Description:this screenshot represent the data sending.so here shows the data send
succesusdully to destination.
66
8.11 Attack Node
Screen 8.11: Attack Node

Description:this screenshot represent the attack nodes.so here some attack will occurs
on nodes but superman will be solves the attack.
.8.12 Data Share Details
Screen 8.12: Data Share Details

Description:this screenshot represents the details of share data.so here it will helps to
know the details of user and node and path and attack details.
67
8.13 Details Of User
Screen 8.13: Details Of User

Description:this screenshot shows the details od user.
8.15 Details Of Node
Screen 8.15: Details Of Nodes

Description:this screenshot shows the details of nodes
68
8.17 Details Of Route Path
Screen 8.17: Details Of Route Path

Description:this screenshot shows the details of the route path.
8.16 Details Of Node Attack
Screen 8.16: Details Of Node Attack

Description: this screenshot represent the details of attacked nodes.
69
CONCLUSION
SUPERMAN is a novel security framework that protects the network and
communication in MANETs. The primary focus is to secure access to a virtually
closed network (VCN) that allows expedient, reliable communication with
confidentiality, integrity and authenticity services. SUPERMAN addresses all eight
security dimensions outlined in X.805. Thus, SUPERMAN can be said to implement a
full suite of security services for autonomous MANETs. It fulfils more of the core
services outlined in X.805 than IPsec, due to being network focused instead of end-to-
end oriented.
IPsec is intended to provide a secure environment between two end-points
regardless of route, and has been suggested by some researchers to be a viable
candidate for MANET security. However, it does not extend protection to routing
services. Nor does it provide low-cost security, requiring a lengthy set-up and
teardown process, usually on a session basis. Simulation has been undertaken and the
results are reported and and analysed to determine the relative cost of security for
SUPERMAN, compared against IPsec, SAODV and SOLSR where relevant.
70
BIBLIOGRAPHY/REFERENCES
[1] P. S. Kiran, “Protocol architecture for mobile ad hoc networks,” 2009 IEEE
International Advance Computing Conference (IACC 2009), 2009.
[2] A. Chandra, “Ontology for manet security threats,” PROC. NCON, Krishnankoil,
Tamil Nadu, pp. 171–17, 2005.
[3] A. K. Rai, R. R. Tewari, and S. K. Upadhyay, “Different types of attacks on
integrated manet-internet communication,” International Journal of Computer Science
and Security, vol. 4, no. 3, pp. 265–274, 2010.
[4] D. Smith, J. Wetherall, S. Woodhead, and A. Adekunle, “A cluster-based
approach to consensus based distributed task allocation,” in Parallel, Distributed and
Network-Based Processing (PDP), 2014 22nd Euromicro International Conference
on. IEEE, 2014, pp. 428–431.
[5] I. D. Chakeres and E. M. Belding-Royer, “Aodv routing protocol implementation
design,” in Distributed Computing Systems Workshops, 2004. Proceedings. 24 th
International Conference on. IEEE, 2004, pp. 698–703.
[6] DATA COMMUNICATIONS AND COMPUTER NETWORKS Kindle Edition
by BRIJENDRA SINGH (Author).
[7] MOBILE COMPUTING textbook technical publication pune-third revised edition
by V.JAYASRI AROKIAMARY(Author).
[8] MOBILE COMMUNICATION textbook technical publication pune-second
edition by JOCHEN SCHILLER(Author).
[9] AD HOC NETWORKING textbook technical publication pune-first Edition by
by CHARLES E. PERKINS (Author)
[10] MOBILE COMPUTING textbook khanna book pubishing edition by RISHABH
ANAND(author)
[11] www.wiley.com/go/misra2204
[12] http://www.isi.edu/nsnam/ns/,2003
[13] http://en.wikipedia.org/wiki/Data_integrity
71

1.1 Brief Information About The Project: Security Using Pre-Existing Routing For Mobile Ad-Hoc Nerwork

Uploaded by

Copyright:

Available Formats

1.1 Brief Information About The Project: Security Using Pre-Existing Routing For Mobile Ad-Hoc Nerwork

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1.1 Brief Information About The Project: Security Using Pre-Existing Routing For Mobile Ad-Hoc Nerwork

Uploaded by

Copyright:

Available Formats

Security using pre-existing routing

for mobile ad-hoc nerwork

3.6.2 Software Requirements

Id Integer Primary Key Specifies ID

User name Varchar Not null Specifies user name

Mac address Varchar Not null Specifies mac address

Table 4.4.1: Data table for user details

Column name Datatype Constraint Description

4.5.1 Use case Diagram

Actor An Actor, as mentioned, is a user of the

Use Case A Use Case is functionality provided by

Directed These Associations are used to link

find shortest path

Participating actors User

Flow of Events 1. The user login into the system

Entry condition Source should login into the system

Entry condition Source should be choose the file.

Exit condition Successfully file uploads and encrypt.

Entry condition system should choose the destination

Exit condition Successfully chosed destination.

destination source will be sends the file to 4.5.1.4:

destination. Use case

2.The system will finds

template for find shortest path

Usecase name Receive file

Table 4.5.1.5: Use case template for receive file

Class Classes are the building blocks in object-

Associatio An Association is a generic relationship

4.5.3 Sequence diagram

Object Objects are instances of classes, and are

Message Messages, modeled as horizontal arrows

shortest oath selection

checking attack resolving

Actor Actors can also communicate with Objects, so they too

Messag Messages, modeled as arrows between objects, and

4: checking attacks and resolving

Fig4.5.4:collaboration diagram for security using pre existing routing for

Action An action represents the execution of an

Decision An activity diagram expresses decision

Synchronization The fork will divide the state into multiple

Swim lane The swim lane will divide the business

Transition A transition is a directed relationship

no superman solv e in the

Fig: Generating class file

Fig: Compiling java program

Fig: Java API

What Can Java Technology Do?

Fig: Java Database Connectivity

 Get started quickly: Although the Java programming language is a powerful

1. SQL Level API

Java ha two things: a programming language and a platform.

Java is a high-level programming language that is all of the

Fig: Process of Compilation and Interpretation

2. Time Series Chart Interactivity

Fig: General J2ME architecture

jLabel6 = new javax.swing.JLabel();

j = st.executeUpdate("insert into userreg

System Testing and Implementation

 Black Box Testing