Documentation

MINIMIZING DELAY AND MAXIMIZING LIFETIME FOR WIRELESS
SENSOR NETWORKS WITH NYCAST

_____________________________________________________________________
CHAPTER-1
_________________________INTRODUCTION
1.1Scope:
The scope of this project we first study how to optimize the any cast
forwarding schemes for minimizing the expected packet-delivery delays from the
sensor nodes to the sink. Based on this result, we then provide a solution to the joint
control problem of how to optimally control the system parameters of the sleep-wake
scheduling protocol and the any cast packet-forwarding protocol to maximize the
network lifetime, subject to a constraint on the expected end to end packet-delivery
delay.
1.2. Objective:
e are interested in minimizing the delay and maximizing the lifetime of
event-driven wireless sensor networks, for which events occur infre!uently. "n such
systems, most of the energy is consumed when the radios are on, waiting for an
arrival to occur. #leep-wake scheduling is an effective mechanism to prolong the
lifetime of these energy-constrained wireless sensor networks. $owever, sleep-wake
scheduling could result in substantial delays because a transmitting node needs to wait
for its next-hop relay node to wake up. %n interesting line of work attempts to reduce
these delays by developing any cast.-based packet forwarding schemes, where each
node opportunistically forwards a packet to the neighboring node that wakes up
among multiple candidate nodes.. Based on this result, we then provide a solution to
the joint control problem of how to optimally control the system parameters of the
sleep-wake scheduling protocol and the any cast packet-forwarding protocol to
maximize the network lifetime, subject to a constraint on the expected end to end
packet-delivery delay
1.3. Desciptio! o" t#e Poject:
_____________________________________________________________________
MITS, MCA2009-12
1
_____________________________________________________________________
&ecent advances in wireless sensor networks have resulted in a uni!ue
capability to remotely sense the environment. These systems are often deployed in
remote or hard-to reach areas. $ence, it is critical that such networks operate
unattended for long durations. Therefore, extending network lifetime through the
efficient use of energy has been a key issue in the development of wireless sensor
networks. "n this paper, we will focus on event-driven asynchronous sensor networks,
where events occur rarely. This is an important class of sensor networks and has many
applications such as environmental monitoring, intrusion detection, etc. "n such
systems, there are four main sources of energy consumption' energy re!uired to keep
the communication radios on( energy re!uired for the transmission and reception of
control packets( energy re!uired to keep sensors on( and energy re!uired for actual
data transmission and reception. The fraction of total energy consumption for actual
data transmission and reception is relatively small in these systems, because events
occur so rarely. The energy re!uired to sense events is usually a constant and cannot
be controlled.
$ence, the energy expended to keep the communication system on )for
listening to the medium and for control packets* is the dominant component of energy
consumption, which can be controlled to extend the network lifetime. Thus, sleep-
wake scheduling becomes an effective mechanism to prolong the lifetime of energy
constrained event-driven sensor networks. By putting nodes to sleep when there are
no events, the energy consumption of the sensor nodes can be significantly reduced.
+arious kinds of sleep-wake scheduling protocols have been proposed in the
literature. #ynchronized sleep-wake scheduling protocols have been proposed in these
protocols, sensor nodes periodically or a periodically exchange synchronization
information with neighboring nodes.
$owever, such synchronization procedure could incur additional
communication overhead, and consume a considerable amount of energy. ,n-demand
sleep-wake scheduling protocols have been proposed in, where nodes turn off most of
their circuitry and always turn on a secondary low-powered receiver to listen to
.wake-up calls from neighboring nodes when there is a need for relaying packets.
_____________________________________________________________________
MITS, MCA2009-12
2
_____________________________________________________________________
$owever, this on demand sleep-wake scheduling can significantly increase the cost of
sensor motes due to the additional receiver.
"n this work, we are interested in asynchronous sleep-wake scheduling
protocols such as those proposed in these protocols, the sleep-wake schedule at each
node is independent of that of other nodes, and thus the nodes do not re!uire
either a synchronization procedure or a secondary low-power receiver. $owever,
because it is not practical for each node to have complete knowledge of the sleep-
wake schedule of other nodes, it incurs additional delays along the path to the sink
because each node needs to wait for its next-hop node to wake up before it can
transmit. This delay could be unacceptable for delay-sensitive applications, such as
are detection or tsunami alarm, which re!uire that the event reporting delay be small.
-rior work in the literature has proposed the use of any cast packet-forwarding
schemes to reduce this event reporting delay. .nder traditional packet-forwarding
schemes, every node has one designated next-hop relaying node in the neighborhood,
and it has to wait for the next-hop node to wake up when it needs to forward a packet.
1.$. I!to%&ctio! to 'o%&(es:
These are as follows
1.$.1. Net)o* +o%&(e:
1.$.2. T,-et ,!. c,st %istib&tio!:
1.$.3. S(eep-),*e sc#e%&(i!-:
1.$.$. Net)o* (i"eti+e e!e-. e""icie!c.:
/lient-server computing or networking is a distributed application architecture
that partitions tasks or workloads between service providers )servers* and service
re!uesters, called clients. ,ften clients and servers operate over a computer network
on separate hardware. % server machine is a high-performance host that is running one
or more server programs which share its resources with clients. % client also shares
any of its resources( /lients therefore initiate communication sessions with servers
which await )listen to* incoming re!uests.
_____________________________________________________________________
MITS, MCA2009-12
3
_____________________________________________________________________
1.$.2. T,-et A!.c,st Distib&tio!:
e start by defining the objective of our measurement process. %ssume that
each user spends a random amount of time in the system, where the lifetime of joining
users is drawn from some distribution. This is similar to the heterogeneous churn
model proposed goal of the sampling process is to estimate with as much accuracy as
possible function. The measurement process is assumed to have periodic
access to the information about which users are currently present in the system. This
process allows the sampler to test whether a given user is still alive as well as discover
the entire population of the system at any time. $owever, due to bandwidth and
/onnection-delay constraints on obtaining this information, the sampling process
cannot !uery the system for longer than or more fre!uently than once per time units,
where usually varies from several minutes to several hours depending on the speed of
the crawler and network size.
1.$.3. S(eep-/,*e Sc#e%&(i!-:
"n such systems, most of the energy is consumed when the radios are on,
waiting for an arrival to occur. #leep-wake scheduling is an effective mechanism to
prolong the lifetime of these energy-constrained wireless sensor networks. $owever,
sleep-wake scheduling could result in substantial delays because a transmitting node
needs to wait for its next-hop relay node to wake up. %n interesting line of work
attempts to reduce these delays by developing anycast based packet forwarding
schemes, where each node opportunistically forwards a packet to the first neighboring
node that wakes up among multiple candidate nodes.
Based on this result, we then provide a solution to the joint control problem of
how to optimally control the system parameters of the sleep-wake scheduling protocol
and the anycast packet-forwarding protocol to maximize the network lifetime, subject
to a constraint on the expected end to end packet-delivery delay.
e assume that the sensor network employs sleep-wake scheduling to
improve energy efficiency. e first introduce a basic sleep-wake scheduling protocol
as follows. 0or ease of exposition, in this basic protocol we assume that there is a
_____________________________________________________________________
MITS, MCA2009-12
4
_____________________________________________________________________
single source that sends out event-reporting packets to the sink. This is the most likely
operating mode because when nodes wake up asynchronously and with low duty-
cycles, the chance of multiple sources generating event-reporting packets
simultaneously is small.
1.$.$. Net)o* 0i"eti+e E!e-. E""icie!c.:
,ptimize the any cast forwarding schemes for minimizing the expected
packet-delivery delays from the sensor nodes to the sink. Based on this result, we then
provide a solution to the joint control problem of how to optimally control the system
parameters of the sleep-wake scheduling protocol and the any cast packet-forwarding
protocol to maximize the network lifetime, subject to a constraint on the expected end
to end packet-delivery delay.
1ow introduce the 1etwork energy efficient, performance metric, the network
lifetime, and the corresponding lifetime-maximization problem. 1ote that implicitly
in this definition of lifetime we have chosen not to account for the energy
consumption by data transmission. %s mentioned in the introduction, this is a
reasonable approximation for event-driven sensor networks in which events occur
very rarely because the energy consumption of the sensor nodes is dominated by the
energy consumed during the sleep-wake scheduling.
e study the lifetime-maximization problem to optimally control the sleep-
wake scheduling policy and the any cast policy, in order to maximize the network
lifetime subject to a upper limit on the expected end-to-end delay. ,ur numerical
results suggest that the proposed solution can substantially outperform prior heuristic
solutions in the literature under practical scenarios where there are obstructions in the
coverage area of the wireless sensor network.
A(-oit#+:
0oc,(-OPT A(-oit#+
This algorithm can be viewed as performing the value-iteration .
_____________________________________________________________________
MITS, MCA2009-12
5
_____________________________________________________________________
2ach node i sets its delay value 3)4* i to in5nity, and only the sink sets 3)4* s
to zero. Then, at every iteration h, each node i uses the delay values 3)h6* j
of neighboring nodes j from the previous iteration )h 6* to update the
current forwarding set 0)h* i
%nd the current priority assignment 7b)h* j according to the value iteration .
e will show that when the value iterations are synchronized, the algorithm
converges in 1 iterations, and it returns the optimal anycast policy that
minimizes the delays of all nodes simultaneously. 0urthe
That even if the value iterations and the policy updates of nodes are not
synchronized, the anycast policy of each node still converges to the optimal
anycast policy.
1(ob,(-OPT A(-oit#+:
The 89,B%9-,-T algorithm is a classic value iteration for solving #hortest
#tochastic -roblem )##-* problems.
we map the delay-minimization problem to the ##- problem as follows.
/onsider the following :arkov chain that corresponds to the process with
which a packet is forwarded under a given anycast policy.
There are states 6( ;( 5 5 5 (1, and s, where state i represents that a packet is in
node i. % state transition occurs from state i to state j when node i forwards the
packet to node j.
)e do not consider self-transitions.*
#tate s is the absorbing state )it is also called the termination state in <;6=*,
where state transition ends.
.nder the anycast forwarding policy )%(B*, a packet at node i will be
forwarded to neighboring node j with probability !i(j )7p(%(B* given by )>*.
The cost associated with the transition from node i to any neighboring node
corresponds to the expected one-hop delay di)7p(%(B* given by )?*.
_____________________________________________________________________
MITS, MCA2009-12
6
_____________________________________________________________________
The total cost, which is the expectation of the accumulated costs from initial
state i to sink s, corresponds to the expected endto-end delay 3i)7p(%(B* from
node i to the sink s. Then, the evolution of 3)h* i corresponds to the value
iteration .
_____________________________________________________________________
MITS, MCA2009-12
7
_____________________________________________________________________
CHAPTER-2
______________________S2STE' ANA02SIS
2.1 I!to%&ctio!
Based on the goals, the analyst study the project to identify the special
e!uipment re!uired for the project. The technology re!uired for the cost estimation
and scheduling.
2.1.1 3e,sibi(it. St&%.
Tec#!ic,( "e,sibi(it.:
2valuating the technical feasibility is the trickiest part of a feasibility study.
This is because , at this point in time, not too many detailed design of the system,
making it difficult to access issues like performance, costs on ) account of the kind of
technology to be deployed* etc. % number of issues have to be considered while doing
a technical analysis.
i* .nderstand the different technologies involved in the proposed system '
Before commencing the project, we have to be very clear about what are the
technologies that are to be re!uired for the development of the new system.
ii* 0ind out whether the organization currently possesses the re!uired
technologies'
o "s the re!uired technology available with the organization@
o "f so is the capacity sufficient@
0or instance A
Bill the current printer be able to handle the new reports and forms re!uired
for the new system@C
_____________________________________________________________________
MITS, MCA2009-12
8
_____________________________________________________________________
Eco!o+ic "e,sibi(it.:
2conomic feasibility attempts ; weigh the costs of developing and
implementing a new system, against the benefits that would accrue from having the
new system in place. This feasibility study gives the top management the economic
justification for the new system.
% simple economic analysis which gives the actual comparison of costs and
benefits are much more meaningful in this case. "n addition, this proves to be a useful
point of reference to compare actual costs as the project progresses. There could be
various types of intangible benefits on account of automation. These could include
increased customer satisfaction, improvement in product !uality better decision
making timeliness of information, expediting activities, improved accuracy of
operations, better documentation and record keeping, faster retrieval of information,
better employee morale.
Ope,tio!,( 3e,sibi(it.:
-roposed projects are beneficial only if they can be turned into information
systems that will meet the organizations operating re!uirements. #imply stated, this
test of feasibility asks if the system will work when it is developed and installed. %re
there major barriers to "mplementation@ $ere are !uestions that will help test the
operational feasibility of a project'
"s there sufficient support for the project from management from users@ "f the
current system is well liked and used to the extent that persons will not be able
to see reasons for change, there may be resistance.
%re the current business methods acceptable to the user@ "f they are not, .sers
may welcome a change that will bring about a more operational and useful
systems.
$ave the user been involved in the planning and development of the project@
2arly involvement reduces the chances of resistance to the system and in
_____________________________________________________________________
MITS, MCA2009-12
9
_____________________________________________________________________
8eneral and increases the likelihood of successful project.
#ince the proposed system was to help reduce the hardships encountered. "n the
existing manual system, the new system was considered to be operational feasible.
2.2. E4isti!- S.ste+:
2xisting mechanism to prolong the lifetime of energy-constrained wireless
sensor networks, it incurs an additional delay for packet delivery when each node
needs to wait for its next-hop relay node to wake up, which could be unacceptable for
delay-sensitive applications. -rior work in the literature has proposed to reduce this
delay using any cast, where each node opportunistically selects the first neighboring
node that wakes up among multiple candidate nodes. Doint control problem of how to
optimally control the sleep-wake schedule, the any cast candidate set of next-hop
neighbors, and any cast priorities, to maximize the network lifetime subject to a
constraint on the expected end-to-end delay. e provide an efficient solution to this
joint control problem. ,ur numerical results indicate that the proposed solution can
substantially outperform prior heuristic solutions in the literature, especially under the
practical scenarios where there are obstructions in the coverage area of the wireless
sensor network.
2.3. Popose% S.ste+:
e are interested in minimizing the delay and maximizing the lifetime of
event-driven wireless sensor networks, for which events occur infre!uently. ,ptimize
the any cast forwarding schemes for minimizing the expected packet-delivery delays
from the sensor nodes to the sink. Based on this result, we then provide a solution to
the joint control problem of how to optimally control the system parameters of the
sleep-wake scheduling protocol and the any cast packet-forwarding protocol to
maximize the network lifetime, subject to a constraint on the expected end to end
packet-delivery delay.
e develop any cast packet-forwarding scheme to reduce the event-reporting
delay and to prolong the lifetime of wireless sensor networks employing
asynchronous sleep-wake scheduling.
_____________________________________________________________________
MITS, MCA2009-12
10
_____________________________________________________________________
#pecifically, we study two optimization problems. 0irst, when the wake-up
rates of the sensor nodes are given, we develop an efficient and distributed algorithm
to minimize the expected event-reporting delay from all sensor nodes to the sink.
#econd, using a specific definition of the network lifetime, we study the lifetime-
maximization problem to optimally control the sleep-wake scheduling policy and the
any cast policy, in order to maximize the network lifetime subject to a upper limit on
the expected end-to-end delay. ,ur numerical results suggest that the proposed
solution can substantially outperform prior heuristic solutions in the literature under
practical scenarios where there are obstructions in the coverage area of the wireless
sensor network.
2.$. So"t),e 5H,%),e Speci"ic,tio!s:
So"t),e Re6&ie+e!ts:
E ,perating system ' - indows F- -rofessional.
E /oding 9anguage ' - Dava.
E Tool .sed ' - 2clipse.
H,%),e Re6&ie+e!ts:
E #ystem ' -entium "+ ;.> 8$z.
E $ard 3isk ' >4 8B):in*
E :onitor ' 6? +8% /olour.
E :ouse ' 9ogitech.
E &%: ' ;?G :B):in*
_____________________________________________________________________
MITS, MCA2009-12
11
_____________________________________________________________________

CHAPTER-3
_________________________S2STE' DESI1N
3.1. I!to%&ctio!
#oftware design sits at the technical kernel of software engineering and
applied regardless of the software process model that is used. Beginning once
software re!uirements have been analyzed and specified, software design is the first
of three technical activities, design, code generation, and test Athat are re!uired to
build and verify the software. 2ach activity transforms information in a manner that
ultimately results in validated computer software.
The importance of software design can be stated with a single word-!uality.
3esign is the place where !uality is fostered in software engineering. 3esign provides
us with representations of software that can be assessed for !uality. 3esign is the only
way that we can accurately translate a customerHs re!uirements into a finished
software product or system. #oftware design serves as the foundation for all the
software engineering and software support steps that follow.
3.2. Desi-! Pi!cip(es
Basic design principles enable the software engineer to navigate the design
process. 3avis <3%+I?= suggests a set of principles for software design, which have
been adapted and extended in the following list'
The design process should not suffer from Btunnel visionC. % good designer
should consider alternative approaches, judging each based on the
re!uirements of the problem, the resources available to do the job.
The design should be traceable to the analysis model. Because a single
element of the design model often traces to multiple re!uirements, it is
necessary to have a means for tracking how re!uirements have been satisfied
by the design model.
_____________________________________________________________________
MITS, MCA2009-12
12
_____________________________________________________________________
The design should not reinvent the wheel. #ystems are constructed using a set
of design patterns, many of which have likely been encountered before.
Time is short and resources are limitedJ 3esign time should be invested in
representing truly new ideas and integrating those patterns that already exist.
The design should Bminimize the intellectual distanceC between the software
and the problem as it exists in the real world. That is, the structure of the
software design should mimic the structure of the problem domain.
The design should exhibit uniformity and integration. % design is uniform if it
appears that one person developed the entire thing. % design is integrated if
care is taken in defining interfaces between design components.
The design should be structured to accommodate change. The design concepts
enable a design to achieve this principle.
3esign is not coding, coding is not design. 2ven when detailed procedural
designs are created for program components, the level of abstraction of the
design model id higher than source code. The only design decisions made at
the coding level address the small implementation details that enable the
procedural design to be coded.
The design should be assessed for !uality as it is being created, not after the
fact. % variety of design concepts and measures are available to assist the
designer in assessing !uality.
The design should be reviewed to minimize conceptual errors.
hen these design principles are properly applied, the software engineer
creates a design that exhibits both external and internal !uality factors. 2xternal
!uality factors are those properties of the software that can be readily observed by
users. "nternal !uality factors are of importance to software engineers.
3.3. Desi-! 'et#o%o(o-.
_____________________________________________________________________
MITS, MCA2009-12
13
_____________________________________________________________________
% methodology can be simply defined as a set of procedure that one follows
from the beginning to the completion of the software development process. The
nature of the methodology is dependent on a number of factors, including the software
development environment, the organizationKs practices, the nature or type of the
software being developed, the re!uirements of the users, the !ualification and training
of the software development team, the available hardware and software resources, the
availability o f existing design modules, and even the budget and the time schedule.
#ince the 6IL4s, there has been a proliferation of software design methodologies.
3ifferent methodologies have been developed to resolve different types of problems.
"n describing these problems, it is often possible or necessary to group problems with
similar characteristics together. This is called the problem domain.
Object Oie!te% Desi-!
,,3 is basically an approach that models the problem in terms of its objects
and the operations performed on them. ,,3 decomposes the system into modules
where each module in the system denotes an object or class of objects from the
problem space. ,bjects represent concrete entities which are instances of one or more
classes. ,bjects encapsulate data attributes, which can be data structures or just
attributes, and operations, which are procedures. ,perations contain methods, which
are program code that operates the attributes. % class is a set of objects that share a set
of common structure and behavior.
% class represents a type and an object is an instance of a class. % class
contains three items' class name, list of attributes, and list of operations. Thus, a class
represents a set of objects with similar attributes, common behavior and common
relationships to other objects.
,bject-oriented design transforms the analysis model created using object-
oriented analysis into a design model that serves as a blueprint for software
construction. 3esigning object-oriented software is hard, and designing reusable
object-oriented software is even harder. e must find pertinent objects, factor them
_____________________________________________________________________
MITS, MCA2009-12
14
_____________________________________________________________________
into classes at the right granularity, define class interfaces and inheritance hierarchies,
and establish key relationships among them. ,ur design should be specific to problem
at hand but also general enough to address future problems and re!uirements. e also
want to avoid redesign, or at least minimize it. 2xperienced object-oriented designers
will tell us that a reusable and flexible design is not impossible to get BrightC the first
time. Before a design is finished, they usually try to reuse it several times, modifying
it each time.
The uni!ue nature of object-oriented design lies in its ability upon four
important software design concepts' abstraction, information hiding, functional
independence, and modularity. %ll design methods strive for software that exhibits
these fundamental characteristics, but only ,,3 provides a mechanism that enables
the designer to achieve all four without complexity or compromise.
SD0C 'et#o%o(o-ies:
This document play a vital role in the development of life cycle )#39/* as it
describes the complete re!uirement of the system. "t means for use by developers and
will be the basic during testing phase. %ny changes made to the re!uirements in the
future will have to go through formal change approval process.
'o%e(:
The waterfall model, sometimes called the classical life cycle, suggests a
systematic se!uential approach to software development that begins with customer
specification of re!uirements and progresses through planning, modeling,
construction and deployment culminating in ongoing support of the complete
software.
The waterfall model is the oldest project but real projects follow the
se!uential flow that model propose. "t can serve as a use full process model in
situations where re!uirements are fixed and work is to proceed to completion in a
linear manner.
Steps "o /,te",(( 'o%e(:
_____________________________________________________________________
MITS, MCA2009-12
15
_____________________________________________________________________
This project is using waterfall model .this model consisting of > phases.
/ommunication phase'
This phase consisting of project initiation and re!uirement gathering
-lanning phase'
This phase consisting of estimation, scheduling ,tracking
:odeling phase'
This phase consisting of analyzing and design.
/onstruction phase'
This phase consisting of coding and testing.
3eployment phase'
This phase consisting of delivery support feedback.
_____________________________________________________________________
MITS, MCA2009-12
16
_____________________________________________________________________

3i- 3.$ : /,te",(( +o%e(
3.$ D3D7U'0 Di,-,+s
3.$.1 D,t, 3(o) Di,-,+s 8D3D9:
The data flow diagram )303* is one of the most important modeling tools. "t
is used to model the system components. These components are the system process,
_____________________________________________________________________
MITS, MCA2009-12
17
_____________________________________________________________________
the data used by the process, an external entity that interacts with the system and the
information flows in the system.
303 shows how the information moves through the system and how it is
modified by a series of transformations. "t is a graphical techni!ue that depicts
information flow and the transformations that are applied as data moves from input to
output.
303 is also known as bubble chart. % 303 may be used to represent a system
at any level of abstraction. 303 may be partitioned into levels that represent
increasing information flow and functional detail.
% level 4 303, also called as the context level diagram, represents the entire
system as a single module with input and output data indicated by incoming outgoing
arrows respectively. %dditional process and information flow paths are represented as
the level 4
303 is portioned to reveal more details. The context level diagram for the
proposed system is shown in the fig.
% level 6 303, also called as top-level 303, represent the system with major
modules and data stores. The other levels will show each module in the top-level 303
in more detailed fashion. The top-level and other level 303 s for the proposed
systems are shown next.
To context a data flow diagram four basic symbols are used. They are given
below.
'o%e(i!- R&(es:
There are several common modeling rules when creating 303s'
6. %ll processes must have at least one data flow in and one data flow out.
_____________________________________________________________________
MITS, MCA2009-12
18
_____________________________________________________________________
;. %ll processes should modify the incoming data, producing new forms of
outgoing data.
M. 2ach data store must be involved with at least one data flow.
>. 2ach external entity must be involved with at least one data flow.
?. % data flow must be attached to at least one process.
Not,tio!s Use% i! D,t, 3(o) Di,-,+
The logic dataflow diagrams can be draw using only four simple notations i.e.
special symbols or icons and the annotation that associates them with a specific
system. % data flow diagram illustrates the processes, data stores, and external entities
in a business or other system and the connecting data flows.
Co+po!e!ts
The four components of data flow diagrams )303* are'
6. 2xternal entities N Terminators
;. -rocesses
M. 3ata stores
>. 3ata flows
Desciptio!
1. E4te!,( e!tities 7 Te+i!,tos: These are outside of the system being
modeled. Terminator represents where the information comes from and where
it goes to. "n designing a system, we have no idea as to what these terminators
do or how they do it.
2. Pocesses: :odify the inputs in the process of generating the outputs.
3. D,t, stoes: &epresents a place in the process where the data comes to rest.
_____________________________________________________________________
MITS, MCA2009-12
19
_____________________________________________________________________
$. D,t, "(o)s: They show how the data moves between terminators, processes
and data stores.
E(e+e!t,( Re"ee!ces ,!% S.+bo(s
E(e+e!t,( Re"ee!ces S.+bo(s
2xternal 2ntities N Terminators
-rocesses
3ata stores
3ata flows
D,t,"(o) Di,-,+:
_____________________________________________________________________
MITS, MCA2009-12
20
_____________________________________________________________________
3i- 3.: D,t, 3(o) Di,-,+
U'0 Di,-,+s
_____________________________________________________________________
MITS, MCA2009-12
21
_____________________________________________________________________
U!i"ie% 'o%e(i!- 0,!-&,-e Di,-,+s
The .nified :odeling language allows software engineer to express an
analysis model using the modeling notation that is governed by set of syntactic
semantic and pragmatic rules. % .:9 system is represented using five different views
that describe the system from distinctly different perspective. 2ach view is defined by
a set of diagram, which is as follows.
A! Ovevie) o" U'0
The .:9 is a language for
+isualizing
#pecifying
/onstructing
3ocumenting
These are the artifacts of a software-intensive system.
Use 'o%e( ;ie)
This view represents the system from the users perspective. The analysis
representation describes a usage scenario from the end-users perspective.
St&ct&,( +o%e( vie)
"n this model the data and functionality are arrived from inside the system.
This model view models the static structures.
<e#,vio,( 'o%e( ;ie)
"t represents the dynamic of behavioral as parts of the system, depicting the
interactions of collection between various structural elements described in the user
model and structural model view.
I+p(e+e!t,tio! 'o%e( ;ie)
_____________________________________________________________________
MITS, MCA2009-12
22
_____________________________________________________________________
"n this the structural and behavioral as parts of the system are represented as
they are to be built.
E!vio!+e!t,( 'o%e( ;ie)
"n this the structural and behavioral aspects of the environment in which the
system is to be implemented are represented. .:9 is specifically constructed
through two different domains they are
.:9 %nalysis modeling, this focuses on the user model and structural model
views of the system.
.:9 design modeling, which focuses on the behavioral modeling,
implementation modeling and environmental model views.
A Co!cept&,( +o%e( o" U'0
The .:9Hs basic building blocks.
The rules that dictate how those building blocks may be put together.
#ome common mechanisms that apply throughout the .:9.
Basic building blocks of the .:9
T#e voc,b&(,. o" U'0 e!co+p,sses t#ee *i!%s o" b&i(%i!- b(oc*s:
Things
&elationships
3iagrams
I T#i!-s i! U'0

Things are the abstractions that are first-class citizens in a model. &elationships
tie these things together. 3iagrams group the interesting collection of things. There
are four kinds of things in the .:9
6. #tructural things
;. Behavioral things.
M. 8rouping things
_____________________________________________________________________
MITS, MCA2009-12
23
_____________________________________________________________________
>. %nnotational things
These things are the basic object oriented building blocks of the .:9. They
are used to write well-formed models.
1. St&ct&,( T#i!-s
#tructural things are the nouns of the .:9 models. These are mostly static
parts of the model, representing elements that are either conceptual or physical. "n all,
there are seven kinds of #tructural things.
,9 C(,ss
% class is a description of a set of objects that share the same attributes,
operations, relationships, and semantics. % class implements one or more interfaces.
8raphically a class is rendered as a rectangle, usually including its name, attributes
and operations, as shown below.
Window
origin
Size
Open()
Close()
Display()
b9 I!te",ce
%n interface is a collection of operations that specify a service of a class or
component. %n interface describes the externally visible behavior of that element.
8raphically the interface is rendered as a circle together with its name.

c9 Co((,bo,tio!
/ollaboration defines an interaction and is a society of roles and other
elements that work together to provide some cooperative behavior thatHs bigger than
the sum of all the elements. 8raphically, collaboration is rendered as an ellipse
with dashed lines, usually including only its name as shown below.
_____________________________________________________________________
MITS, MCA2009-12
24
_____________________________________________________________________

%9 Use C,se
.se case is a description of a set of se!uence of actions that a system performs
that yields an observable result of value to a particular things in a model. 8raphically,
.se /ase is rendered as an ellipse with dashed lines, usually including only its name
as shown below.
e9 Co+po!e!t
/omponent is a physical and replaceable part of a system that conforms to and
provides the realization of a set of interfaces. 8raphically, a component is rendered as
a rectangle with tabs, usually including only its name, as shown below.
orderform.java
"9 No%e
% 1ode is a physical element that exists at run time and represents a
computational resource, generally having at least some memory and often, processing
capability. 8raphically, a node is rendered as a cube, usually including only its name,
as shown below.
_____________________________________________________________________
MITS, MCA2009-12
25
Chain of
Responsibilit
y
Place Orer
_____________________________________________________________________

server
2. <e#,vio,( T#i!-s
Behavioral Things are the dynamic parts of .:9 models. These are the verbs
of a model, representing behavior over time and space.
,9 I!te,ctio!
%n interaction is a behavior that comprises a set of messages exchanged
among a set of objects within a particular context to accomplish a specific purpose.
8raphically, a message is rendered as a direct line, almost always including the name
if its operation, as shown below.
3isplay
b9 St,te ',c#i!e
% state machine is a behavior that specifies the se!uence of states an object or
an interaction goes through during its lifetime on response to events, together with its
responses to those events. 8raphically, a state is rendered as rounded rectangle usually
including its name and its sub-states, if any, as shown below.
3. 1o&pi!- T#i!-s
8rouping things are the organizational parts of the .:9 models. These are the
boxes into which a model can be decomposed.
_____________________________________________________________________
MITS, MCA2009-12
26
!aitin"
_____________________________________________________________________
P,c*,-e
% package is a general-purpose mechanism for organizing elements into
groups.

Business Rules
$. A!!ot,tio!,( T#i!-s
%nnotational things are the explanatory parts of the .:9 models.
Note
% note is simply a symbol for rendering constraints and comments attached to
an element or a collection of elements. 8raphically a note is rendered as a rectangle
with dog-eared corner together, with a textual or graphical comment, as shown below.
II Re(,tio!s#ips i! t#e U'0
The word B1otationC in .:9 refers to set of symbols, which are used to
represent a system. These symbols play a vital role in defining a system. Based on
these notations, .:9 defines the four relationships.
6. 3ependency
;. %ssociation
M. 8eneralization
>. &ealization
_____________________________________________________________________
MITS, MCA2009-12
27
_____________________________________________________________________
1. Depe!%e!c.:
The relationship B3ependencyC between two entities refer to position where
changes caused to one entity may have its effect on other entity. The dependency
relation ship is represented as,
%s seen from the figure the dependency symbol is represented by a dashed
arrow proceeding in one direction.
2. Associ,tio!:
% structural relationship that shows a connection among objects is called as an
B%ssociationC. "t is represented as,
3. 1e!e,(i=,tio!:
8eneralization is termed as B#pecialized &elationshipC. "n this relationship,
the objects of one entity can be substituted with the objects of another entity. The
entity whose objects are substituted is known as parent entity and the entity, which is
providing objects for replacement, is known as child entity. "t is represented as,
$. Re,(i=,tio!:
&ealization is a relationship between classifiers in which one classifier lays
down a contract and another classifier guarantees to carry out this contract.
_____________________________________________________________________
MITS, MCA2009-12
28
_____________________________________________________________________
III.Di,-,+s i! t#e U'0
St&ct&,( Di,-,+s:
The #tructural 3iagrams are four types. They are as follows.
a. /lass diagrams
b. ,bject diagrams
c. /omponent 3iagrams
d. 3eployment 3iagrams
,9 C(,ss Di,-,+s
/lass diagrams are the most common diagrams found in modeling object-
oriented systems. % class diagram shows a set of classes, interfaces, and
collaborations and their relationships. 8raphically, a class diagram is a collection of
vertices and arcs.
Co!te!ts:
/lass 3iagrams commonly contain the following things
/lasses
"nterfaces
/ollaborations
3ependency,
generalization and
association relationships
_____________________________________________________________________
MITS, MCA2009-12
29
_____________________________________________________________________
C(,ss Di,-,+:
3i-.3.> C(,ss Di,-,+
_____________________________________________________________________
MITS, MCA2009-12
30
_____________________________________________________________________
8<9 Co+po!e!t Di,-,+:
% component is the physical implementation of classes and collaborations.
%rchitecture of a system can be explained with its components.
Therefore a component is the basic building block of a system. These diagram
scan be achieved by modeling various physical components like libraries, tables, files
etc. which are residing internal to given node.
Co!te!ts:
/omponents
"nterfaces
&elationships
_____________________________________________________________________
MITS, MCA2009-12
31
_____________________________________________________________________
Co+po!e!t Di,-,+:
lien! ".e#e
"dmin.e#e
lien! B.e#e
s$eduling.e
#e
3i-.3.? Co+po!e!t Di,-,+
_____________________________________________________________________
MITS, MCA2009-12
32
_____________________________________________________________________
Dep(o.+e!t Di,-,+:
The deployment diagrams indicate the processing elements, processes,
software components. The static deployment view of a system in terms of different
components, processes can be modeled by deployment diagrams.
% deployment diagram contains-nodes and relationships )dependency and
association*. This diagram is used to know which components will run on which
nodes )with the stereo typeOOsupportsPP* similarly the migration of components will
be represented by the stereo typeOObecomesPP.
Co!te!ts:
1odes
&elationships
_____________________________________________________________________
MITS, MCA2009-12
33
_____________________________________________________________________
user
da!a%as
"dmin
lien! "
lien! B
s$edul
e
3i-.3.@ Dep(o.+e!t Di,-,+
<e#,vio,( Di,-,+s:
The behavioral 3iagrams are four types. They are as follows.
.se case diagrams
#e!uence diagrams
/ollaboration diagrams
%ctivity diagrams
#tate chart diagrams
,9 Use c,se %i,-,+s:
.se /ase diagrams are one of the five diagrams in the .:9 for modeling the
dynamic aspects of systems )activity diagrams, se!uence diagrams, state chart
_____________________________________________________________________
MITS, MCA2009-12
34
_____________________________________________________________________
diagrams and collaboration diagrams are the four other kinds of diagrams in the .:9
for modeling the dynamic aspects of systems*. .se /ase diagrams are central to
modeling the behavior of the system, a sub-system, or a class. 2ach one shows a set of
use cases and actors and relationships.
Co++o! Popeties
% .se /ase diagram is just a special kind of diagram and shares the same
common properties, as do all other diagrams- a name and graphical contents that are a
projection into the model. hat distinguishes a use case diagram from all other kinds
of diagrams is its particular content.
Co!te!ts:
.se /ase diagrams commonly contain'
.se /ases
%ctors
3ependency, generalization, and association relationships
9ike all other diagrams, use case diagrams may contain notes and constraints.
.se /ase diagrams may also contain packages, which are used to group elements of
your model into larger chunks. ,ccasionally, you will want to place instances of use
cases in your diagrams, as well, especially when you want to visualize a specific
executing system.
USECASE DIA1RA':
_____________________________________________________________________
MITS, MCA2009-12
35
_____________________________________________________________________
3i-.3.A:Use c,se %i,-,+
b9 Se6&e!ce Di,-,+s:
% se!uence diagram is an interaction diagram that emphasizes the time
ordering of the messages. 8raphically, a se!uence diagram is a table that shows
objects arranged along the F-axis and messages, ordered in increasing time, along the
Q-axis.
_____________________________________________________________________
MITS, MCA2009-12
36
_____________________________________________________________________
Typically you place the object that initiates the interaction at the left, and
increasingly more sub-routine objects to the right. 1ext, you place the messages that
these objects send and receive along the Q-axis, in order of increasing time from top
to the bottom. This gives the reader a clear visual cue to the flow of control over time.
#e!uence diagrams have two interesting features
There is the object lifeline. %n object lifeline is the vertical dashed line that
represents the existence of an object over a period of time. :ost objects that appear in
the interaction diagrams will be in existence for the duration of the interaction, so
these objects are all aligned at the top of the diagram, with their lifelines drawn from
the top of the diagram to the bottom.
There is a focus of the control. The focus of control is tall, thin rectangle that
shows the period of time during which an object is performing an action, either
directly or through the subordinate procedure. The top of the rectangle is aligns with
the action( the bottom is aligned with its completion.
Se6&e!ce Di,-,+:
_____________________________________________________________________
MITS, MCA2009-12
37
_____________________________________________________________________
3i-.3.1B Se6&e!ce %i,-,+
_____________________________________________________________________
MITS, MCA2009-12
38
_____________________________________________________________________
c9 Co((,bo,tio! Di,-,+s:
/ollaboration 3iagrams remains analogous with se!uence diagrams since
these diagrams encompasses various objects, there links along with
transmissionNreceiving of messages. "n this way they coordinate to structural aspects
of the system )which also provides dynamic view of the system*.
The collaboration diagram contains set of objects( links and the messages send
and received by them.
Co((,bo,tio! Di,-,+s:

lien!
login
da!a !o %e sen!
!o sender
!arge!
dis!ri%u!ion
sleep&wee'
s$eduling
des!ina!i
on
() sending re*ues!
+) providing user name , password
-) ge!!ing a'nowledgmen!
.) using sleep&wa'e algori!$m
/) ge!!ing da!a
3i-.3.11: Co((,bo,tio! Di,-,+
_____________________________________________________________________
MITS, MCA2009-12
39
_____________________________________________________________________
%9 Activit. Di,-,+s:
%n %ctivity 3iagram is essentially a flow chart showing flow of control from
activity to activity. They are used to model the dynamic aspects of as system. They
can also be used to model the flow of an object as it moves from state to state at
different points in the flow of control.
%n activity is an ongoing non-atomic execution with in a state machine.
%ctivities ultimately result in some action, which is made up of executable atomic
computations that result in a change of state of distinguishes a use case diagram from
all other kinds of diagrams is its particular content.
Activit. Di,-,+:
3i-. M.6; %ctivity 3iagram
_____________________________________________________________________
MITS, MCA2009-12
40
_____________________________________________________________________
e9 St,te C#,t Di,-,+s:
% state chart diagram shows a state machine. #tate chart diagrams are used to
model the dynamic aspects of the system. 0or the most part this involves modeling the
behavior of the reactive objects.
% reactive object is one whose behavior is best characterized by its response to
events dispatched from outside its context. % reactive object has a clear lifeline whose
current behavior is affected by its past.
% state chart diagram show a state machine emphasizing the flow of control
from state to state. % state machine is a behavior that specifies the se!uence of states
an object goes through during its lifetime in response to events together with its
response to those events.
% state is a condition in the life of the object during which it satisfies some
conditions, performs some activity or wait for some events. %n event is a specification
of a significant occurrence that has a location in time and space. 8raphically a state
chart diagram is a collection of vertices and arcs. #tate chart diagram commonly
contain.
_____________________________________________________________________
MITS, MCA2009-12
41
_____________________________________________________________________
St,te C#,t Di,-,+:
lo"in
chec#in" for loin process
sener infor$ation
tar"et infor$ation
sleep %ee# sche&lin"
%aitin"
client '
r&nnin"
s&cessf&ll rece(in" of ata to esination
3i-.3.13 St,te c#,t %i,-,+
_____________________________________________________________________
MITS, MCA2009-12
42
_____________________________________________________________________
CHAPTER C $
______________________I'P0E'ENTATION
$.1 I!to%&ctio!
"mplementation is the stage of the project where the theoretical design is
turned into a working system. %t this stage the main workload, the greatest upheaval
and the major impact on the existing system shifts to the user department. "f the
implementation is not carefully planned and controlled it can cause chaos and
confusion.
"mplementation includes all those activities that take place to convert from old
system to new one. The new system may be totally new, replacing an existing manual
or automated system or it may be a major modification to an existing system. -roper
implementation is essential to provide a reliable system to meet the organization
re!uirements. #uccessful implementation may not guarantee improvement in the
organization using the new system, but improper installation will prevent it.
The process of putting the developed system in the actual use is called system
implementation. This includes all those activities that take place to convert from old
system to new system. The system can be implemented only after through testing is
done and if it is found to be working according to the specifications.
The implementation stage involves the following tasks.
"nvestigation of system and constraints.
3esign of methods to achieve the changeover.
Training of the staff is the change over phase.
2valuation of the change over method.
The system is implemented in the server and checked for its performance and
accuracy. #uccessful implementation of the software is accomplished. This project is
to be done using D2EE as a front end and O,c(eAi as a back end. This project uses
DSPE HT'0 controls and events, connected through DD<C OD<C source.
_____________________________________________________________________
MITS, MCA2009-12
43
_____________________________________________________________________
$.2.Ovevie) o" I+p(e+e!t,tio! 0,!-&,-e:
So"t),e E!vio!+e!t
D,v, Tec#!o(o-.
Dava technology is both a programming language and a platform.
T#e D,v, Po-,++i!- 0,!-&,-e
The Dava programming language is a high-level language that can be
characterized by all of the following buzzwords'
#imple
%rchitecture neutral
,bject oriented
-ortable
3istributed
$igh performance
"nterpreted
:ultithreaded
&obust
3ynamic
#ecure
ith most programming languages, you either compile or interpret a program
so that you can run it on your computer. The Dava programming language is unusual
in that a program is both compiled and interpreted. ith the compiler, first you
translate a program into an intermediate language called Dava byte codes Rthe
platform-independent codes interpreted by the interpreter on the Dava platform. The
_____________________________________________________________________
MITS, MCA2009-12
44
_____________________________________________________________________
interpreter parses and runs each Dava byte code instruction on the computer.
/ompilation happens just once( interpretation occurs each time the program is
executed. The following figure illustrates how this works.
3i-.$.1.D,v, ;it&,( ',c#i!e
Qou can think of Dava byte codes as the machine code instructions for the Dava
+irtual :achine )Dava +:*. 2very Dava interpreter, whether itHs a development tool or
a eb browser that can run applets, is an implementation of the Dava +:. Dava byte
codes help make Bwrite once, run anywhereC possible. Qou can compile your program
into byte codes on any platform that has a Dava compiler. The byte codes can then be
run on any implementation of the Dava +:. That means that as long as a computer has
a Dava +:, the same program written in the Dava programming language can run on
indows ;444, a #olaris workstation, or on an i:ac.
T#e D,v, P(,t"o+
% platform is the hardware or software environment in which a program runs.
eHve already mentioned some of the most popular platforms like indows ;444,
_____________________________________________________________________
MITS, MCA2009-12
45
_____________________________________________________________________
9inux, #olaris, and :ac,#. :ost platforms can be described as a combination of the
operating system and hardware. The Dava platform differs from most other platforms
in that itHs a software-only platform that runs on top of other hardware-based
platforms.
The Dava platform has two components'
The Dava +irtual :achine )Dava +:*
The Dava %pplication -rogramming "nterface )Dava %-"*
QouHve already been introduced to the Dava +:. "tHs the base for the Dava
platform and is ported onto various hardware-based platforms.
The Dava %-" is a large collection of ready-made software components that
provide many useful capabilities, such as graphical user interface )8."* widgets. The
Dava %-" is grouped into libraries of related classes and interfaces( these libraries are
known as packages. The next section, hat /an Dava Technology 3o@ $ighlights
what functionality some of the packages in the Dava %-" provide.
The following figure depicts a program thatHs running on the Dava platform. %s
the figure shows, the Dava %-" and the virtual machine insulate the program from the
hardware.
1ative code is code that after you compile it, the compiled code runs on a
specific hardware platform. %s a platform-independent environment, the Dava
platform can be a bit slower than native code. $owever, smart compilers, well-tuned
interpreters, and just-in-time byte code compilers can bring performance close to that
of native code without threatening portability.
_____________________________________________________________________
MITS, MCA2009-12
46
_____________________________________________________________________
/#,t C,! D,v, Tec#!o(o-. DoF
The most common types of programs written in the Dava programming
language are applets and applications. "f youHve surfed the eb, youHre probably
already familiar with applets. %n applet is a program that adheres to certain
conventions that allow it to run within a Dava-enabled browser.
$owever, the Dava programming language is not just for writing cute,
entertaining applets for the eb. The general-purpose, high-level Dava programming
language is also a powerful software platform. .sing the generous %-", you can write
many types of programs.
%n application is a standalone program that runs directly on the Dava platform.
% special kind of application known as a server serves and supports clients on a
network. 2xamples of servers are eb servers, proxy servers, mail servers, and print
servers. %nother specialized program is a servlet. % servlet can almost be thought of
as an applet that runs on the server side. Dava #ervlets are a popular choice for
building interactive web applications, replacing the use of /8" scripts. #ervlets are
similar to applets in that they are runtime extensions of applications. "nstead of
working in browsers, though, servlets run within Dava eb servers, configuring or
tailoring the server.
$ow does the %-" support all these kinds of programs@ "t does so with
packages of software components that provides a wide range of functionality. 2very
full implementation of the Dava platform gives you the following features'
T#e esse!ti,(s' ,bjects, strings, threads, numbers, input and output, data
structures, system properties, date and time, and so on.
App(ets' The set of conventions used by applets.
Net)o*i!-' .&9s, T/- )Transmission /ontrol -rotocol*, .3- ).ser 3ata
gram -rotocol* sockets, and "- )"nternet -rotocol* addresses.
_____________________________________________________________________
MITS, MCA2009-12
47
_____________________________________________________________________
I!te!,tio!,(i=,tio!' $elp for writing programs that can be localized for users
worldwide. -rograms can automatically adapt to specific locales and be displayed
in the appropriate language.
Sec&it.' Both low level and high level, including electronic signatures, public
and private key management, access control, and certificates.
So"t),e co+po!e!ts' Snown as DavaBeans
T:
, can plug into existing
component

Object sei,(i=,tio!' %llows lightweight persistence and communication via
&emote :ethod "nvocation )&:"*.
D,v, D,t,b,se Co!!ectivit. 8DD<C
T'
9' -rovides uniform access to a wide
range of relational databases.
The Dava platform also has %-"s for ;3 and M3 graphics, accessibility, servers,
collaboration, telephony, speech, animation, and more. The following figure depicts
what is included in the Dava ; #3S.
Ho) /i(( D,v, Tec#!o(o-. C#,!-e '. 0i"eF
e canHt promise you fame, fortune, or even a job if you learn the Dava
programming language. #till, it is likely to make your programs better and re!uires
less effort than other languages. e believe that Dava technology will help you do the
following'
_____________________________________________________________________
MITS, MCA2009-12
48
_____________________________________________________________________
1et st,te% 6&ic*(.' %lthough the Dava programming language is a powerful
object-oriented language, itHs easy to learn, especially for programmers already
familiar with / or /TT.
/ite (ess co%e' /omparisons of program metrics )class counts, method
counts, and so on* suggest that a program written in the Dava programming
language can be four times smaller than the same program in /TT.
/ite bette co%e' The Dava programming language encourages good coding
practices, and its garbage collection helps you avoid memory leaks. "ts object
orientation, its DavaBeans component architecture, and its wide-ranging, easily
extendible %-" let you reuse other peopleHs tested code and introduce fewer
bugs.
Deve(op po-,+s +oe 6&ic*(.' Qour development time may be as
much as twice as fast versus writing the same program in /TT. hy@ Qou
write fewer lines of code and it is a simpler programming language than
/TT.
Avoi% p(,t"o+ %epe!%e!cies )it# 1BBG P&e D,v,' Qou can keep your
program portable by avoiding the use of libraries written in other
languages. The 644U -ure Dava
T:
-roduct /ertification -rogram has a
repository of historical process manuals, white papers, brochures, and
similar materials online.
/ite o!ceE &! ,!.)#ee' Because 644U -ure Dava programs are compiled
into machine-independent byte codes, they run consistently on any Dava platform.
Distib&te so"t),e +oe e,si(.' Qou can upgrade applets easily from a
central server. %pplets take advantage of the feature of allowing new classes to be
loaded Bon the fly,C without recompiling the entire program.
OD<C
:icrosoft ,pen 3atabase /onnectivity ),3B/* is a standard programming
interface for application developers and database systems providers. Before ,3B/
_____________________________________________________________________
MITS, MCA2009-12
49
_____________________________________________________________________
became a de facto standard for indows programs to interface with database systems,
programmers had to use proprietary languages for each database they wanted to
connect to. 1ow, ,3B/ has made the choice of the database system almost irrelevant
from a coding perspective, which is as it should be. %pplication 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 ,3B/ %dministrator in /ontrol -anel, you can specify the
particular database that is associated with a data source that an ,3B/ application
program is written to use. Think of an ,3B/ data source as a door with a name on it.
2ach door will lead you to a particular database. 0or example, the data source named
#ales 0igures might be a #V9 #erver database, whereas the %ccounts -ayable data
source could refer to an %ccess database. The physical database referred to by
a data source can reside anywhere on the 9%1.
The ,3B/ system files are not installed on your system by indows I?.
&ather, they are installed when you setup a separate database application, such as
#V9 #erver /lient or +isual Basic >.4. hen the ,3B/ icon is installed in /ontrol
-anel, it uses a file called ,3B/"1#T.399. "t is also possible to administer your
,3B/ data sources through a stand-alone program called ,3B/%3:.2F2. There is
a 6G-bit and a M;-bit version program and each maintains a separate list of odbc data
storage
0rom a programming perspective, the beauty of ,3B/ 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 doesnHt change
whether it talks to ,racle or #V9 #erver. e only mention these two as an example.
There are ,3B/ drivers available for several dozen popular database systems. 2ven
2xcel spreadsheets and plain text files can be turned into data sources. The operating
system uses the &egistry information written by ,3B/ %dministrator to determine
which low-level ,3B/ drivers are needed to talk to the data source )such as the
interface to ,racle or #V9 #erver*. The loading of the ,3B/ drivers is transparent to
_____________________________________________________________________
MITS, MCA2009-12
50
_____________________________________________________________________
the ,3B/ application program. "n a clientNserver environment, the ,3B/ %-" 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 ,3B/ is that it isnHt as efficient
as talking directly to the native database interface. ,3B/ has had many detractors
make the charge that it is too slow. :icrosoft has always claimed that the critical
factor in performance is the !uality of the driver software that is used. "n our humble
opinion, this is true. The availability of good ,3B/ drivers has improved a great deal
recently. %nd anyway, the criticism about performance is somewhat analogous to
those who said that compilers would never match the speed of pure assembly
language. :aybe not, but the compiler )or ,3B/* gives you the opportunity to write
cleaner programs, which means you finish sooner. :eanwhile, computers get faster
every year.
DD<C
"n an effort to set an independent database standard %-" for Dava( #un
:icrosystems developed Dava 3atabase /onnectivity, or D3B/. D3B/ offers a
generic #V9 database access mechanism that provides a consistent interface to a
variety of &3B:#s. This consistent interface is achieved through the use of Bplug-inC
database connectivity modules, or drivers. "f a database vendor wishes to have D3B/
support, he or she must provide the driver for each platform that the database and Dava
run on.
To gain a wider acceptance of D3B/, #un based D3B/Hs framework on
,3B/. %s you discovered earlier in this chapter, ,3B/ has widespread support on a
variety of platforms. Basing D3B/ on ,3B/ will allow vendors to bring D3B/
drivers to market much faster than developing a completely new connectivity
solution.
D3B/ was announced in :arch of 6IIG. "t was released for a I4 day public
review that ended Dune W, 6IIG. Because of user input, the final D3B/ v6.4
specification was released soon after.
_____________________________________________________________________
MITS, MCA2009-12
51
_____________________________________________________________________
The remainder of this section will cover enough information about D3B/ for
you to know what it is about and how to use it effectively. This is by no means a
complete overview of D3B/. That would fill an entire book.
DD<C 1o,(s
0ew software packages are designed without goals in mind. D3B/ is one that,
because of its many goals, drove the development of the %-". These goals, in
conjunction with early reviewer feedback, have finalized the D3B/ class library into a
solid framework for building database applications in Dava.
The goals that were set for D3B/ 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 D3B/ are as follows'
1. SH0 0eve( API
The designers felt that their main goal was to define a #V9 interface for Dava.
%lthough not the lowest database interface level possible, it is at a low enough level
for higher-level tools and %-"s to be created. /onversely, it is at a high enough level
for application programmers to use it confidently. %ttaining this goal allows for future
tool vendors to BgenerateC D3B/ code and to hide many of D3B/Hs complexities from
the end user.
2. SH0 Co!"o+,!ce
#V9 syntax varies as you move from database vendor to database vendor. "n
an effort to support a wide variety of vendors, D3B/ will allow any !uery 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.
M. DD<C +&st be i+p(e+e!t,( o! top o" co++o! %,t,b,se i!te",ces
_____________________________________________________________________
MITS, MCA2009-12
52
_____________________________________________________________________
The D3B/ #V9 %-" must BsitC on top of other common #V9 level %-"s. This
goal allows D3B/ to use existing ,3B/ level drivers by the use of a software
interface. This interface would translate D3B/ calls to ,3B/ and vice versa.
$. Povi%e , D,v, i!te",ce t#,t is co!siste!t )it# t#e est o" t#e D,v, s.ste+
Because of DavaHs acceptance in the user community thus far, the designers
feel that they should not stray from the current design of the core Dava system.
:. Ieep it si+p(e
This goal probably appears in all software design goal listings. D3B/ is no
exception. #un felt that the design of D3B/ should be very simple, allowing for only
one method of completing a task per mechanism. %llowing duplicate functionality
only serves to confuse the users of the %-".
>. Use sto!-E st,tic t.pi!- )#eeve possib(e
#trong typing allows for more error checking to be done at compile time(
also, less error appear at runtime.
?. Ieep t#e co++o! c,ses si+p(e
Because more often than not, the usual #V9 calls used by the programmer are
simple #292/THs, "1#2&THs, 3292T2Hs and .-3%T2Hs, these !ueries should be simple to
perform with D3B/. $owever, more complex #V9 statements should also be
possible.
0inally we decided to proceed the implementation using Dava networking. %nd
for dynamically updating the cache table we go for :# %ccess database.
Dava ha two things' a programming language and a platform.
Dava is a high-level programming language that is all of the following
#imple %rchitecture-neutral
,bject-oriented -ortable
3istributed $igh-performance
_____________________________________________________________________
MITS, MCA2009-12
53
_____________________________________________________________________
"nterpreted multithreaded
&obust 3ynamic
#ecure
Dava is also unusual in that each Dava program is both compiled and
interpreted. ith a compile you translate a Dava program into an intermediate
language called Dava byte codes the platform-independent code instruction is passed
and run on the computer.
/ompilation happens just once( interpretation occurs each time the program is
executed. The figure illustrates how this works.
Qou can think of Dava byte codes as the machine code instructions for the Dava
+irtual :achine )Dava +:*. 2very Dava interpreter, whether itHs a Dava development
tool or a eb browser that can run Dava applets, is an implementation of the Dava +:.
The Dava +: can also be implemented in hardware.
Dava byte codes help make Bwrite once, run anywhereC possible. Qou can
compile your Dava program into byte codes on my platform that has a Dava compiler.
The byte codes can then be run any implementation of the Dava +:. 0or example, the
same Dava program can run indows 1T, #olaris, and :acintosh.
U'0 Di,-,+s:
_____________________________________________________________________
MITS, MCA2009-12
54
Java
Program
Compilers
Interpreter
My Program
_____________________________________________________________________
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.
% .:9 system is represented using five different views that describe the
system from distinctly different perspective. 2ach view is defined by a set of diagram,
which is as follows.
Use 'o%e( ;ie)
This view represents the system from the users perspective.
The analysis representation describes a usage scenario from the end-users
perspective.
St&ct&,( +o%e( vie)
"n this model the data and functionality are arrived from inside
the system.
This model view models the static structures.
<e#,vio,( 'o%e( ;ie)
"t represents the dynamic of behavioral as parts of the
system, depicting the interactions of collection between various structural
elements described in the user model and structural model view.
I+p(e+e!t,tio! 'o%e( ;ie)
"n this the structural and behavioral as parts
of the system are represented as they are to be built.

$.3 Ovevie) o" Net)o*i!- TCP7IP St,c*s:
The T/-N"- stack is shorter than the ,#" one'
_____________________________________________________________________
MITS, MCA2009-12
55
_____________________________________________________________________
T/- is a connection-oriented protocol( .3- ).ser 3atagram -rotocol* is a
connectionless protocol.
IP %,t,-,+Js:
The "- layer provides a connectionless and unreliable delivery system. "t
considers each datagram independently of the others. %ny association between
datagram must be supplied by the higher layers. The "- layer supplies a checksum that
includes its own header. The header includes the source and destination addresses.
The "- layer handles routing through an "nternet. "t is also responsible for breaking up
large datagram into smaller ones for transmission and reassembling them at the other
end.
UDP:
.3- is also connectionless and unreliable. hat it adds to "- is a checksum
for the contents of the datagram and port numbers. These are used to give a
clientNserver model - see later.
_____________________________________________________________________
MITS, MCA2009-12
56
_____________________________________________________________________
TCP:
T/- supplies logic to give a reliable connection-oriented protocol above "-. "t
provides a virtual circuit that two processes can use to communicate.
I!te!et ,%%esses
"n order to use a service, you must be able to find it. The "nternet uses an
address scheme for machines so that they can be located. The address is a M; bit
integer which gives the "- address. This encodes a network "3 and more addressing.
The network "3 falls into various classes according to the size of the network address.
Net)o* ,%%ess:
/lass % uses W bits for the network address with ;> bits left over for other
addressing. /lass B uses 6G bit network addressing. /lass / uses ;> bit network
addressing and class 3 uses all M;.
S&b!et ,%%ess:
"nternally, the .1"F network is divided into sub networks. Building 66 is
currently on one sub network and uses 64-bit addressing, allowing 64;> different
hosts.
Host ,%%ess:
W bits are finally used for host addresses within our subnet. This places a limit
of ;?G machines that can be on the subnet.
Tot,( ,%%ess:
The M; bit address is usually written as > integers separated by dots.
_____________________________________________________________________
MITS, MCA2009-12
57
_____________________________________________________________________
Pot ,%%esses
% service exists on a host, and is identified by its port. This is a 6G bit number.
To send a message to a server, you send it to the port for that service of the host that it
is running on. This is not location transparencyJ /ertain of these ports are Xwell
knownX.
Soc*ets:
% socket is a data structure maintained by the system to handle network
connections. % socket is created using the call socket. "t returns an integer that is like a
file descriptor. "n fact, under indows, this handle can be used with &ead 0ile and rite
0ile functions.
Yinclude OsysNtypes.hP
Yinclude OsysNsocket.hP
int socket)int family, int type, int protocol*(
$ere XfamilyX will be %05"12T for "- communications, protocol will be zero,
and type will depend on whether T/- or .3- is used. Two processes wishing to
communicate over a network create a socket each. These are similar to two
ends of a pipe - but the actual pipe does not yet exist.
D3ee C#,t:
D0ree /hart is a free 644U Dava chart library that makes it easy for developers
to display professional !uality charts in their applications. D0ree/hartKs extensive
feature set includes'
% consistent and well-documented %-", supporting a wide range of chart
types(
% flexible design that is easy to extend, and targets both server-side and client-
side applications(
_____________________________________________________________________
MITS, MCA2009-12
58
_____________________________________________________________________
#upport for many output types, including #wing components, image files
)including -18 and D-28*, and vector graphics file formats )including -30, 2-# and
#+8*(
D0ree/hart is Xopen sourceX or, more specifically, free software. "t is
distributed under the terms of the 81. 9esser 8eneral -ublic 9icence )98-9*, which
permits use in proprietary applications.
1. ',p ;is&,(i=,tio!s:
/harts showing values that relate to geographical areas. #ome examples
include' )a* population density in each state of the .nited #tates, )b* income per
capita for each country in 2urope, )c* life expectancy in each country of the world.
The tasks in this project include' #ourcing freely redistributable vector outlines for the
countries of the world, statesNprovinces in particular countries ).#% in particular, but
also other areas*(
/reating an appropriate dataset interface )plus default implementation*, a
rendered, and integrating this with the existing FQ-lot class in D0ree/hart(
Testing, documenting, testing some more, documenting some more.
2. Ti+e Seies C#,t I!te,ctivit.
"mplement a new )to D0ree/hart* feature for interactive time series charts ---
to display a separate control that shows a small version of %99 the time series data,
with a sliding XviewX rectangle that allows you to select the subset of the time series
data to display in the main chart.
3. D,s#bo,%s
There is currently a lot of interest in dashboard displays. /reate a flexible
dashboard mechanism that supports a subset of D0ree/hart chart types )dials, pies,
thermometers, bars, and linesNtime series* that can be delivered easily via both Dava
eb #tart and an applet.
_____________________________________________________________________
MITS, MCA2009-12
59
_____________________________________________________________________
$. Popet. E%itos
The property editor mechanism in D0ree/hart only handles a small subset of
the properties that can be set for charts. 2xtend )or reimplement* this mechanism to
provide greater end-user control over the appearance of the charts.
CHAPTER C :
________________________________TESTIN1
:.1 INTRODUCTION
So"t),e Testi!-:
#oftware testing is a critical element of software !uality assurance and
represents the ultimate reuse of specification. 3esign and code testing represents
interesting anomaly for the software during earlier definition and development phase,
it was attempted to build software from an abstract concept to tangible
implementation.
_____________________________________________________________________
MITS, MCA2009-12
60
_____________________________________________________________________
The testing phase involves, testing of the development of the system using
various techni!ues such as hite Box Testing, /ontrol #tructure Testing.

:.2 Testi!- 3&!%,+e!t,(s:
:.2.1. /#ite <o4 5 <(,c* <o4 Testi!-
/#ite <o4 Testi!-:
hite box testing is a test case design method that uses the control
structure of the procedural design to derive test cases. %fter performing white
box testing it was identified that
The 9eave &ecording #ystem )9&#* software guarantees that all independent
paths within the modules have been exercised at least once.
"t has been exercised all logical decisions on their true and false sides.
"t was tested to execute all loops at their boundaries and within their
,perational bounds.
"t was tested for the internal data structures to ensure their validity.
<(,c* bo4 Testi!-' is the testing process in which tester can perform testing on an
application without having any internal structural knowledge of application.
.sually Test 2ngineers are involved in the black box testing.
:.2.2. Co!to( St&ct&e Testi!- :
The following tests were conducted and it was noted that the B/B# is
performing them well.
Basic path Testing
_____________________________________________________________________
MITS, MCA2009-12
61
_____________________________________________________________________
/ondition Testing
3ata 0low Testing
9oop Testing
Black box testing methods focuses on the functional re!uirements of the
software by conducting black box testing using the methods 2!uivalence partitioning
Boundary +alue %nalysis and /ause-2ffect-8raphing techni!ues.
0unctional validity of 9&# checked.
/hecked the isolation of the boundaries of a class.
The tolerance of the system for the data rates and data volumes.
:.3 Testi!- St,te-ies:
% strategy for software testing must accommodate low-level tests that are
necessary to verify that a small source code segment has been correctly implemented
as well as high level against customer re!uirements.
;ei"ic,tio! ,!% ;,(i%,tio!:
+erification is a 0undamental concept in the software design. +erification
refers to the set of activities that ensure that software correctly implements a specific
function. +alidation refers to a different set of activities that ensures that software that
has been build is a traceable to customers. +alidation is nothing but the process of
using software in live environment in order to find errors.
+erification is typically done in two steps'
vei"ic,tio! o" t#e e6&ie+e!ts: +erification that the software
re!uirement definition satisfies the customer needs.
;ei"ic,tio! o" t#e %esi-!' +erification that the design satisfies the
re!uirements definition.

_____________________________________________________________________
MITS, MCA2009-12
62
_____________________________________________________________________
U!it Testi!-:
The tests that occur as part of unit tests are illustrated schematically in the
module interface is tested to ensure that information properly flows into and out of the
program unit under test. The local data structure is examined to ensure that data stored
temporarily maintains its integrity during all steps in an algorithmKs
execution.Boundary conditions are tested to ensure that the module operates properly
at boundaries established to limit or restrict processing. %ll independent paths )basis
paths* through the control structure are exercised to ensure that all statements in a
module have been executed at least once. %nd finally, all error handling paths are
tested.
Tests of data flow across a module interface are re!uired before any other test
isinitiated. "f data do not enter and exit properly, all other tests are moot. "n
addition,local data structures should be exercised and the local impact on global data
should be ascertained )if possible* during unit testing.#elective testing of execution
paths is an essential task during the unit test.
Test cases should be designed to uncover errors due to erroneous
computations, incorrect comparisons, or improper control flow. Basis path and loop
testing are effective techni!ues for uncovering a broad array of path errors.
%mong the more common errors in computation are
)6* :isunderstood or incorrect arithmetic precedence
);* :ixed mode operations
)M* "ncorrect initialization
)>* -recision inaccuracy
)?* "ncorrect symbolic representation of an expression.
C.c(o+,tic Co+p(e4it. Testi!-
/yclomatic complexity is a software metric that provides a !uantitative
measure of the logical complexity of a program. hen used in the context of the basis
path testing method, the value computed for cyclomatic complexity defines the
_____________________________________________________________________
MITS, MCA2009-12
63
_____________________________________________________________________
number of independent paths in the basis set of a program and provides us with an
upper bound for the number of tests that must be conducted to ensure that all
statements have been executed at least once.
%n independent path is any path through the program that introduces at least
one new set of processing statements or a new condition. hen stated in terms of a
flow "f hile The structured constructs in flow graph form' here each circle
represents one or more nonbranching -39 or source code statements
$ow do we know how many paths to look for@ The computation of cyclomatic
complexity provides the answer.
/yclomatic complexity has a foundation in graph theory and provides us with
an extremely useful software metric. /omplexity is computed in one of three ways'
1. The number of regions of the flow graph correspond to the cyclomatic
complexity.
2. /yclomatic complexity, V)G*, for a flow graph, G, is defined as
V)G* Z E 5 N T ;
where E is the number of flow graph edges, N is the number of flow graph
nodes.
3. /yclomatic complexity, V)G*, for a flow graph, G, is also defined as
V)G* Z P T 6
3(o) c#,t)
_____________________________________________________________________
MITS, MCA2009-12
64
_____________________________________________________________________
0ig' 0low chart
_____________________________________________________________________
MITS, MCA2009-12
65
_____________________________________________________________________
3(o) 1,p#:
3i-: 3(o) 1,p#
_____________________________________________________________________
MITS, MCA2009-12
66
1
2
3
4
4*1
4*2
6
5
_____________________________________________________________________
3o+&(,:
V(G)=E-N+2
+9,8-2
+1-2
+3
./01+P-1
+2-1
+3
:.$ S,+p(e Test C,ses
:.$.1 Test c,sesE s&itesE scipts ,!% sce!,ios
% test case is a software testing document, which consists of event, action,
input, output, expected result and actual result. /linically defined )"222 W;I-6IIW* a
test case is an input and an expected result. This can be as pragmatic as Kfor condition
x your derived result is yK, whereas other test cases described in more detail the input
scenario and what results might be expected. "t can occasionally be a series of steps
)but often steps are contained in a separate test procedure that can be exercised against
multiple test cases, as a matter of economy* but with one expected result or expected
outcome. The optional fields are a test case "3, test step or order of execution number,
related re!uirement)s*, depth, test category, author, and check boxes for whether the
test is automatable and has been automated. 9arger test cases may also contain
prere!uisite states or steps, and descriptions. % test case should also contain a place
for the actual result. These steps can be stored in a word processor document,
spreadsheet, database or other common repository. "n a database system, you may also
be able to see past test results and who generated the results and the system
_____________________________________________________________________
MITS, MCA2009-12
67
_____________________________________________________________________
/onfiguration used to generate those results. These past results would usually
be stored in a separate table.
The term test script is the combination of a test case, test procedure and test
data. "nitially the term was derived from the byproduct of work created by automated
regression test tools. Today, test scripts can be manual, automated or a combination of
both.
The most common term for a collection of test cases is a test suite. The test
suite often also contains more detailed instructions or goals for each collection of test
cases. "t definitely contains a section where the tester identifies the system
configuration used during testing. % group of test cases may also contain prere!uisite
states or steps, and descriptions of the following tests.
/ollections of test cases are sometimes incorrectly termed a test plan. They
might correctly be called a test specification. "f se!uence is specified, it can be called
a test script, scenario or procedure.
_____________________________________________________________________
MITS, MCA2009-12
68
_____________________________________________________________________
:.$ TESTCASES:
$ere we tested some sample test cases on the project. There are
Test C,se1' ,pen client % and selecet a file that is B.tetC and verify the data will be
displaying in the specified window.
E4pecte% <e#,vio' 3isplay the path of the file paraperly or not.
Obseve <e#,vio' 3isplayed.
St,t&s: -aseed.
:.1 3i-.Testc,se "o %isp(,.i!- c(ie!t A
_____________________________________________________________________
MITS, MCA2009-12
69
_____________________________________________________________________
Testc,se2' /lick submit button and verifying the specified file transfaring from
/lient % to #erver.
E4pecte% <e#,vio' +erifying #pecified link given to the /lient %.
St,t&s' -assed.
:.2 3i-.Testc,se "o se(ect D,t, ,e T,!s"e
_____________________________________________________________________
MITS, MCA2009-12
70
_____________________________________________________________________
Testc,se3' +erify the #ever reveving a file from /lient %.
E4pecte% <e#,vio' 3isplay two systems #ymbols and Transfaring the "nformation
node % to respected to #erver.
St,t&s:-assed.
:.3 3i-.Test C,se "o D,t, T,!s"e
_____________________________________________________________________
MITS, MCA2009-12
71
_____________________________________________________________________
Testc,se $: +erify the status of the recived data and bandwidth.
E4pecte% <e#,vio' "t is the data are 3isplayed or not and Bandwidth is 3isplay into
3aysimal format.
Obseve <e#,vio' 3ispalyed.
St,t&s: -assed.
:.$ 3i-.Testc,se "o st,t&s o" t#e b,!%)i%t#
_____________________________________________________________________
MITS, MCA2009-12
72
_____________________________________________________________________
Testc,se ?' /heck the lifetime of 1ode%.
E4pecte%<e#,vio ' verifing the data is recived or not and /hecking the Bandwidth
and lifetime and also the displaythe lifetime in the daysimal format.
St,t&s'-assed.
:.: 3i-.Testc,se "o (i"eti+e !o%e A
_____________________________________________________________________
MITS, MCA2009-12
73
_____________________________________________________________________
Testc,se G' /heck the lifetime of the server
E4pecte%<e#,vio' "n #erver we verifying the signal is avaliable or
not.if signal is not available failure will be occur
Obseve <e#,vio' not 3isplayed.
St,t&s' failed
:.> 3i-.Testc,se "o (i"eti+e !o%e A ",i(e%
_____________________________________________________________________
MITS, MCA2009-12
74
_____________________________________________________________________
CHAPTER C >
_______CONC0USION AND 3UTURE /ORI
CONC0USION:
"n this paper, we develop an any cast packet-forwarding scheme to reduce the
event-reporting delay and to prolong the lifetime of wireless sensor networks
employing asynchronous sleep-wake scheduling. #pecially , we study two
optimization problems. 0irst, when the wake-up rates of the sensor nodes are given,
we develop an efficient and distributed algorithm to minimize the expected event-
reporting delay from all sensor nodes to the sink. #econd, using a specific definition
of the network lifetime, we study the lifetime-maximization problem to optimally
control the sleep-wake scheduling policy and the any cast policy, in order to maximize
the network lifetime subject to a upper limit on the expected end-to-end delay. ,ur
numerical results suggest that the proposed solution can substantially outperform prior
heuristic solutions in the literature under practical scenarios where there are
obstructions in the coverage area of the wireless sensor network.
3UTURE /ORI:
0or future work, we plan to generalize our solution to take into account non-
-oisson wake-up processes and other lifetime definitions.
_____________________________________________________________________
MITS, MCA2009-12
75
_____________________________________________________________________
CHAPTER -?
____________________________RE3ERENCES
RE3ERENCES:
<6= D. Sim, F. 9in, 1. B. #hroff, and -. #inha, .,n :aximizing the 9ifetime of 3elay-
#ensitive ireless #ensor 1etworks with %nycast,. in -roceedings of "222
"10,/,:, )-heonix, %[*, %pril ;44W.
<;= Q.-/. Tseng, /.-#. $su, and T.-Q. $sieh, .-ower-#aving -rotocols for "222
W4;.66-Based :ulti-$op %d $oc 1etworks,. /omputer 1etworks, vol. >M, pp.
M6L.MML, ,ct. ;44M.
<M= . Qe, $. $eidemann, and 3. 2strin, .:edium %ccess /ontrol with /oordinated
%daptive #leeping for ireless #ensor 1etworks,. "222N%/: Transactions on
1etworking, vol. 6;, pp. >IM.?4G, Dune ;44>.
<>= T. van 3am and S. 9angendoen, .%n %daptive 2nergy-2f5cient :%/ -rotocol for
ireless #ensor 1etworks,. in -roc. #en#ys, pp. 6L6.6W4, 1ovember ;44M.
<?= 8. 9u, B. Srishnamachari, and /. #. &aghavendra, .%n %daptive 2nergy-2f5cient
and 9ow-9atency :%/ for 3ata 8athering in ireless #ensor 1etworks,. in -roc.
"-3-#, pp. ;;>.;M6, %pril ;44>.
<G= D. 2lson, 9. 8irod, and 3. 2strin, .0ine-grained network time synchronization
using reference broadcasts,. #"8,-# ,per. #yst. &ev., vol. MG, no. #", pp. 6>L.6GM,
;44;.
<L= 2. #hih, #.-$. /ho, 1. "ckes, &. :in, %. #inha, %. ang, and %. /handrakasan,
.-hysical layer driven protocol and algorithm design for energy-ef5cient wireless
sensor networks,. in -roc. :obi/om, ;446.
<W= :. 1osovic and T. Todd, .9ow power rendezvous and &0"3 wakeup for
embedded wireless networks,. in %nnual "222 /omputer /ommunications orkshop,
;444.
_____________________________________________________________________
MITS, MCA2009-12
76
_____________________________________________________________________
<I= D. -olastre, D. $ill, and 3. /uller, .+ersatile 9ow -ower :edia %ccess for ireless
#ensor 1etworks,. in -roc. #en#ys, pp. I?.64L, 1ovember ;44>.
<64= D. -olastre, D. $ill, -. 9evis, D. [hao, 3. /uller, and #. #henker, .% .nifying 9ink
%bstraction for ireless #ensor 1etworks,. in -roc. #en#ys, pp. LG.WI, 1ovember
;44?.
<66= :. [orzi and &. &. &ao, .8eographic &andom 0orwarding )8e&a0* for %d $oc
and #ensor 1etworks' 2nergy and 9atency -erformance,. "222 transactions on
:obile /omputing, vol. ;, pp. M>I.MG?, ,ctober ;44M.
<6;= :. [orzi and &. &. &ao, .8eographic &andom 0orwarding )8e&a0* for %d hoc
and #ensor 1etworks' :ultihop -erformance,. "222 transactions on :obile
/omputing, vol. ;, pp. MML.M>W, ,ctober ;44M.
<6M= &. &. /houdhury and 1. $. +aidya, .:%/-9ayer %nycasting in %d $oc
1etworks,. #"8/,:: /omputer /ommunication &eview, vol. M>, pp. L?.W4,
Danuary ;44>.
<6>= #. Dain and #. &. 3as, .2xploiting -ath 3iversity in the 9ink 9ayer in ireless
%d $oc 1etworks,. in -roc. o:o:, pp. ;;.M4, Dune ;44L.
<6?= #. 9iu, S.-. 0an, and -. #inha, ./:%/' %n 2nergy 2f5cient :%/ 9ayer
-rotocol .sing /onvergent -acket 0orwarding for ireless #ensor 1etworks,. in
-roc. #2/,1, )#an 3iego, /%*, Dune ;44L.
_____________________________________________________________________
MITS, MCA2009-12
77
_____________________________________________________________________
APPENDIK
________________________A. USER 'ANUA0
.ser manual provides easier interaction with the system who does not know
actual design of the system. This is generally useful to the client or third party to
perform basic operations and installation of the system.
Ho) t#e e4ec&tio! )i(( be t,*e! "o t#is pojectF
E 0irst select the /lient % window)batch file*
E %gain select the /lient B window)batch file*
E #elect the /lient / window)batch file*
E #elect the /lient 3 window)batch file*
E #elect the /lient 2 window)batch file*
E #elect the server window)batch file*
E "n /lient % window click the Browse button
E Then select the Text file one
E Then text file one is display in /lient window.
E Then click the submit button
E Then we are seen in server window 3ata are Transfer
E "n server window 3ata are Transfer and 3isplay the Bandwidth
E "n server window lifetime are also displayed
_______________________________<.3OR'S
_____________________________________________________________________
MITS, MCA2009-12
78
_____________________________________________________________________
A%%i!- : /i!%o)s:
0o,%i!- C(ie!t A )i!%o)
DESCRIPTION: ,pen /lient % and select a file that isC.textC and verify the data will
be displaying in the specified window
3i- <1: Disp(,. t#e C(ie!t A )i!%o)
_____________________________________________________________________
MITS, MCA2009-12
79
_____________________________________________________________________
A%%i!- t#e C(ie!t < )i!%o)
Desciptio!:
This 0orm is the %dding the /lient B window
3i- <2: Disp(,. t#e C(ie!t < )i!%o)
_____________________________________________________________________
MITS, MCA2009-12
80
_____________________________________________________________________
0o,%i!- t#e C(ie!t C )i!%o)
Desciptio!:
This 0ormis the %dding the /lient / window
3i- <3: Disp(,. t#e C(ie!t C )i!%o)
_____________________________________________________________________
MITS, MCA2009-12
81
_____________________________________________________________________
0o,%i!- t#e C(ie!t D )i!%o)
Desciptio!:
This 0orm is the %dding the /lient 3 window
3i- <$: Disp(,. t#e C(ie!t D )i!%o)
_____________________________________________________________________
MITS, MCA2009-12
82
_____________________________________________________________________
0o,%i!- t#e C(ie!t E )i!%o)
Desciptio!:
This 0orm is the %dding the /lient 2 window
3i- <:'Disp(,. t#e C(ie!t E )i!%o)
_____________________________________________________________________
MITS, MCA2009-12
83
_____________________________________________________________________
A%%i!- C(ie!t A )i!%o) i! %,t, ,e se(ect
Desciptio!:
This 0orm is the loading data to /lient window \%H.
3i- <>: Disp(,. t#e C(ie!t A /i!%o) I! D,t, Ae Se(ect
_____________________________________________________________________
MITS, MCA2009-12
84
_____________________________________________________________________
D,t, ,e %isp(,. %isp(,.e% i! be(o) )i!%o)
Desciptio!:
This form data are displayed in the below diagram.
3i- <?: D,t, ,e %isp,(.e% i! t#is )i!%o)
_____________________________________________________________________
MITS, MCA2009-12
85
_____________________________________________________________________
0o,%i!- )i!%o) i! seve )i!%o) %,t, ,e t,!s"e
Desciptio!:
This 0orm is %dding window in server window data are transfer
3i- <@: Disp(,. T#e Seve /i!%o) D,t, Ae T,!s"e
_____________________________________________________________________
MITS, MCA2009-12
86
_____________________________________________________________________
0o,%i!- i! seve )i!%o) %,t, ",i(e%
Desciptio!:
This 0orm is %dding in server window data failed'
3i- <A: Disp(,. T#e Seve /i!%o) D,t, 3,i(e%
_____________________________________________________________________
MITS, MCA2009-12
87
_____________________________________________________________________
A%%i!- C(ie!t D )!%o)
Desciptio!'
This 0orm is %dding client 3 window and Browse data.click submit botton
0ig b 64. 3isplaying /lient 3 window data are select
_____________________________________________________________________
MITS, MCA2009-12
88
_____________________________________________________________________
D,t, ,e se(ect i! t#e c(ie!t D )i!%o)
Desciptio!:
This 0orm 3ata are select in this client 3 window
0ig b 66. 3isplaying /lient 3 window data are select
_____________________________________________________________________
MITS, MCA2009-12
89
_____________________________________________________________________
I! Seve /i!%o) %,t, ,e T,!s"e C(ie!t D to T,!s"e
Desciptio!:
This 0orm #hows the transformation of 3ata 0orm 1ode 3 to 3estination
0ig b 6;. 3ata Transfer from 1ode 3 to destination
_____________________________________________________________________
MITS, MCA2009-12
90
_____________________________________________________________________
C.REPORT
C(ie!t A Repot:
Desciptio!:
This report is generated client % running the network batch file.
3i- C1: Disp(,.i!- C(ie!t A epot
_____________________________________________________________________
MITS, MCA2009-12
91
_____________________________________________________________________
C(ie!t < Repot:
Desciptio!:
This report is generated /lient B running the network batch file
0ig c;. 3isplaying /lient B &eport
_____________________________________________________________________
MITS, MCA2009-12
92
_____________________________________________________________________
C(ie!t C Repot:
Desciptio!:
This report is generated /lient / running the network batch file

0ig / M. 3isplaying /lient / window
_____________________________________________________________________
MITS, MCA2009-12
93
_____________________________________________________________________
C(ie!t D Repot:
Desciptio!:
This report is generated /lient 3 running the network batch file
0ig / >. 3isplaying /lient 3 window
_____________________________________________________________________
MITS, MCA2009-12
94
_____________________________________________________________________
C(ie!t E Repot:
Desciptio!:
This report is generated /lient 2 running the network batch file
0ig / ?.3isplaying /lient 2 window
_____________________________________________________________________
MITS, MCA2009-12
95
_____________________________________________________________________
A%%i!- Seve Repot:
Desciptio!:
This report is generated #erver window running the network batch file
0ig cG. 3isplaying server window
_____________________________________________________________________
MITS, MCA2009-12
96
_____________________________________________________________________
C(ie!t A D,t, ,e se(ect Repot:
Desciptio!:
This report is generated /lient % data are select window running the network
batch file
0ig c G.3isplaying /lient % window data are select
_____________________________________________________________________
MITS, MCA2009-12
97
_____________________________________________________________________
D,t, ,e t,!s"e No%e A to Desti!,tio! Repot)
Desciptio!: 3ata are transfer 1ode % to 3estination &eport
0ig /L.Text file are transfer report
_____________________________________________________________________
MITS, MCA2009-12
98

Documentation

Uploaded by

Document Information

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

Documentation

Uploaded by

Copyright:

Available Formats

MINIMIZING DELAY AND MAXIMIZING LIFETIME FOR WIRELESS

SENSOR NETWORKS WITH NYCAST

You might also like