Wireless Sensor Networks (WSNs) are increasingly used in data-intensive applications such as micro-climate monitoring, precision agriculture, and audio/video surveillance. A key challenge faced by data-intensive WSNs is to transmit all the data generated within an application’s lifetime to the base station despite the fact that sensor nodes have limited power supplies. We propose using low-cost disposable mobile relays to reduce the energy consumption of data-intensive WSNs. Our approach differs from previous work in two main aspects. First, it does not require complex motion planning of mobile nodes, so it can be implemented on a number of low-cost mobile sensor platforms. Second, we integrate the energy consumption due to both mobility and wireless transmissions into a holistic optimization framework. We present efficient distributed implementations for each algorithm that require only limited, localized synchronization. Because we do not necessarily compute an optimal topology, our final routing tree is not necessarily optimal. However, our simulation results show that our algorithms significantly outperform the best existing solutions.

Excerpt

1. Introduction

WSNS have been deployed in a variety of data-intensive applications including microclimate and habitat monitoring, precision agriculture, and audio/video surveillance. A moderate-size WSN can gather up to 1 Gb/year from a biological habitat. Due to the limited storage capacity of sensor nodes, most data must be transmitted to the base station for archiving and analysis. However, sensor nodes must operate on limited power supplies such as batteries or small solar panels. Therefore, a key challenge faced by data-intensive WSNs is to minimize the energy consumption of sensor nodes so that all the data generated within the lifetime of the application can be transmitted to the base station. Several different approaches have been proposed to significantly reduce the energy cost of WSNs by using the mobility of nodes. A robotic unit may move around the network and collect data from static nodes through one-hop or multihop transmissions. The mobile node may serve as the base station or a “data mule” that transports data between static nodes and the base station. Mobile nodes may also be used as relays that forward data from source nodes to the base station. Several movement strategies for mobile relays have been studied in. Although the effectiveness of mobility in energy conservation is demonstrated by previous studies, the following key issues have not been collectively addressed. First, the movement cost of mobile nodes is not accounted for in the total network energy consumption. Instead, mobile nodes are often assumed to have a replenishable energy supply which is not always feasible due to the constraints of the physical environment. Second, complex motion planning of mobile nodes is often assumed in existing solutions which introduces significant design complexity and manufacturing costs. In, mobile nodes need to repeatedly compute optimal motion paths and change their location, their orientation and/or speed of movement. Such capabilities are usually not supported by existing low-cost mobile sensor platforms. For instance, Robomote nodes are designed using 8-bit CPUs and small batteries that only last for about 25 minutes in full motion.

In this paper, we use low-cost disposable mobile relays to reduce the total energy consumption of data-intensive WSNs. Different from mobile base station or data mules, mobile relays do not transport data; instead, they move to different locations and then remain stationary to forward data along the paths from the sources to the base station. Thus, the communication delays can be significantly reduced compared with using mobile sinks or data mules. Moreover, each mobile node performs a single relocation unlike other approaches which require repeated relocations.

Our approach is motivated by the current state of mobile sensor platform technology. On the one hand, numerous low-cost mobile sensor prototypes such as Robomote, Khepera, and FIRA are now available. Their manufacturing cost is comparable to that of typical static sensor platforms. As a result, they can be massively deployed in a network and used in a disposable manner. Our approach takes advantage of this capability by assuming that we have a large number of mobile relay nodes. On the other hand, due to low manufacturing cost, existing mobile sensor platforms are typically powered by batteries and only capable of limited mobility. Consistent with this constraint, our approach only requires one-shot relocation to designated positions after deployment. Compared with our approach, existing mobility approaches typically assume a small number of powerful mobile nodes, which does not exploit the availability of many low-cost mobile nodes.

1.1. Objective of the Project

2. Literature Survey

An Analysis of a Large Scale Habitat Monitoring Application

Habitat and environmental monitoring is a driving application for wireless sensor networks. We present an analysis of data from a second generation sensor networks deployed during the summer and autumn of 2003. During a 4 month deployment, these net-works, consisting of 150 devices, produced unique datasets for both systems and biological analysis. This paper focuses on nodal and network performance, with an emphasis on lifetime, reliability, and the static and dynamic aspects of single and multi-hop networks. We compare the results collected to expectations set during the design phase: we were able to accurately predict lifetime of the single-hop network, but we underestimated the impact of multi-hop traffic overhearing and the nuances of power source selection. While initial packet loss data was commensurate with lab experiments, over the duration of the deployment, reliability of the back-end infrastructure and the transit network had a dominant impact on overall network performance. Finally, we evaluate the physical design of the sensor node based on deployment experience and a post mortem analysis. The results shed light on a number of design issues from network deployment, through selection of power sources to optimizations of routing decisions.

We have presented the system architecture, implementation, and deployment of two wireless sensor networks. These networks used a total of 150 nodes in both single-hop and multi-hop configurations. During four months of operation, they compiled a rich dataset with more than 650,000 records that are valuable both to biologists and computer scientists. This paper analyzed this data from a systems perspective of lifetime, network structure, routing and yield. Lifetime estimates based on micro-benchmarks accurately predicted the single-hop mote longevity but diverged for multi-hop motes. We believe that moisture penetrating enclosures caused attrition in both networks. This obscures the fundamental roles that overhearing and routing packets have on longevity. A sense-and-send application design and best-effort routing layer was sufficient for the single-hop network. About 50% of the losses in the multi-hop routing tree, can be modeled as a deterministic factor; the remaining losses show the expected exponential decay of yield as a function of depth. Each of the packet loss components represents area for improvement, and may need to be addressed differently –custody transfer mechanisms may be a suitable way to handle the deterministic losses, while link-level retransmissions would eliminate the depth-dependent loss. Motes with smaller battery capacities were observed routing on behalf of motes with larger battery capacities. While routing could be done preferentially by motes with larger batteries, reducing the burden of large packet preambles represents a larger potential savings. Time synchronized low power listening stacks, such as the ones being developed by Crossbow, begin to address this by synchronizing senders and receivers sufficiently to allow receivers to remain asleep during more of the preamble reception time, awaking slightly before the arrival of the packet payload. After the initial setup, the network exhibited stable periods of organization punctuated by periods of increased re-parenting rates. This was caused primarily from the incremental addition of motes. In general, more than 80% of the packets were routed using less than 20% of the links. Across quantized 6-hour time intervals, in over 50% there were no re-parenting in the network, and in more than 75% there were less than 10% re-parentings. Base station availability, which reflects the reliability of the Windows laptops, background services for logging data into Postgres, and photo-voltaic power was lower than expected and resulted in lost data. We have another year of experience with the practical challenges of deploying sensor networks in the field. We have identified the need to eliminate the logistical overheads required to install each mote, and the need for field tools for in-situ installation and monitoring. We discussed the potential value of logging sensor readings to local storage to allow post-deployment reclamation of data that was not successfully sent to the base station. While not a replacement for reliable networking, it may be appropriate for deployments where motes can be reclaimed in good working condition. Reclamation in our case was complicated because motes were often moved and buried by animals. Working indoors and in the field allows sensor network researchers to compare laboratory results with observations from the real world over a period of months. In a number of cases (e.g., lifetime prediction for the single-hop network), the micro-benchmarks transferred well into a deployed application. In other cases (e.g., the lower packet yields from the multi-hop network) we saw an interesting departure from the expected behavior. Often these new behaviors emerged as the network was reconfigured, expanded, or re-deployed; others were an artifact of aging. Many of those behaviors cannot be observed without building complete systems and deploying them in realistic conditions.

EnviroMic: Towards Cooperative Storage and Retrieval in Audio Sensor Networks

This paper presents the design, implementation, and evaluation of EnviroMic, a novel distributed acoustic monitoring, storage, and trace retrieval system. Audio represents one of the least exploited modalities in sensor networks to date. The relatively high frequency and large size of audio traces motivate distributed algorithms for coordinating recording tasks, reducing redundancy of data stored by nearby sensors, filtering out silence, and balancing storage utilization in the network. Applications of acoustic monitoring with EnviroMic range from the study of mating rituals and social behavior of animals in the wild to audio surveillance of military targets. EnviroMic is designed for disconnected operation, where the luxury of having a base station cannot be assumed. We implement the system on a Tiny OS-based platform and systematically evaluate its performance through both indoor test bed experiments and a preliminary outdoor deployment. Results demonstrate up to a 4-fold improvement in effective storage capacity of the network compared to uncoordinated recording.

In this paper, we presented EnviroMic, a novel distributed acoustic monitoring, storage, and trace retrieval system. The long-term disconnected service model for our target applications calls for a design which stores recorded acoustic data in the network. EnviroMic employs a cooperative recording scheme and a distributed balanced storage mechanism to address unique challenges arising from high-frequency acoustic sampling and high-volume sensory data storage. Data chunks recorded are tagged with timestamps, node IDs, and event (file) IDs to facilitate data retrieval. EnviroMic is implemented on MicaZ motes running Tiny OS. Evaluation results drawn from both indoor and outdoor deployments demonstrate the efficacy of our design. Significant system (storage) lifetime improvement is observed compared to baseline algorithms at a modest overhead. We are currently working on a large-scale long-term deployment of EnviroMic for bird vocalization monitoring and recording. We plan to investigate more intelligent storage balancing algorithms, such as data compression and global (as opposed to local greedy) load-balancing. In a long-term deployment, reliability is apparently a concern. Defunct or lost motes can cause data loss. In this case, a controlled data redundancy may become desirable.

An Evaluation of Multi-Resolution Storage for Sensor Networks

Wireless sensor networks enable dense sensing of the environment, offering unprecedented opportunities for observing the physical world. Centralized data collection and analysis adversely impact sensor node lifetime. Previous sensor network research has, therefore, focused on in network aggregation and query processing, but has done so for applications where the features of interest are known a priori. When features are not known a priori, as is the case with many scientific applications in dense sensor arrays, efficient support for multi-resolution storage and iterative, drill-down queries is essential. Our system demonstrates the use of in-network wavelet-based summarization and progressive aging of summaries in support of long-term querying in storage and communication-constrained networks. We evaluate the performance of our linux implementation and show that it achieves: (a) low communication overhead for multi-resolution summarization, (b) highly efficient drill-down search over such summaries, and (c) efficient use of network storage capacity through load-balancing and progressive aging of summaries Ideally, a search and storage system for sensor networks should have the following properties: (a) low communication overhead, (b) efficient search for a broad range of queries, and (c) long-term storage capability. In this paper, we present the design and evaluation of DIMENSIONS, a system that constructs multi-resolution summaries and progressively ages them to meet these goals. This system uses wavelet compression techniques to construct summaries at different spatial resolutions that can be queried efficiently using drill-down techniques. We demonstrate the generality of our system by studying the query accuracy for a variety of queries on a wide-area precipitation sensor dataset. A significant contribution of this work is extending our system to storage-constrained large-scale sensor networks. We use a combination of progressive aging of summaries, and load-sharing by cluster-rotation to achieve long-term query processing under such constraints. Our proposal for progressive aging includes schemes that are applicable to a spectrum of application deployment conditions: a training algorithm where training sets can be obtained and a greedy algorithm for others. A comparison shows that both the training and greedy scheme perform within 2% of an optimal scheme. While the training scheme performs better than the greedy scheme in practice, the latter performs within 1% of training for an appropriate choice of aging parameters. We demonstrate the load-sharing properties of our system in a sensor network emulator. In our future work, our primary focus will be deploying our system in a real sensor network deployment scenario.

Energy Efficient Schemes for Wireless Sensor Networks with Multiple Mobile Base Stations

Ideally, a search and storage system for sensor networks should have the following properties: (a) low communication overhead, (b) efficient search for a broad range of queries, and (c) long-term storage capability. In this paper, we present the design and evaluation of DIMENSIONS, a system that constructs multi-resolution summaries and progressively ages them to meet these goals. This system uses wavelet compression techniques to construct summaries at different spatial resolutions that can be queried efficiently using drill-down techniques. We demonstrate the generality of our system by studying the query accuracy for a variety of queries on a wide-area precipitation sensor dataset. A significant contribution of this work is extending our system to storage-constrained large-scale sensor networks. We use a combination of progressive aging of summaries, and load-sharing by cluster-rotation to achieve long-term query processing under such constraints. Our proposal for progressive aging includes schemes that are applicable to a spectrum of application deployment conditions: a training algorithm where training sets can be obtained and a greedy algorithm for others. A comparison shows that both the training and greedy scheme perform within 2% of an optimal scheme. While the training scheme performs better than the greedy scheme in practice, the latter performs within 1% of training for an appropriate choice of aging parameters. We demonstrate the load-haring properties of our system in a sensor network emulator. In our future work, our primary focus will be deploying our system in a real sensor network deployment scenario.

Joint Mobility and Routing for Lifetime Elongation in Wireless Sensor Networks

Although many energy efficient/conserving routing protocols have been proposed for wireless sensor networks, the concentration of data traffic towards a small number of base stations remains a major threat to the network lifetime. The main reason is that the sensor nodes located near a base station have to relay data for a large part of the network and thus deplete their batteries very quickly. The solution we propose in this paper suggests that the base station be mobile; in this way, the nodes located close to it change over time. Data collection protocols can then be optimized by taking both base station mobility and multi-hop routing into account. We first study the former, and conclude that the best mobility strategy consists in following the periphery of the network (we assume that the sensors are deployed within a circle). We then consider jointly mobility and routing algorithms in this case, and show that a better routing strategy uses a combination of round routes and short paths. We provide a detailed analytical model for each of our statements, and corroborate it with simulation results. We show that the obtained improvement in terms of network lifetime is in the order of 500%.

In this paper, we have first shown that, with a static base station, the sensor nodes located close to the base station suffer premature battery depletion, leading to an early disconnection of the network. In order to better balance the load among the nodes, we have proposed that the base station be mobile and demonstrated that the traffic experienced by the most heavily loaded nodes is reduced by a factor of 3 with only an arbitrary mobility strategy. These results suggest that base station mobility is indeed a strategy that deserves to be considered when optimizing the network lifetime. In order to further exhibit the benefit of the base station mobility, we have compared different mobility strategies and obtained the optimum one under the assumption of certain routing strategies. We have also explained how routing can be fine-tuned to leverage on the trajectory of the base station; in particular, we have shown how to better exploit the transmission capabilities of the nodes located at the periphery of the network. Our joint mobility and routing strategy achieves a 500% improvement of the network lifetime. For all these scenarios, we have developed an analytical model, corroborated by a set of simulations. We are currently considering an interesting complement to the work in this paper, where we perform an analysis based on a discrete model (i.e., a graph). In addition, we are preparing field tests that could better justify the benefit of the base station mobility. In terms of other future work, we intend to study how data aggregation protocols can be efficiently integrated into the proposed scheme. We will also explore how a set of mobile base stations can be coordinated to further optimize the data collection. More generally, an intriguing research area would consist in further exploiting the capabilities of base stations for optimizing various aspects of sensor networks.

Exploiting Sink Mobility for Maximizing Sensor Networks Lifetime

This paper explores the idea of exploiting the mobility of data collection points (sinks) for the purpose of increasing the lifetime of a wireless sensor network with energy-constrained nodes. We give a novel linear programming formulation for the joint problems of determining the movement of the sink and the sojourn time at different points in the network that induce the maximum network lifetime. Differently from previous solutions, our objective function maximizes the overall network lifetime (here defined as the time till the first node “dies” because of energy depletion) rather than minimizing the energy consumption at the nodes. For wireless sensor networks with up to 256 nodes our model produces sink movement patterns and sojourn times leading to a network lifetime up to almost five times that obtained with a static sink. Simulation results are performed to determine the distribution of the residual energy at the nodes over time. These results confirm that energy consumption varies with the current sink location, being the nodes more drained those in the proximity of the sink. Furthermore, the proposed solution for computing the sink movement results in a fair balancing of the energy depletion among the network nodes.

In this paper, we propose a method for using a mobile sink to increase network lifetime. We use a linear optimization model to determine which nodes should be visited by the sink and for how long in order to maximize the time till the first node in the network dies because of energy depletion. Our model directly aims at maximizing network lifetime instead of reducing total energy consumption during data communication, which is what was done in previous solutions. It is demonstrated that almost 500% improvement in network lifetime can be achieved by deploying a sink that moves according to the patterns provided by our model instead of using a static sink. The network energy consumption over time is also studied, which helps validating the effectiveness of the proposed method. Encouraged by the current results we propose future research that considers more complex circumstances. In particular, the model and the experiments will consider more realistic assumptions which include random data generation rates, data generation rates based on moving targets, multiple mobile sinks and random network topologies. In addition, we will investigate the impact of mobile sinks on network performance such as latency and bandwidth usage.

Controllably Mobile Infrastructure for Low Energy Embedded Networks

We discuss the use of mobility to enhance network performance for a certain class of applications in sensor networks. A major performance bottleneck in sensor networks is energy since it is impractical to replace the batteries in embedded sensor nodes post-deployment. A significant portion of the energy expenditure is attributed to communications and, in particular, the nodes close to the sensor network gateways used for data collection typically suffer a large overhead as these nodes must relay data from the remaining network. Even with compression and in-network processing to reduce the amount of communicated data, all the processed data must still traverse these nodes to reach the gateway. We discuss a network infrastructure based on the use of controllably mobile elements to reduce the communication energy consumption at the energy constrained nodes and, thus, increase useful network lifetime. In addition, our approach yields advantages in delay-tolerant networks and sparsely deployed networks. We first show how our approach helps reduce energy consumption at battery constrained nodes. Second, we describe our system prototype which utilizes our proposed approach to improve the energy performance. As part of the prototyping effort, we experienced several interesting design choices and trade-offs that affect system capabilities and performance. We describe many of these design challenges and discuss the algorithms developed for addressing these. In particular, we focus on network protocols and motion control strategies. Our methods are tested using a practical system and do not assume idealistic radio range models or operation in unobstructed environments.

In this paper, we explored the possibility of using a mobile device for data transfer in sensor networks. The motivation for doing this was to save energy in the embedded sensor nodes and increase the useful service time of a deployed system. The key intuition was that using a mobile node to establish shorter data routes reduces the data relaying overhead, especially at the nodes close to the data egress point in the network. We showed analytical calculations which help develop this intuition further. We then described many of the challenges in the design of such a system, both for networking and for motion control, and presented the design choices made in our prototype. The network protocols we designed can even be used in other systems which do not use controllably mobile nodes but rely on available mobile elements in the deployment environment which follow approximately fixed trajectories, such as public transportation vehicles. The energy and lifetime advantages may come at a cost of increased data latency in many cases and this approach is advantageous for applications where latency is acceptable. An important conclusion to be drawn from this investigation is that, for the same total amount of data communicated, moving data physically may sometimes be more energy efficient than transmitting it over a wireless route, as was shown in Fig. 2, even when the energy consumed by the mobile node for locomotion is provided by the deployed system itself. Further, this approach changes the points of energy consumption in the system and makes adding energy to the system, on a long term basis, easier than in a static network with no mobile components. Energy expenditure at a small number of mobile nodes is used to reduce the energy expenditure in a much larger number of sensor network components. Thus, the total energy may not be provided up front, but is added to the system over a period of time, such as through environmental energy harvesting. We expect this approach to be advantageous in many long term sensor network deployments.

Rendezvous Design Algorithms for Wireless Sensor Networks with a Mobile Base Station

Recent research shows that significant energy saving can be achieved in wireless sensor networks with a mobile base station that collects data from sensor nodes via short-range communications. However, a major performance bottleneck of such WSNs is the significantly increased latency in data collection due to the low movement speed of mobile base stations. To address this issue, we propose a rendezvous-based data collection approach in which a subset of nodes serves as the rendezvous points that buffer and aggregate data originated from sources and transfer to the base station when it arrives. This approach combines the advantages of controlled mobility and in-network data caching and can achieve a desirable balance between network energy saving and data collection delay. We propose two efficient rendezvous design algorithms with provable performance bounds for mobile base stations with variable and fixed tracks, respectively. The effectiveness of our approach is validated through both theoretical analysis and extensive simulations.

In this paper, we study the rendezvous-based data collection in WSNs with a mobile base station. We develop two efficient rendezvous design algorithms with constant approximation ratios. The first algorithm is based on SMT and allows the data to be efficiently aggregated at RPs while shortening the data collection tour of BS. The second algorithm is designed for mobile BSs that must move along fixed tracks. Based on the analysis on the optimal structure of connection between sources and a fixed track, we can find efficient RPs within bounded BS tour on the track. Simulation results show that both algorithms can achieve satisfactory performance under a range of settings. The theoretical performance bounds of the algorithms are also validated through simulations.

Multiple Controlled Mobile Elements (Data Mules) for Data Collection in Sensor Networks

Recent research has shown that using a mobile element to collect and carry data mechanically from a sensor network has many advantages over static multihop routing. We have an implementation as well employing a single mobile element. But the network scalability and traffic may make a single mobile element insufficient. In this paper we investigate the use of multiple mobile elements. In particular, we present load balancing algorithm which tries to balance the number of sensor nodes each mobile element services. We show by simulation the benefits of load balancing.

Deployments of sensor networks are taking place. Using a controlled mobile element is a promising approach to collect data from these sensor nodes. We showed that as the network scales, using a single mobile element may not be sufficient, and would require multiple of them. The sensor nodes and (or) the mobile elements may not be uniformly placed in practice, necessitating the use of load balancing, so that each mobile element as far as possible, serves the same number of sensor nodes. We gave a load balancing algorithm, and described the mechanism these multiple mobile elements can be used. Finally we presented simulation results justifying our approach. The work presented here can be extended in many directions. For load balancing, we can remove the assumption that each sensor node can talk to at least one mobile element. This will lead to case similar to Figure 1. Now, when doing load balancing, we also need to consider the cost of doing multihop, to reach either of the mobile elements. We can also extend to cases where mobile elements can be added or removed once the system is in operation. Node dynamics can be handled by running the initialization and load balancing periodically.

Data Mules: Modeling a Three-Tier Architecture for Sparse Sensor networks

This paper presents and analyzes three-tier architecture for collecting sensor data in sparse sensor networks. Our approach exploits the presence of mobile entities (called MULEs) present in the environment. When in close range, MULEs pick up data from the sensors, buffer it, and deliver it to wired access points. This can lead to substantial power savings at the sensors as they only have to transmit over a short-range. This paper focuses on a simple analytical model for understanding performance as system parameters are scaled. Our model assumes a two-dimensional random walk for mobility and incorporates key system variables such as number of MULEs, sensors and access points. The performance metrics observed are the data success rate (the fraction of generated data that reaches the access points), latency and the required buffer capacities on the sensors and the MULEs. The modeling and simulation results can be used for further analysis and provide certain guidelines for deployment of such systems.

In this paper we have presented architecture to connect sparse sensor networks at the cost of higher latencies. The main idea is to utilize the motion of the entities that are already present in an environment to provide a low-power transport medium for sensor data. After introducing the architecture, the focus of the paper was on presenting a simple analytical model based upon two-dimensional random walks to provide insight into various performance metrics (data success rate, latency and buffer sizes). Our key observations are:

- The sensor buffer requirement is inversely proportional to q mules.

- The MULE buffer requirement is inversely proportional to both q mules and q AP.

-When the sensor buffer is large, the buffer capacity on each MULE can be traded off with the number of MULEs to maintain the same data success rate.

- The change in the buffer capacity on each sensor needs to be greater than the change in the

number of MULEs to keep the same data success rate.

- The average latency at a sensor for the drop tail protocol is inversely proportional to the number of MULEs.

- For a large sensor buffer, the average latency at the sensor (drop head protocol) drops dramatically with increase in the number of MULEs; for small sensor buffers, the decrease is linear.

The average latency on a MULE is inversely proportional to the number of access points in the system. We plan to expand our work in a couple of directions. One is to develop a more complete stochastic model to address some of the current simplifications such as infinite bandwidth, random-walk mobility model and error-free communication. Here we plan to use ideas from queuing theory and renewal processes. From the protocol point of view, MULE-to-MULE communication and reliability using acknowledgments are issues of interest. Another limitation of the current work is the assumption that the sensors have to continuously listen in order to identify a MULE s presence. Approaches to increase the sleep time for sensors, such as reduced duty cycle, need to be explored along with their effect on system performance.

3. Analysis

3.1. Introduction

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering, information systems and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system the software development process.

3.2. Existing System

Wireless Multimedia Sensor Networks (WMSNs) has many challenges such as nature of wireless media and multimedia information transmission. Consequently traditional mechanisms for network layers are no longer acceptable or applicable for these networks.

3.3. Proposed System

We use low-cost disposable mobile relays to reduce the total energy consumption of data-intensive WSNs. Different from mobile base station or data mules, mobile relays do not transport data; instead, they move to different locations and then remain stationary to forward data along the paths from the sources to the base station. Thus, the communication delays can be significantly reduced compared with using mobile sinks or data mules. Moreover, each mobile node performs a single relocation unlike other approaches which require repeated relocations.

3.4. PROCESS MODEL USED WITH JUSTIFICATION

SDLC (Umbrella Model) :

Abbildung in dieser Leseprobe nicht enthalten

SDLC is nothing but Software Development Life Cycle. It is a standard which is used by software industry to develop good software.

Stages in SDLC :

- Requirement Gathering
- Analysis
- Designing
- Coding
- Testing
- Maintenance

Requirements Gathering stage :

The requirements gathering process takes as its input the goals identified in the high-level requirements section of the project plan. Each goal will be refined into a set of one or more requirements. These requirements define the major functions of the intended application, define operational data areas and reference data areas, and define the initial data entities. Major functions include critical processes to be managed, as well as mission critical inputs, outputs and reports. A user class hierarchy is developed and associated with these major functions, data areas, and data entities. Each of these definitions is termed a Requirement. Requirements are identified by unique requirement identifiers and, at minimum, contain a requirement title and textual description.

Abbildung in dieser Leseprobe nicht enthalten

These requirements are fully described in the primary deliverables for this stage: the Requirements Document and the Requirements Traceability Matrix (RTM). The requirements document contains complete descriptions of each requirement, including diagrams and references to external documents as necessary. Note that detailed listings of database tables and fields are not included in the requirements document.

The title of each requirement is also placed into the first version of the RTM, along with the title of each goal from the project plan. The purpose of the RTM is to show that the product components developed during each stage of the software development lifecycle are formally connected to the components developed in prior stages.

In the requirements stage, the RTM consists of a list of high-level requirements, or goals, by title, with a listing of associated requirements for each goal, listed by requirement title. In this hierarchical listing, the RTM shows that each requirement developed during this stage is formally linked to a specific product goal. In this format, each requirement can be traced to a specific product goal, hence the term requirements traceability.

The outputs of the requirements definition stage include the requirements document, the RTM, and an updated project plan.

- Feasibility study is all about identification of problems in a project.

- No. of staff required to handle a project is represented as Team Formation, in this case only modules are individual tasks will be assigned to employees who are working for that project.

- Project Specifications are all about representing of various possible inputs submitting to the server and corresponding outputs along with reports maintained by administrator.

Analysis Stage :

The planning stage establishes a bird's eye view of the intended software product, and uses this to establish the basic project structure, evaluate feasibility and risks associated with the project, and describe appropriate management and technical approaches.

Abbildung in dieser Leseprobe nicht enthalten

The most critical section of the project plan is a listing of high-level product requirements, also referred to as goals. All of the software product requirements to be developed during the requirements definition stage flow from one or more of these goals. The minimum information for each goal consists of a title and textual description, although additional information and references to external documents may be included. The outputs of the project planning stage are the configuration management plan, the quality assurance plan, and the project plan and schedule, with a detailed listing of scheduled activities for the upcoming Requirements stage, and high level estimates of effort for the out stages.

Designing Stage :

The design stage takes as its initial input the requirements identified in the approved requirements document. For each requirement, a set of one or more design elements will be produced as a result of interviews, workshops, and/or prototype efforts. Design elements describe the desired software features in detail, and generally include functional hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams, pseudo code, and a complete entity-relationship diagram with a full data dictionary. These design elements are intended to describe the software in sufficient detail that skilled programmers may develop the software with minimal additional input.

When the design document is finalized and accepted, the RTM is updated to show that each design element is formally associated with a specific requirement. The outputs of the design stage are the design document, an updated RTM, and an updated project plan.

Development (Coding) Stage :

The development stage takes as its primary input the design elements described in the approved design document. For each design element, a set of one or more software artifacts will be produced. Software artifacts include but are not limited to menus, dialogs, data management forms, data reporting formats, and specialized procedures and functions. Appropriate test cases will be developed for each set of functionally related software artifacts, and an online help system will be developed to guide users in their interactions with the software.

Abbildung in dieser Leseprobe nicht enthalten

The RTM will be updated to show that each developed artifact is linked to a specific design element, and that each developed artifact has one or more corresponding test case items. At this point, the RTM is in its final configuration. The outputs of the development stage include a fully functional set of software that satisfies the requirements and design elements previously documented, an online help system that describes the operation of the software, an implementation map that identifies the primary code entry points for all major system functions, a test plan that describes the test cases to be used to validate the correctness and completeness of the software, an updated RTM, and an updated project plan.

Integration & Test Stage :

During the integration and test stage, the software artifacts, online help, and test data are migrated from the development environment to a separate test environment. At this point, all test cases are run to verify the correctness and completeness of the software. Successful execution of the test suite confirms a robust and complete migration capability. During this stage, reference data is finalized for production use and production users are identified and linked to their appropriate roles. The final reference data (or links to reference data source files) and production user list are compiled into the Production Initiation Plan.

The outputs of the integration and test stage include an integrated set of software, an online help system, an implementation map, a production initiation plan that describes reference data and production users, an acceptance plan which contains the final suite of test cases, and an updated project plan.

- Installation & Acceptance Test:

During the installation and acceptance stage, the software artifacts, online help, and initial production data are loaded onto the production server. At this point, all test cases are run to verify the correctness and completeness of the software. Successful execution of the test suite is a prerequisite to acceptance of the software by the customer.

After customer personnel have verified that the initial production data load is correct and the test suite has been executed with satisfactory results, the customer formally accepts the delivery of the software.

Abbildung in dieser Leseprobe nicht enthalten

The primary outputs of the installation and acceptance stage include a production application, a completed acceptance test suite, and a memorandum of customer acceptance of the software. Finally, the PDR enters the last of the actual labor data into the project schedule and locks the project as a permanent project record. At this point the PDR "locks" the project by archiving all software items, the implementation map, the source code, and the documentation for future reference.

Maintenance :

Outer rectangle represents maintenance of a project, Maintenance team will start with requirement study, understanding of documentation later employees will be assigned work and they will under go training on that particular assigned category.

For this life cycle there is no end, it will be continued so on like an umbrella (no ending point to umbrella sticks).

3.5. Software Requirement Specification

3.5.1. Overall Description

A Software Requirements Specification (SRS) – a requirements specification for a software system is a complete description of the behavior of a system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. In addition to use cases, the SRS also contains non-functional requirements. Nonfunctional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints).

System requirements specification: A structured collection of information that embodies the requirements of a system. A business analyst, sometimes titled system analyst, is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development lifecycle domain, the BA typically performs a liaison function between the business side of an enterprise and the information technology department or external service providers. Projects are subject to three sorts of requirements:

- Business requirements describe in business terms what must be delivered or accomplished to provide value.

- Product requirements describe properties of a system or product (which could be one of several ways to accomplish a set of business requirements.)

- Process requirements describe activities performed by the developing organization. For instance, process requirements could specify .Preliminary investigation examine project feasibility, the likelihood the system will be useful to the organization. The main objective of the feasibility study is to test the Technical, Operational and Economical feasibility for adding new modules and debugging old running system. All system is feasible if they are unlimited resources and infinite time. There are aspects in the feasibility study portion of the preliminary investigation:

- ECONOMIC FEASIBILITY

A system can be developed technically and that will be used if installed must still be a good investment for the organization. In the economical feasibility, the development cost in creating the system is evaluated against the ultimate benefit derived from the new systems. Financial benefits must equal or exceed the costs. The system is economically feasible. It does not require any addition hardware or software. Since the interface for this system is developed using the existing resources and technologies available at NIC, There is nominal expenditure and economical feasibility for certain.

- Operational Feasibility

Proposed projects are beneficial only if they can be turned out into information system. That will meet the organization’s operating requirements. Operational feasibility aspects of the project are to be taken as an important part of the project implementation. This system is targeted to be in accordance with the above-mentioned issues. Beforehand, the management issues and user requirements have been taken into consideration. So there is no question of resistance from the users that can undermine the possible application benefits. The well-planned design would ensure the optimal utilization of the computer resources and would help in the improvement of performance status.

- TECHNICAL FEASIBILITY

Earlier no system existed to cater to the needs of ‘Secure Infrastructure Implementation System’. The current system developed is technically feasible. It is a web based user interface for audit workflow at NIC-CSD. Thus it provides an easy access to .the users. The database’s purpose is to create, establish and maintain a workflow among various entities in order to facilitate all concerned users in their various capacities or roles. Permission to the users would be granted based on the roles specified. Therefore, it provides the technical guarantee of accuracy, reliability and security.

3.5.2. External Interface Requirements

User Interface

The user interface of this system is a user friendly Java Graphical User Interface.

Hardware Interfaces

The interaction between the user and the console is achieved through Java capabilities.

Software Interfaces

The required software is JAVA1.6.

Operating Environment

Windows XP, Linux.

HARDWARE REQUIREMENTS:

Abbildung in dieser Leseprobe nicht enthalten

SOFTWARE REQUIREMENTS:

Abbildung in dieser Leseprobe nicht enthalten

4. Design

UML diagrams

The Unified Modeling Language allows the software engineer to express an analysis model using the modeling notation that is governed by a set of syntactic semantic and pragmatic rules.

A UML system is represented using five different views that describe the system from distinctly different perspective. Each view is defined by a set of diagram, which is as follows.

- User Model View

i. This view represents the system from the users perspective.

ii. The analysis representation describes a usage scenario from the end-users perspective.

- Structural Model view

i. In this model the data and functionality are arrived from inside the system.

ii. This model view models the static structures.

- Behavioral Model View

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

- Implementation Model View

In this the structural and behavioral as parts of the system are represented as they are to be built.

- Environmental Model View

In this the structural and behavioral aspects of the environment in which the system is to be implemented are represented.

Class diagram:-

The class diagram is the main building block of object oriented modelling. It is used both for general conceptual modeling of the systematics of the application, and for detailed modelling translating the models into programming code. Class diagrams can also be used for data modeling. The classes in a class diagram represent both the main objects, interactions in the application and the classes to be programmed.

A class with three sections.

In the diagram, classes are represented with boxes which contain three parts:

- The upper part holds the name of the class
- The middle part contains the attributes of the class
- The bottom part gives the methods or operations the class can take or undertake

Abbildung in dieser Leseprobe nicht enthalten

Use case diagram:-

A use case diagram at its simplest is a representation of a user's interaction with the system and depicting the specifications of a use case. A use case diagram can portray the different types of users of a system and the various ways that they interact with the system. This type of diagram is typically used in conjunction with the textual use case and will often be accompanied by other types of diagrams as well.

Abbildung in dieser Leseprobe nicht enthalten

Sequence Diagram:-

A sequence diagram is a kind of interaction diagram that shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart. A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario. Sequence diagrams are typically associated with use case realizations in the Logical View of the system under development. Sequence diagrams are sometimes called event diagrams, event scenarios, and timing diagrams.

Sequence diagram for Admin:

Abbildung in dieser Leseprobe nicht enthalten

Collaborative diagram:-

A collaboration diagram describes interactions among objects in terms of sequenced messages. Collaboration diagrams represent a combination of information taken from class, sequence, and use case diagrams describing both the static structure and dynamic behavior of a system.

Collaborative diagram:

Abbildung in dieser Leseprobe nicht enthalten

Component Diagram

In the Unified Modeling Language, a component diagram depicts how components are wired together to form larger components and or software systems. They are used to illustrate the structure of arbitrarily complex systems

Components are wired together by using an assembly connector to connect the required interface of one component with the provided interface of another component. This illustrates the service consumer - service provider relationship between the two components.

Component diagram:

Abbildung in dieser Leseprobe nicht enthalten

Deployment Diagram

A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on nodes. To describe a web site, for example, a deployment diagram would show what hardware components ("nodes") exist (e.g., a web server, an application server, and a database server), what software components ("artifacts") run on each node (e.g., web application, database), and how the different pieces are connected (e.g. JDBC, REST, RMI).

The nodes appear as boxes, and the artifacts allocated to each node appear as rectangles within the boxes. Nodes may have sub nodes, which appear as nested boxes. A single node in a deployment diagram may conceptually represent multiple physical nodes, such as a cluster of database servers.

Deployment diagram:

Abbildung in dieser Leseprobe nicht enthalten

Activity diagram:

Activity diagram is another important diagram in UML to describe dynamic aspects of the system. It is basically a flow chart to represent the flow form one activity to another activity. The activity can be described as an operation of the system.

So the control flow is drawn from one operation to another. This flow can be sequential, branched or concurrent.

Activity diagram:

Abbildung in dieser Leseprobe nicht enthalten

5. Implementation

5.1. Modules

1. Mobile Relays
2. Sink
3. Source Nodes
4. Tree Optimization

5.2. Module description

Mobile Relays:

The network consists of mobile relay nodes along with static base station and data sources. Relay nodes do not transport data; instead, they move to different locations to decrease the transmission costs. We use the mobile relay approach in this work. Goldenberg et al. [13] showed that an iterative mobility algorithm where each relay node

moves to the midpoint of its neighbors converges on the optimal solution for a single routing path. However, they do not account for the cost of moving the relay nodes. In mobile nodes decide to move only when moving is beneficial, but the only position considered is the midpoint of neighbors.

Sink:

The sink is the point of contact for users of the sensor network. Each time the sink receives a question from a user, it first translates the question into multiple queries and then disseminates the queries to the corresponding mobile relay, which process the queries based on their data and return the query results to the sink. The sink unifies the query results from multiple storage nodes into the final answer and sends it back to the user.

Source Nodes:

The source nodes in our problem formulation serve as storage points which cache the data gathered by other nodes and periodically transmit to the sink, in response to user queries. Such network architecture is consistent with the design of storage centric sensor networks [38]. Our problem formulation also considers the initial positions of nodes and the amount of data that needs to be transmitted from each storage node to the sink.

Tree Optimization:

We consider the sub problem of finding the optimal positions of relay nodes for a routing tree given that the topology is fixed. We assume the topology is a directed tree in which the leaves are sources and the root is the sink. We also assume that separate messages cannot be compressed or merged; that is, if two distinct messages of lengths m1 and m2 use the same link (si, sj ) on the path from a source to a sink, the total number of bits that must traverse link (si, sj ) is m1 + m2.

5.3. Introduction of technologies used

About Java:

Initially the language was called as “oak” but it was renamed as “java” in 1995.The primary motivation of this language was the need for a platform-independent (i.e. architecture neutral) language that could be used to create software to be embedded in various consumer electronic devices.

- Java is a programmer’s language
- Java is cohesive and consistent
- Except for those constraint imposed by the Internet environment. Java gives the programmer, full control

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

Importance of Java to the Internet

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

Applications and applets

An application is a program that runs on our Computer under the operating system of that computer. It is more or less like one creating using C or C++ .Java’s ability to create Applets makes it important. An Applet I san application, designed to be transmitted over the Internet and executed by a Java-compatible web browser. An applet I actually a tiny Java program, dynamically downloaded across the network, just like an image. But the difference is, it is an intelligent program, not just a media file. It can be react to the user input and dynamically change.

Java Architecture

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

Compilation of code

When you compile the code, the Java compiler creates machine code (called byte code)for a hypothetical machine called Java Virtual Machine(JVM). The JVM is supposed t executed the byte code. The JVM is created for the overcoming the issue of probability. The code is written and compiled for one machine and interpreted on all machines .This machine is called Java Virtual Machine.

Compiling and interpreting java source code.

Abbildung in dieser Leseprobe nicht enthalten

During run-time the Java interpreter tricks the byte code file into thinking that it is running on a Java Virtual Machine. In reality this could be an Intel Pentium windows 95 or sun SPARCstation running Solaris or Apple Macintosh running system and all could receive code from any computer through internet and run the Applets.

Simple:

Java was designed to be easy for the Professional programmer to learn and to use effectively. If you are an experienced C++ Programmer. Learning Java will oriented features of C++. Most of the confusing concepts from C++ are either left out of Java or implemented in a cleaner, more approachable manner. In Java there are a small number of clearly defined ways to accomplish a given task.

Object oriented

Java was not designed to be source-code compatible with any other language. This allowed the Java team the freedom to design with a blank state. One outcome of this was a clean usable, pragmatic approach to objects. The object model in Java is simple and easy to extend, while simple types, such as integers, are kept as high-performance non-objects.

Robust

The multi-platform environment of the web places extraordinary demands on a program, because the program must execute reliably in a variety of systems. The ability to create robust programs. Was given a high priority in the design of Java. Java is strictly typed language; it checks your code at compile time and runtime.

Java virtually eliminates the problems of memory management and deal location, which is completely automatic. In a well-written Java program, all run-time errors can and should be managed by your program.

AWT and Swings:

AWT:

Graphical User Interface:

The user interface is that part of a program that interacts with the user of the program. GUI is a type of user interface that allows users to interact with electronic devices with images rather than text commands. A class library is provided by the Java programming language which is known as Abstract Window Toolkit (AWT) for writing graphical programs. The Abstract Window Toolkit (AWT) contains several graphical widgets which can be added and positioned to the display area with a layout manager.

As the Java programming language, the AWT is not platform-independent. AWT uses system peers object for constructing graphical widgets. A common set of tools is provided by the AWT for graphical user interface design. The implementation of the user interface elements provided by the AWT is done using every platform's native GUI toolkit. One of the AWT's significance is that the look and feel of each platform can be preserved.

Components:

A graphical user interface is built of graphical elements called components. A component is an object having a graphical representation that can be displayed on the screen and that can interact with the user. Components allow the user to interact with the program and provide the input to the program. In the AWT, all user interface components are instances of class Component or one of its subtypes. Typical components include such items as buttons, scrollbars, and text fields.

Types of Components:

Abbildung in dieser Leseprobe nicht enthalten

Before proceeding ahead, first we need to know what containers are. After learning containers we learn all components in detail.

Containers:

Components do not stand alone, but rather are found within containers. In order to make components visible, we need to add all components to the container. Containers contain and control the layout of components. In the AWT, all containers are instances of class Container or one of its subtypes. Components must fit completely within the container that contains them. For adding components to the container we will use add () method.

Types of containers:

Abbildung in dieser Leseprobe nicht enthalten

Basic GUI Logic:

The GUI application or applet is created in three steps. These are:

- Add components to Container objects to make your GUI.

- Then you need to setup event handlers for the user interaction with GUI.

- Explicitly display the GUI for application.

A new thread is started by the interpreter for user interaction when an AWT GUI is displayed. When any event is received by this new thread such as click of a mouse, pressing of key etc then one of the event handlers is called by the new thread set up for GUI. One important point to note here is that the event handler code is executed within the thread.

Creating a Frame:

Method1:

In the first method we will be creating frame by extending Frame class which is defined in java.awt package. Following program demonstrate the creation of a frame.

import java.awt.*;

public class FrameDemo1 extends Frame

{

FrameDemo1()

{

setTitle("Label Frame");

setVisible(true);

setSize(500,500);

}

public static void main(String[] args)

{

new FrameDemo1 ();

}

In the above program we are using three methods:

setTitle: For setting the title of the frame we will use this method. It takes String as an argument which will be the title name.

SetVisible: For making our frame visible we will use this method. This method takes Boolean value as an argument. If we are passing true then window will be visible otherwise window will not be visible.

SetSize: For setting the size of the window we will use this method. The first argument is width of the frame and second argument is height of the frame.

Method 2:

In this method we will be creating the Frame class instance for creating frame window. Following program demonstrate Method2.

import java.awt.*;

public class FrameDemo2

{

public static void main(String[] args)

{

Frame f = new Frame();

f.setTitle("My first frame");

f.setVisible(true);

f.setSize(500,500);

}

Types of Components:

1) Labels :

This is the simplest component of Java Abstract Window Toolkit. This component is generally used to show the text or string in your application and label never perform any type of action.

Label l1 = new Label("One");

Label l2 = new Label("Two");

Label l3 = new Label("Three",Label.CENTER);

In the above three lines we have created three labels with the name “one, two, three”. In the third label we are passing two arguments. Second argument is the justification of the label. Now after creating components we will be adding it to the container.

add(l1);

add(l2);

add(l3);

We can set or change the text in a label by using the setText( ) method. You can obtain the current label by calling getText( ). These methods are shown here:

void setText(String str)

String getText( )

2) Buttons :

This is the component of Java Abstract Window Toolkit and is used to trigger actions and other events required for your application. The syntax of defining the button is as follows :

Button l1 = new Button("One");

Button l2 = new Button("Two");

Button l3 = new Button("Three");

We can change the Button's label or get the label's text by using the Button.setLabel(String) and Button.getLabel() method.

3) CheckBox:

A check box is a control that is used to turn an option on or off. It consists of a small box that can either contain a check mark or not. There is a label associated with each check box that describes what option the box represents. You change the state of a check box by clicking on it. The syntax of the definition of Checkbox is as follows :

Checkbox Win98 = new Checkbox("Windows 98/XP", null, true);

Checkbox winNT = new Checkbox("Windows NT/2000");

Checkbox solaris = new Checkbox("Solaris");

Checkbox mac = new Checkbox("MacOS");

The first form creates a check box whose label is specified in first argument and whose group is specified in second argument . If this check box is not part of a group, then cbGroup must be null. (Check box groups are described in the next section.) The value true determines the initial state of the check box is checked. The second form creates a check box with only one parameter.

To retrieve the current state of a check box, call getState( ). To set its state, call setState( ). You can obtain the current label associated with a check box by calling getLabel( ). To set the label, call setLabel( ). These methods are as follows:

boolean getState( )

void setState(boolean on)

String getLabel( )

void setLabel(String str)

Here, if on is true, the box is checked. If it is false, the box is cleared. The string passed in str becomes the new label associated with the invoking check box.

4) Radio Button:

This is the special case of the Checkbox component of Java AWT package. This is used as a group of checkboxes which group name is same. Only one Checkbox from a Checkbox Group can be selected at a time. Syntax for creating radio buttons is as follows:

CheckboxGroup cbg = new CheckboxGroup();

Checkbox Win98 = new Checkbox("Windows 98/XP", cbg , true);

Checkbox winNT = new Checkbox("Windows NT/2000",cbg, false);

Checkbox solaris = new Checkbox("Solaris",cbg, false);

Checkbox mac = new Checkbox("MacOS",cbg, false);

For Radio Button we will be using CheckBox class. The only difference in Checkboxes and radio button is in Check boxes we will specify null for checkboxgroup but whereas in radio button we will be specifiying the checkboxgroup object in the second parameter.

5) Choice:

The Choice class is used to create a pop-up list of items from which the user may choose. Thus, a Choice control is a form of menu. Syntax for creating choice is as follows:

Choice os = new Choice();

/* adding items to choice */

os.add("Windows 98/XP");

os.add("Windows NT/2000");

os.add("Solaris");

os.add("MacOS");

We will be creating choice with the help of Choice class. Pop up list will be creating with the creation of object, but it will not have any items. For adding items we will be using add() method defined in Choice class.

To determine which item is currently selected, you may call either getSelectedItem( ) or getSelectedIndex( ). These methods are shown here:

String getSelectedItem( )

int getSelectedIndex( )

The getSelectedItem( ) method returns a string containing the name of the item. getSelectedIndex( ) returns the index of the item. The first item is at index 0. By default, the first item added to the list is selected.

6) List:

List class is also same as choice but the only difference in list and choice is, in choice user can select only one item whereas in List user can select more than one item. Syntax for creating list is as follows:

List os = new List(4, true);

First argument in the List constructor specifies the number of items allowed in the list. Second argument specifies whether multiple selections are allowed or not.

/* Adding items to the list */

os.add("Windows 98/XP");

os.add("Windows NT/2000");

os.add("Solaris");

os.add("MacOS");

In list we can retrieve the items which are selected by the users. In multiple selection user will be selecting multiple values for retrieving all the values we have a method called getSelectedValues() whose return type is string array. For retrieving single value again we can use the method defined in Choice i.e. getSelectedItem().

7) TextField:

Text fields allow the user to enter strings and to edit the text using the arrow keys, cut and paste keys. TextField is a subclass of TextComponent. Syntax for creating list is as follows:

TextField tf1 = new TextField(25);

TextField tf2 = new TextField();

In the first text field we are specifying the size of the text field and the second text field is created with the default value. TextField (and its superclass TextComponent) provides several methods that allow you to utilize a text field. To obtain the string currently contained in the text field, call getText( ). To set the text, call setText( ). These methods are as follows:

String getText( )

void setText(String str)

We can control whether the contents of a text field may be modified by the user by calling setEditable( ). You can determine editability by calling isEditable( ). These methods are shown here:

boolean isEditable( )

void setEditable(boolean canEdit)

isEditable( ) returns true if the text may be changed and false if not. In setEditable( ), if canEdit is true, the text may be changed. If it is false, the text cannot be altered.

There may be times when we will want the user to enter text that is not displayed, such as a password. We can disable the echoing of the characters as they are typed by calling setEchoChar( ).

8) TextArea:

TextArea is a multiple line editor. Syntax for creating list is as follows:

TextArea area = new TextArea(20,30);

Above code will create one text area with 20 rows and 30 columns. TextArea is a subclass of TextComponent. Therefore, it supports the getText( ), setText( ), getSelectedText( ), select( ), isEditable( ), and setEditable( ) methods described in the preceding section.

TextArea adds the following methods:

void append(String str)

void insert(String str, int index)

void replaceRange(String str, int startIndex, int endIndex)

The append( ) method appends the string specified by str to the end of the current text. insert( ) inserts the string passed in str at the specified index. To replace text, call replaceRange( ). It replaces the characters from startIndex to endIndex –1, with the replacement text passed in str.

Layout Managers:

A layout manager automatically arranges controls within a window by using some type of algorithm. Each Container object has a layout manager associated with it. A layout manager is an instance of any class that implements the LayoutManager interface. The layout manager is set by the setLayout( ) method. If no call to setLayout( ) is made, then the default layout manager is used. Whenever a container is resized (or sized for the first time), the layout manager is used to position each of the components within it. The setLayout( ) method has the following general form:

void setLayout(LayoutManager layoutObj)

Here, layoutObj is a reference to the desired layout manager. If you wish to disable the layout manager and position components manually, pass null for layoutObj. If we do this, you will need to determine the shape and position of each component manually, using the setBounds( ) method defined by Component.

Void setBounds(int x , int y , int width, int length)

In which first two arguments are the x and y axis. Third argument is width and fourth argument is height of the component.

Java has several predefined LayoutManager classes, several of which are described next. You can use the layout manager that best fits your application.

Flow Layout:

Flow Layout is the default layout manager. This is the layout manager that the preceding examples have used. Flow Layout implements a simple layout style, which is similar to how words flow in a text editor. Components are laid out from the upper-left corner, left to right and top to bottom. When no more components fit on a line, the next one appears on the next line. A small space is left between each component, above and below, as well as left and right. Here are the constructors for FlowLayout:

FlowLayout( )

FlowLayout(int how)

FlowLayout(int how, int horz, int vert)

The first form creates the default layout, which centers components and leaves five pixels of space between each component. The second form lets you specify how each line is aligned. Valid values for how are as follows:

FlowLayout.LEFT

FlowLayout.CENTER

FlowLayout.RIGHT

These values specify left, center, and right alignment, respectively. The third form allows you to specify the horizontal and vertical space left between components in horz and vert, respectively.

BorderLayout:

THE JAVA LIBRARYThe BorderLayout class implements a common layout style for top-level windows. It has four narrow, fixed-width components at the edges and one large area in the center. The four sides are referred to as north, south, east, and west. The middle area is called the center. Here are the constructors defined by BorderLayout:

BorderLayout( )

BorderLayout(int horz, int vert)

The first form creates a default border layout. The second allows you to specify the horizontal and vertical space left between components in horz and vert, respectively. BorderLayout defines the following constants that specify the regions:

Abbildung in dieser Leseprobe nicht enthalten

When adding components, you will use these constants with the following form of add( ), which is defined by Container:

void add(Component compObj, Object region);

Here, compObj is the component to be added, and region specifies where the component will be added.

GridLayout:

GridLayout lays out components in a two-dimensional grid. When you instantiate a GridLayout, you define the number of rows and columns. The constructors supported by GridLayout are shown here:

GridLayout( )

GridLayout(int numRows, int numColumns)

GridLayout(int numRows, int numColumns, int horz, int vert)

The first form creates a single-column grid layout. The second form creates a grid layout with the specified number of rows and columns. The third form allows you to specify the horizontal and vertical space left between components in horz and vert, respectively. Either numRows or numColumns can be zero. Specifying numRows as zero allows for unlimited-length columns. Specifying numColumns as zero allows for unlimited-length rows.

Swings:

About Swings:

Swing is important to develop Java programs with a graphical user interface (GUI). There are many components which are used for the building of GUI in Swing. The Swing Toolkit consists of many components for the building of GUI. These components are also helpful in providing interactivity to Java applications. Following are components which are included in Swing toolkit:

- list controls
- buttons
- labels
- tree controls
- table controls

All AWT flexible components can be handled by the Java Swing. Swing toolkit contains far more components than the simple component toolkit. It is unique to any other toolkit in the way that it supports integrated internationalization, a highly customizable text package, rich undo support etc. Not only this you can also create your own look and feel using Swing other than the ones that are supported by it. The customized look and feel can be created using Synth which is specially designed. Not to forget that Swing also contains the basic user interface such as customizable painting, event handling, drag and drop etc.

The Java Foundation Classes (JFC) which supports many more features important to a GUI program comprises of Swing as well. The features which are supported by Java Foundation Classes (JFC) are the ability to create a program that can work in different languages, the ability to add rich graphics functionality etc.

There are several components contained in Swing toolkit such as check boxes, buttons, tables, text etc. Some very simple components also provide sophisticated functionality. For instance, text fields provide formatted text input or password field behavior. Furthermore, the file browsers and dialogs can be used according to one's need and can even be customized.

Difference between Swings and AWT:

Abbildung in dieser Leseprobe nicht enthalten

Java Swing Class Hierarchy:

Abbildung in dieser Leseprobe nicht enthalten

Swing Components:

All the components which are supported in AWT same components are also supported in Swings with a slight change in their class name.

Abbildung in dieser Leseprobe nicht enthalten

We will discuss only those components which are not discussed in AWT chapter.

JTabbedPane class:

The JTabbedPane container allows many panels to occupy the same area of the interface, and the user may select which to show by clicking on a tab.

Constructor

Abbildung in dieser Leseprobe nicht enthalten

Adding tabs to the JTabbedPane

Add tabs to a tabbed pane by calling addTab and passing it a String title and an instance of a class which should be called when we pressed a tab. That class should be a subclass of JPanel.

addTab(“String”,instance);

Example program:

import javax.swing.*;

import java.awt.*;

public class TabbedPaneDemo extends JFrame

Abbildung in dieser Leseprobe nicht enthalten

setLayout(new FlowLayout(FlowLayout.LEFT));

setTitle("Tabbed Demo");

setVisible(true);

setSize(500,500);

setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

JTabbedPane pane = new JTabbedPane();

pane.addTab("Countries",new Count());

pane.addTab("Cities",new Cit());

add(pane);

Abbildung in dieser Leseprobe nicht enthalten

JButton b1 = new JButton("India");

JButton b2 = new JButton("SriLanka");

JButton b3 = new JButton("Australia");

add(b1);

add(b2);

add(b3);

Abbildung in dieser Leseprobe nicht enthalten

JCheckBox cb1 = new JCheckBox("Hyderabad");

JCheckBox cb2 = new JCheckBox("Banglore");

JCheckBox cb3 = new JCheckBox("Pune");

add(cb1);

add(cb2);

add(cb3);

Abbildung in dieser Leseprobe nicht enthalten

JMenuBar, JMenu, JMenuItem

A top-level window can have a menu bar associated with it. A menu bar displays a list of top-level menu choices. Each choice is associated with a drop-down menu. This concept is implemented in Java by the following classes: JMenuBar, JMenu, and JMenuItem. In general, a menu bar contains one or more JMenu objects. Each JMenu object contains a list of JMenuItem objects. Each JMenuItem object represents something that can be selected by the user. To create a menu bar, first create an instance of JMenuBar. This class only defines the default constructor. Next, create instances of JMenu that will define the selections displayed on the bar. Following are the constructors for Menu:

JMenu( )

JMenu(String optionName)

Here, optionName specifies the name of the menu selection. The first form creates an empty menu. Individual menu items are of type MenuItem. It defines these constructors:

JMenuItem( )

JMenuItem(String itemName)

Here, itemName is the name shown in the menu.

6. CODING

6.1. Source code

WSN.java

package relay;

import javax.swing.JFrame;

import javax.swing.JMenuBar;

import javax.swing.JMenu;

import javax.swing.JMenuItem;

import javax.swing.JPanel;

import java.awt.event.ActionListener;

import java.awt.event.ActionEvent;

import java.awt.CardLayout;

import java.awt.Color;

import java.awt.Font;

import javax.swing.JLabel;

import javax.swing.ImageIcon;

import java.awt.BorderLayout;

import javax.swing.UIManager;

import java.awt.Dimension;

import javax.swing.JButton;

import java.awt.Toolkit;

import java.util.ArrayList;

import org.jfree.ui.RefineryUtilities;

import java.io.BufferedReader;

import java.io.FileReader;

public class WSN extends JFrame implements ActionListener,Runnable

{

Dimension d1;

JPanel p1,p2,p3;

JMenuBar bar;

JMenu m1,m2,m3,m4;

JMenuItem create_network,exit,logout;

JMenuItem log,reg,chart;

Font f1,f2;

JLabel l1,l2;

CardLayout card;

Thread thread;

CreateNodes cn;

public WSN(){

super("Wireless Sensor Networks");

d1 = Toolkit.getDefaultToolkit().getScreenSize();

p1 = new JPanel();

f1 = new Font("Courier New",Font.BOLD,18);

l1 = new JLabel("<HTML><BODY><CENTER>MOBILE RELAY CONFIGURATION IN DATA-INTENSIVE<BR/>WIRELESS SENSOR NETWORKS</CENTER></BODY></HTML>");

l1.setFont(f1);

p1.add(l1);

p1.setBackground(new Color(103,159,223));

p2 = new JPanel();

card = new CardLayout();

p2.setLayout(card);

bar = new JMenuBar();

setJMenuBar(bar);

f2 = new Font("Courier New",Font.BOLD,14);

m4 = new JMenu("Login");

bar.add(m4);

m4.setFont(f2);

log = new JMenuItem("Login");

m4.add(log);

log.addActionListener(this);

log.setFont(f2);

reg = new JMenuItem("Register");

m4.add(reg);

reg.addActionListener(this);

reg.setFont(f2);

m1 = new JMenu("Create Network");

bar.add(m1);

m1.setFont(f2);

create_network = new JMenuItem("Create Sensor Network");

m1.add(create_network);

create_network.addActionListener(this);

create_network.setFont(f2);

m2 = new JMenu("Charts");

bar.add(m2);

m2.setFont(f2);

chart = new JMenuItem("Chart");

m2.add(chart);

chart.addActionListener(this);

chart.setFont(f2);

m3 = new JMenu("Exit");

bar.add(m3);

m3.setFont(f2);

logout = new JMenuItem("Logout");

m3.add(logout);

logout.addActionListener(this);

logout.setFont(f2);

exit = new JMenuItem("Exit");

m3.add(exit);

exit.addActionListener(this);

exit.setFont(f2);

p3 = new JPanel();

p3.setLayout(new BorderLayout());

ImageIcon icon=new ImageIcon("img/images.jpg");

l2 = new JLabel(icon);

p3.add(l2);

d1 = new Dimension(icon.getIconWidth(),icon.getIconHeight());

p2.add(p3,"p3");

card.show(p2,"p3");

p2.add(login,"login");

p2.add(register,"register");

cn = new CreateNodes(d1);

p2.add(cn,"cn");

getContentPane().add(p1,BorderLayout.NORTH);

getContentPane().add(p2,BorderLayout.CENTER);

m1.setEnabled(false);

m2.setEnabled(false);

thread = new Thread(this);

thread.start();

}

public void run(){

try{

while(true){

l1.setForeground(Color.white);

thread.sleep(500);

l1.setForeground(Color.cyan);

thread.sleep(500);

l1.setForeground(Color.black);

thread.sleep(500);

Abbildung in dieser Leseprobe nicht enthalten

public void actionPerformed(ActionEvent ae){

if(ae.getSource() == chart){

ArrayList<String> str = new ArrayList<String>();

try{

BufferedReader br = new BufferedReader(new FileReader("graph.txt"));

String line = null;

while((line = br.readLine())!=null){

str.add(line);

Abbildung in dieser Leseprobe nicht enthalten

Chart chart1 = new Chart("Network Path Length",str);

chart1.pack();

RefineryUtilities.centerFrameOnScreen(chart1);

chart1.setVisible(true);

}

if(ae.getSource() == exit){

System.exit(0);

}

if(ae.getSource() == create_network){

card.show(p2,"cn");

}

if(ae.getSource() == logout){

m1.setEnabled(false);

m2.setEnabled(false);

m4.setEnabled(true);

card.show(p2,"p3");

}

if(ae.getSource() == log){

card.show(p2,"login");

}

if(ae.getSource() == reg){

card.show(p2,"register");

}

public static void main(String a[])throws Exception{

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

WSN wsn = new WSN();

wsn.setVisible(true);

wsn.setSize(800,700);

}

ShowNetwork.java

package relay;

import javax.swing.JFrame;

import javax.swing.JPanel;

import java.util.ArrayList;

import java.awt.BorderLayout;

import java.awt.Color;

import javax.swing.JOptionPane;

import java.awt.Dimension;

import java.awt.Font;

import java.io.FileWriter;

import javax.swing.table.DefaultTableModel;

import javax.swing.JLabel;

import javax.swing.JComboBox;

import javax.swing.JButton;

import java.awt.event.ActionEvent;

import java.awt.event.ActionListener;

import net.miginfocom.swing.MigLayout;

import javax.swing.JFileChooser;

import java.io.File;

public class ShowNetwork extends JFrame

{

Sensors node;

JPanel p1,p2;

int left,top;

ArrayList<NodeDetails> nd;

Dimension dim;

Font f1;

boolean flag = false;

DefaultTableModel dtm;

JLabel l1;

JComboBox c1;

JButton b1;

JFileChooser chooser;

String old;

int run;

public static boolean checkRelay(String node,String sink[]){

boolean flag = true;

for(int i=0;i<sink.length;i++){

if(sink[i].equals(node)){

flag = false;

break;

}

return flag;

Abbildung in dieser Leseprobe nicht enthalten

super("Wireless Sensor Networks");

nd = nodedetails;

dim = dimension;

dtm=dt;

f1 = new Font("Courier New",Font.BOLD,14);

node = new Sensors();

p1 = new JPanel();

p1.setLayout(new BorderLayout());

p1.add(node,BorderLayout.CENTER);

p1.setBackground(Color.black);

getContentPane().add(p1,BorderLayout.CENTER);

chooser = new JFileChooser();

p2 = new JPanel();

p2.setLayout(new MigLayout("wrap 2"));

l1 = new JLabel("Sender Sensor");

l1.setFont(f1);

p2.add(l1);

c1 = new JComboBox();

c1.setFont(f1);

c1.addItem("Sensor");

NodeDetails nd = nodedetails.get(0);

String sink[] = nd.getRelayNode().split(",");

Abbildung in dieser Leseprobe nicht enthalten

7. Testing

Implementation and Testing:

Implementation is one of the most important tasks in project is the phase in which one has to be cautions because all the efforts undertaken during the project will be very interactive. Implementation is the most crucial stage in achieving successful system and giving the users confidence that the new system is workable and effective. Each program is tested individually at the time of development using the sample data and has verified that these programs link together in the way specified in the program specification. The computer system and its environment are tested to the satisfaction of the user.

Implementation

The implementation phase is less creative than system design. It is primarily concerned with user training, and file conversion. The system may be requiring extensive user training. The initial parameters of the system should be modifies as a result of a programming. A simple operating procedure is provided so that the user can understand the different functions clearly and quickly. The different reports can be obtained either on the inkjet or dot matrix printer, which is available at the disposal of the user. The proposed system is very easy to implement. In general implementation is used to mean the process of converting a new or revised system design into an operational one.

Testing

Testing is the process where the test data is prepared and is used for testing the modules individually and later the validation given for the fields. Then the system testing takes place which makes sure that all components of the system property functions as a unit. The test data should be chosen such that it passed through all possible condition. Actually testing is the state of implementation which aimed at ensuring that the system works accurately and efficiently before the actual operation commence. The following is the description of the testing strategies, which were carried out during the testing period.

System Testing

Testing has become an integral part of any system or project especially in the field of information technology. The importance of testing is a method of justifying, if one is ready to move further, be it to be check if one is capable to with stand the rigors of a particular situation cannot be underplayed and that is why testing before development is so critical. When the software is developed before it is given to user to user the software must be tested whether it is solving the purpose for which it is developed. This testing involves various types through which one can ensure the software is reliable. The program was tested logically and pattern of execution of the program for a set of data are repeated. Thus the code was exhaustively checked for all possible correct data and the outcomes were also checked.

Module Testing

To locate errors, each module is tested individually. This enables us to detect error and correct it without affecting any other modules. Whenever the program is not satisfying the required function, it must be corrected to get the required result. Thus all the modules are individually tested from bottom up starting with the smallest and lowest modules and proceeding to the next level. Each module in the system is tested separately. For example the job classification module is tested separately. This module is tested with different job and its approximate execution time and the result of the test is compared with the results that are prepared manually. The comparison shows that the results proposed system works efficiently than the existing system. Each module in the system is tested separately. In this system the resource classification and job scheduling modules are tested separately and their corresponding results are obtained which reduces the process waiting time.

Integration Testing

After the module testing, the integration testing is applied. When linking the modules there may be chance for errors to occur, these errors are corrected by using this testing. In this system all modules are connected and tested. The testing results are very correct. Thus the mapping of jobs with resources is done correctly by the system.

Acceptance Testing

When that user fined no major problems with its accuracy, the system passers through a final acceptance test. This test confirms that the system needs the original goals, objectives and requirements established during analysis without actual execution which elimination wastage of time and money acceptance tests on the shoulders of users and management, it is finally acceptable and ready for the operation.

7. Screen Shots

Home page:

Abbildung in dieser Leseprobe nicht enthalten

If new user first register.

Abbildung in dieser Leseprobe nicht enthalten

Fill the details of user and click on register button:

Abbildung in dieser Leseprobe nicht enthalten

After clicked the register button it will show the message:

Abbildung in dieser Leseprobe nicht enthalten

Enter the user name and password after click the login button:

Abbildung in dieser Leseprobe nicht enthalten

After login this is the home page:

Abbildung in dieser Leseprobe nicht enthalten

Select create sensor network:

Abbildung in dieser Leseprobe nicht enthalten

Enter the total sensors (25) after should click on enter button, choose color for sensor nodes, choose relay nodes one after another (s6, s12, s17, s23), choose color for relay nodes finally click on finish button.

Abbildung in dieser Leseprobe nicht enthalten

This is the wireless sensor network screen first choose sender sensor node click on send button:

Abbildung in dieser Leseprobe nicht enthalten

Choose the file to send the data from sensor node to the base station:

Abbildung in dieser Leseprobe nicht enthalten

With the help of relay nodes sending the data from base station:

Abbildung in dieser Leseprobe nicht enthalten

After sending the data see the first screen:

Abbildung in dieser Leseprobe nicht enthalten

Select the chart option:

Abbildung in dieser Leseprobe nicht enthalten

View the chart:

Abbildung in dieser Leseprobe nicht enthalten

Finally click on logout button:

Abbildung in dieser Leseprobe nicht enthalten

9. Conclusions

Our approach can work with less optimal initial configurations including one generated using only local information such as greedy geographic routing. Our approach improves the initial configuration using two iterative schemes. The first inserts new nodes into the tree. The second computes the optimal positions of relay nodes in the tree given a fixed topology. This algorithm is appropriate for a variety of data-intensive wireless sensor networks. It allows some nodes to move while others do not because any local improvement for a given mobile relay is a global improvement. This allows us to potentially extend our approach to handle additional constraints on individual nodes such as low energy levels or mobility restrictions due to application requirements. Our approach can be implemented in a centralized or distributed fashion. Our simulations show it substantially reduces the energy consumption by up to 45%.

10. Bibliography

[1] R. Szewczyk, A. Mainwaring, J. Polastre, J. Anderson, and D. Culler, “An Analysis of a Large Scale Habitat Monitoring Application,”Proc. Second ACM Conf. Embedded Networked Sensor Systems (SenSys),2004.
[2] L. Luo, Q. Cao, C. Huang, T.F. Abdelzaher, J.A. Stankovic, and M. Ward, “EnviroMic: Towards Cooperative Storage and Retrieval in Audio Sensor Networks,”Proc. 27th Int’l Conf. Distributed Computing Systems (ICDCS),p. 34, 2007.
[3] D. Ganesan, B. Greenstein, D. Perelyubskiy, D. Estrin, and J. Heidemann, “An Evaluation of Multi-Resolution Storage for Sensor Networks,” Proc. First Int’l Conf. Embedded Networked Sensor Systems (SenSys),2003.
[4] S.R. Gandham, M. Dawande, R. Prakash, and S. Venkatesan, “Energy Efficient Schemes for Wireless Sensor Networks with Multiple Mobile Base Stations,”Proc. IEEE GlobeCom,2003.
[5] J. Luo and J.-P. Hubaux, “Joint Mobility and Routing for Lifetime Elongation in Wireless Sensor Networks,”Proc. IEEE INFOCOM, 2005.
[6] Z.M. Wang, S. Basagni, E. Melachrinoudis, and C. Petrioli, “Exploiting Sink Mobility for Maximizing Sensor Networks Lifetime,” Proc. 38th Ann. Hawaii Int’l Conf. System Sciences (HICSS),2005.
[7] A. Kansal, D.D. Jea, D. Estrin, and M.B. Srivastava, “Controllably Mobile Infrastructure for Low Energy Embedded Networks,” IEEE Trans. Mobile Computing,vol. 5, no. 8, pp. 958-973, Aug. 2006.
[8] G. Xing, T. Wang, W. Jia, and M. Li, “Rendezvous Design Algorithms for Wireless Sensor Networks with a Mobile Base Station,”Proc. ACM MobiHoc,pp. 231-240, 2008.
[9] D. Jea, A.A. Somasundara, and M.B. Srivastava, “Multiple Controlled Mobile Elements (Data Mules) for Data Collection in Sensor Networks,”Proc. IEEE First Int’l Conf. Distributed Computing in Sensor Systems (DCOSS), 2005.
[10] R. Shah, S. Roy, S. Jain, and W. Brunette, “Data Mules: Modeling a Three-Tier Architecture for Sparse Sensor networks,”Proc. IEEE First Int’l Workshop Sensor Network Protocols and Applications (SNPA),2003.

Excerpt out of 91 pages - scroll top

Details

Title: Relay Nodes in Big-Data Wireless Sensor Networks
College: Jawaharlal Nehru University (Guru Nanak college of institutions and technology)
Course: CSE
Grade: A
Author: Chandra Shekar Kemedi (Author)
Publication Year: 2014
Pages: 91
Catalog Number: V284154
ISBN (eBook): 9783656844990
ISBN (Book): 9783656845003
Language: English
Tags: relay nodes big-data wireless sensor networks

Quote paper: Chandra Shekar Kemedi (Author), 2014, Relay Nodes in Big-Data Wireless Sensor Networks, Munich, GRIN Verlag, https://www.grin.com/document/284154

Relay Nodes in Big-Data Wireless Sensor Networks

Excerpt

1. Introduction

1.1. Objective of the Project

2. Literature Survey

3. Analysis

3.1. Introduction

3.2. Existing System

3.3. Proposed System

3.4. PROCESS MODEL USED WITH JUSTIFICATION

3.5. Software Requirement Specification

3.5.1. Overall Description

3.5.2. External Interface Requirements

4. Design

5. Implementation

5.1. Modules

5.2. Module description

5.3. Introduction of technologies used

Compilation of code

Object oriented

Robust

Adding tabs to the JTabbedPane

7. Testing

Implementation

Testing

System Testing

Module Testing

Integration Testing

Acceptance Testing

7. Screen Shots

9. Conclusions

10. Bibliography

Details