mobile based lan monitoring and control

Mobile Based Lan Monitoring And Control

CHAPTER-1

INTRODUCTION

Today, the world is rapidly changing the statement “We are in the world” to “World is

in our hands”. The main aim of our project is to control and monitor the LAN network from

our wireless handheld device i.e. cell phone from anywhere irrespective of distance. Say, you

have a LAN setup at your office. Sitting at home you want to learn the LAN status. You can

do so by storing this project in your cell phone and executing the same.

In the era of mobile devices, wireless devices are widely used and it has penetrated

every part of our life, but remote monitoring of networks through mobile device is still a

mirage, this project is an effort to make this mirage a reality, and this is where the genesis of

this of this project lies.

1.1 . Problem Statement :

LAN monitoring using GSM technology can be used in offices, malls as well as college

or university level.

The main objective of this project is to provide maximum details about the network to

the administrator on their mobile phone, when administrator is away from office / goes out

station.

1.2Literature Survey :

1.2.1 Introduction :

A literature survey is a discussion of the literature in a given area of the study. It is

concise overview of what has been studied, argued and established about a topic, and it is

usually organized chronologically or thematically. It is not an annotated bibliography,

because it groups related works together and discusses trends and developments rather than

focusing on one item at a time. It is not a summary, rather it evaluates previous and current

research in regard to how relevant and or useful it is.

1


1.2.2 Technology Information:

1.2.2.1 Servlets

The Java Servlet API allows a software developer to add dynamic content to a Web

server using the Java platform. The generated content is commonly HTML, but may be other

data such as XML. Servlets with JavaServer Pages are the Java counterpart to dynamic web

content technologies such as CGI/PHP or ASP.NET/VBScript,JScript,C Sharp. Servlets can

maintain state across many server transactions by using HTTP cookies, session variables or

URL rewriting.

The Servlet API, contained in the Java package hierarchy javax.servlet, defines the

expected interactions of a web container and a servlet. A web container is essentially the

component of a web server that interacts with the servlets. The web container is responsible

for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring

that the URL requester has the correct access rights.

A Servlet is an object that receives requests (ServletRequest) and generates a response

(ServletResponse) based on the request. The API package javax.servlet.http defines HTTP

subclasses of the generic servlet (HttpServlet) request (HttpServletRequest) and response

(HttpServletResponse) as well as an (HttpSession) that tracks multiple requests and

responses between the web server and a client. Servlets may be packaged in a WAR file as a

Web application.

Moreover, servlets can be generated automatically by JavaServer Pages (JSP), or

alternately by template engines such as WebMacro. Often servlets are used in conjunction

with JSPs in a pattern called "Model 2", which is a flavor of the model-view-controller

pattern.

1.2.2.2 J2SE SDK

Java Platform, Standard Edition or Java SE (formerly known up to version 5.0 as Java 2

Platform, Standard Edition or J2SE), is a collection of Java programming language APIs

useful to many Java platform programs. The Java Platform, Enterprise Edition includes all of

the classes in the Java SE, plus a number which are more useful to programs running on

servers than on workstations.

2


Starting with the J2SE 1.4 version (Merlin), the Java SE platform has been developed

under the Java Community Process. JSR 59 was the umbrella specification for J2SE 1.4 and

JSR 176 specified J2SE 5.0 (Tiger). As of 2006, Java SE 6 (Mustang) is being developed

under JSR 270.

The following are descriptions of some of the primary Java SE packages. For a

complete list of packages see the J2SE 5.0 API Javadocs.

1.2.2.3 NetBeans

NetBeans refers to both a platform for the development of Java desktop applications,

and an integrated development environment (IDE) developed using the NetBeans Platform.

The NetBeans Platform allows applications to be developed from a set of modular

software components called modules. A module is a Java archive file that contains Java

classes written to interact with the NetBeans Open APIs and a manifest file that identifies it

as a module. Applications built on modules can be extended by adding new modules. Since

modules can be developed independently, applications based on the NetBeans platform can

be easily and powerfully extended by third party developers.

The NetBeans Platform:

The NetBeans Platform is a reusable framework for simplifying the development of

other desktop applications. When an application based on the NetBeans Platform is run, the

platform's Main class is executed. Available modules are located, placed in an in-memory

registry, and the modules' startup tasks are executed. Generally, a module's code is loaded

into memory only as it is needed.

Applications can install modules dynamically. Any application can include the Update

Center module to allow users of the application to download digitally-signed upgrades and

new features directly into the running application. Reinstalling an upgrade or a new release

does not force users to download the entire application again.

The platform offers services common to desktop applications, allowing developers to

focus on the logic specific to their application. Among the features of the platform are:

User interface management (e.g. menus and toolbars)

User settings management

3


Storage management (saving and loading any kind of data)

Window management

Wizard framework (supports step-by-step dialogs)

The NetBeans IDE is an open-source integrated development environment written

entirely in Java using the NetBeans Platform. NetBeans IDE supports development of all

Java application types (J2SE, web, EJB and mobile applications) out of the box. Among

other features are an Ant-based project system, version control and refactoring.

The current version is NetBeans IDE 5.5.1, which was released in May 2007. NetBeans

IDE 5.5 extends the existing Java EE features (including Java Persistence support, EJB 3 and

JAX-WS). Additionally, the NetBeans Enterprise Pack supports development of Java EE 5

enterprise applications, including SOA visual design tools, XML schema tools, web services

orchestration (for BPEL), and UML modeling. The NetBeans C/C++ Pack supports C/C++

projects. NetBeans 5.5.1 builds on the functionality of NetBeans 5.5 and also provides

several bug fixes.

NetBeans IDE 5.5 builds upon the previous version 5.0, which introduced

comprehensive support for developing IDE modules and rich client applications based on the

NetBeans platform, a new GUI builder (formerly known as "Project Matisse"), new and

redesigned CVS support, Weblogic 9 and JBoss 4 support, and many editor enhancements.

Modularity: All the functions of the IDE are provided by modules. Each module

provides a well defined function, such as support for the Java language, editing, or support

for the CVS versioning system. NetBeans contains all the modules needed for Java

development in a single download, allowing the user to start working immediately. Modules

also allow NetBeans to be extended. New features, such as support for other programming

languages, can be added by installing additional modules. For instance, Sun Studio, Sun Java

Studio Enterprise, and Sun Java Studio Creator from Sun Microsystems are all based on the

NetBeans IDE.

4


1.2.2.4 Process Builder

This class is used to create operating system processes. Each ProcessBuilder instance

manages a collection of process attributes. The start() method creates a new Process instance

with those attributes. The start() method can be invoked repeatedly from the same instance to

create new subprocesses with identical or related attributes.

Each process builder manages these process attributes:

A command, a list of strings which signifies the external program file to be invoked

and its arguments, if any. Which string lists represent a valid operating system

command is system-dependent. For example, it is common for each conceptual

argument to be an element in this list, but there are operating systems where programs

are expected to tokenize command line strings themselves - on such a system a Java

implementation might require commands to contain exactly two elements.

An environment, which is a system-dependent mapping from variables to values. The

initial value is a copy of the environment of the current process.

A working directory. The default value is the current working directory of the current

process, usually the directory named by the system property user.dir.

A redirectErrorStream property. Initially, this property is false, meaning that the

standard output and error output of a subprocess are sent to two separate streams,

which can be accessed using the Process.getInputStream() and

Process.getErrorStream() methods. If the value is set to true, the standard error is

merged with the standard output. This makes it easier to correlate error messages with

the corresponding output. In this case, the merged data can be read from the stream

returned by Process.getInputStream(), while reading from the stream returned by

Process.getErrorStream() will get an immediate end of file.

Modifying a process builder's attributes will affect processes subsequently started by

that object's start() method, but will never affect previously started processes or the Java

process itself.

Most error checking is performed by the start() method. It is possible to modify the

state of an object so that start() will fail. For example, setting the command attribute to an

empty list will not throw an exception unless start() is invoked.

5


Note that this class is not synchronized. If multiple threads access a ProcessBuilder

instance concurrently, and at least one of the threads modifies one of the attributes

structurally, it must be synchronized externally.

1.2.2.5 Tomcat Apache

Apache Tomcat (formerly under the Apache Jakarta Project; Tomcat is now a top level

project) is a web container developed at the Apache Software Foundation. Tomcat

implements the servlet and the JavaServer Pages (JSP) specifications from Sun

Microsystems, providing an environment for Java code to run in cooperation with a web

server. It adds tools for configuration and management but can also be configured by editing

configuration files that are normally XML-formatted. Tomcat includes its own HTTP server

internally.

Environment:

Tomcat is a web server that supports servlets and JSPs. Tomcat comes with the Jasper

compiler that compiles JSPs into servlets.

The Tomcat servlet engine is often used in combination with an Apache webserver or

other web servers. Tomcat can also function as an independent web server. Earlier in its

development, the perception existed that standalone Tomcat was only suitable for

development environments and other environments with minimal requirements for speed and

transaction handling. However, that perception no longer exists; Tomcat is increasingly used

as a standalone web server in high-traffic, high-availability environments.

Since its developers wrote Tomcat in Java, it runs on any operating system that has a JVM.

1.2.2.6 Abstract Window Toolkit

The Abstract Window Toolkit (AWT) is Java's original platform-independent

windowing, graphics, and user-interface widget toolkit. The AWT is now part of the Java

Foundation Classes (JFC) — the standard API for providing a graphical user interface (GUI)

for a Java program.

6

http://en.wikipedia.org/wiki/Java_(programming_language)

http://en.wikipedia.org/wiki/Graphical_user_interface

http://en.wikipedia.org/wiki/Application_programming_interface

http://en.wikipedia.org/wiki/Java_Foundation_Classes

http://en.wikipedia.org/wiki/Java_Foundation_Classes

http://en.wikipedia.org/wiki/Widget_toolkit

http://en.wikipedia.org/wiki/User-interface

http://en.wikipedia.org/wiki/Graphic

http://en.wikipedia.org/wiki/Windowing_system


AWT is also the GUI toolkit for a number of Mobile Java profiles. For example,

Connected Device Configuration profiles require Java runtimes on mobile telephones to

support AWT.

The AWT provides two levels of APIs:

A general interface between Java and the native system, used for windowing, events,

layout managers. This API is at the core of Java GUI programming and is also used

by Swing and Java 2D. It contains:

o The interface between the native windowing system and the Java application

o The core of the GUI event subsystem,

o Several layout managers,

o The interface to input devices such as mouse and keyboard,

o A java.awt.datatransfer package for use with the Clipboard and Drag and

Drop,

A basic set of GUI widgets such as buttons, text boxes, and menus. it also provide the

AWT Native Interface, which enables rendering libraries compiled to native code to

draw directly to an AWT Canvas object drawing surface.

AWT also provide some miscellaneous useful utilities, that can also be used by Swing, such

as:

Access to the system tray on supporting systems,

The ability to launch some desktop applications such as web browsers and email

clients from a Java application.

Neither AWT nor Swing are inherently thread safe. Therefore, code that updates the

GUI or processes events should execute on the Event dispatching thread. Failure to do so

may result in a deadlock or race condition. To address this problem, a utility class called

SwingWorker allows applications to perform time-consuming tasks following user-

interaction events in the event dispatching thread.

Implementation:

As AWT bridge to the underlying native user interface, its implementation on a new

operating system may involve a lot of work, especially for the set of AWT GUI widgets,

which require to develop ab initio a native peer for each of AWT widgets.Since the opening

7

http://en.wikipedia.org/wiki/Operating_system

http://en.wikipedia.org/wiki/SwingWorker

http://en.wikipedia.org/wiki/Event_dispatching_thread

http://en.wikipedia.org/wiki/Mail_client

http://en.wikipedia.org/wiki/Mail_client

http://en.wikipedia.org/wiki/Web_browser

http://en.wikipedia.org/wiki/System_tray

http://en.wikipedia.org/wiki/Object_(computer_science)

http://java.sun.com/javase/6/docs/api/java/awt/Canvas.html

http://en.wikipedia.org/wiki/Native_code

http://en.wikipedia.org/wiki/Library_(computer_science)

http://en.wikipedia.org/wiki/Render

http://en.wikipedia.org/wiki/Java_AWT_Native_Interface

http://en.wikipedia.org/wiki/Drag_and_drop

http://en.wikipedia.org/wiki/Drag_and_drop

http://en.wikipedia.org/wiki/Clipboard_(software)

http://en.wikipedia.org/wiki/Java_package

http://java.sun.com/javase/6/docs/api/java/awt/datatransfer/package-summary.html

http://en.wikipedia.org/wiki/Keyboard_(computing)

http://en.wikipedia.org/wiki/Mouse_(computing)

http://en.wikipedia.org/wiki/Input_device

http://en.wikipedia.org/wiki/Layout_manager

http://en.wikipedia.org/wiki/Event-driven_programming

http://en.wikipedia.org/wiki/Java_2D

http://en.wikipedia.org/wiki/Swing_(Java)

http://en.wikipedia.org/wiki/Graphical_user_interface

http://en.wikipedia.org/wiki/Layout_manager

http://en.wikipedia.org/wiki/Event-driven_programming

http://en.wikipedia.org/wiki/Windowing_system

http://en.wikipedia.org/wiki/Application_programming_interface

http://en.wikipedia.org/wiki/Mobile_telephone

http://en.wikipedia.org/wiki/Connected_Device_Configuration


of Java, a project called Caciocavallo has been created. It aims to provide a Java API based

on OpenJDK to ease AWT implementation on a new system. The project has successfully

experimented the implementation of AWT widgets using Java2D.

1.3 Brief Idea

1.3.1 Features controlled by cell phone

Net View: Get in your cell phone, the list of entire client’s in LAN. Keep pinging

every time to check the latest status of the PC’s. Anytime, the PC goes offline, its

name is removed from the list.

Process List: Get the list of all the processes running in the remote machine.

Activate Process: Activate different processes in either the server machine or any of

the client’s.

Kill Process: Kill the desired processes in either the server or clients.

Read: You can read the drives, folders, files of any of the client machines/ the server

machine from cell.

Open File: A small text file residing in any of the client or the server machine can be

opened in your cell phone.

Broadcast messages: Broadcast messages to clients, Server from cell.

New File: Create a new document in the cell phone and save the same in either the

server or client machine.

Shut Down the client machines from mobile

8

http://en.wikipedia.org/wiki/OpenJDK

http://hg.openjdk.java.net/caciocavallo/caciocavallo/raw-file/tip/cacio-docs/index.html


CHAPTER 2

SYSTEM PLAN AND OVERVIEW

2.1 Purpose :

This is software requirement specification for SMS. The purpose of this subject is to

convey information about applications requirements, both functional and non functional to

the reader a)this document provides the description of the environment in which the

application is expected to operate, b)a definition of application capabilities and c)the

specification of the applications functional and non functional requirements

Its serves the following group of audiences :

1. It helps the application designer with the clear view of the project requirement s

Designers will use this information recorded here as the basis for creating the

applications design

2. It helps the ultimate user that is the network administrator to cause the full capability

of the application

3. It will be used for test planning and designing the test cases

2.2 Scope :

Software scope is the first software project management activity it describes the data

and control the processed, function, performance, constraints, interfaces and reliability.

Function described in the statement of scope are evaluated and in some cases refined to

provide more details prior to beginning of estimation because both cost and schedule

estimates are functionally oriented, some degree of decomposition is often useful constraint

identify the limit placed on the software by external hardware, available memory or other

existing systems . performance considerations in encompass processing and response time

requirements.

2.2 Overall Description :

Mobile based lan monitoring and control is a tool used to monitor a lan through a

mobile device by the administrator when he is at a remote site.

9


This tool is installed on the node which has two independent parts. One is server

application which works as a major process on the machine and offer the services to

administrator for controlling and monitoring the lan. The other is the client application

which is the background process on the machine and control all the activities of the client and

gives feedback to the server. The server application can control through registered mobile

device. Using that mobile device the administrator can perform following actions

1)kill process 2)start process 3)open file 4)delete file 5)broadcast message

The client application retrieves the list of processes running on the machine and send it back

to the server application. The server keep the list updated to check for live hosts. The server

can contact to the particular client using his id.

2.4 Architecture :

Administrator sends his request through SMS using his mobile phone having MIDP 1.0

tech on his phone via GSM modem to the server. Server then recognizes the client machine

which administrator is supposed to monitor and extract data from locally cached data buffer

where latest 15 sec data of every machine is updated or stored and sends this info to the

administrator as response.

Administrator is provided with a GUI based application in J2ME to send command

message instantly without the need to retype message every time. Server sends command to

the clients like start process, shutdown process, kill process, create, delete, send task list,

compile code

Through the GSM service provider the communication is done with the GSM modem

which communicates with the server and the server communicates with the client. All clients

are controlled and monitored by administrator via a series of SMS text messages for which

we are using a SMS parser to parse the SMS .

The administrator controls the LAN through his mobile even he is at the remote place.

The clients cannot send back or communicate to the administrator the communication is

unidirectional it is not two way. Only the administrator can give command to the clients.

The mobile used can be any mobile which has a GSM facility in it. Also the

administrator can check the network load on the LAN by typing only a command. In this also

a serial USB interface and a set of commands is used for the administrator to communicate to

10


the clients. The block diagram above shows how the operation takes place of the entire

system.

2.5 Block Diagram

11


2.6 Modules :

Server GUI:

Server side GUI to be designed in NetBeans 6.0 using Java Swing

Technology.

Contains GUI for communication with client.

Client GUI:

Client side GUI to be designed in NetBeans 6.0 using Java Swing

Technology.

Command can be given to the clients.

Data Library:

Database design to be created using Java Object Serialization (Java

Class Library creation in NetBeans).

Database containing client status.

GSM Modem Interfacing:

Modem interfacing at Server using Nokia PC Connectivity SDK

(This module is created in VB)

To interface GSM Modem with the server.

JAVA-VB interface:

This is a minor module used to interface the last mentioned VB

module so that messages (SMS) can be sent/received from within

Java.

Servlets:

Several java servlets need to be written in order to achieve client -

server communication.

Server:

We need to configure Tomcat Apache 5.5 server in order to get the

servlets running.

12


Servlets used for communication between client and the server.

OS Interfacing:

Several modules need to be programmed in order to access the

tasks currently running on any client.

Mobile Module (Optional):

A GUI module for mobile can be programmed which would ease

the process of typing and sending monitor and control messages

from administrator mobile.

Log:

A module to maintain log of all the activities on server.

SMS Parser:

A module to parse messages being sent by administrator.

Authentication:

A module to authenticate administrator via his/her

number/password.

Client Side Monitor:

A client module that continuously checks the current tasks on that

client and reports it to server. It also listens to any request received

from server.

Server Control:

A module to control and monitor all the clients form server

directly.

SMS Control:

Finally the module to control and monitor all the clients from

administrator mobile.

13


2.7 User Characteristics

One type of users for the System are Administrator sitting on the server machine. Administrator using cell phone

Type of user User Characteristic User technical expertise

How the user characteristic and technical expertise affect project functionalities

User sitting on the client machine

1)has some knowledge of pc depending on the work he/she is associated with 2)will not have any formal training to use the system

1)has some exposure to windows environment2)need not have knowledge of hardware and networking

1) GUI may be easier to learn 2)provides appropriate error messages for invalid user inputs

User using cell phone

1)has some knowledge of different commands that can be send through cell phone

1) need not have any technical knowledge

1)commands should be easy to remember according to their functionality

14


2.8 Schedule :

Software scheduling is a activity that distributes estimated efforts across the planned

project duration by allocating the effort to specific software engineering tasks.

Like all other areas of software engineering, number of basic principles guide software

project scheduling.

Interdependency :

Some tasks must occurs in sequence while others can occurs in parallel. Some

activities cant commence until the work product produced by another is available.

Time Allocation :

Each task to be scheduled must be allocated some number of work units (for example

person days of effort).

Effort Validation :

Every project has a defined number of staff members and project manager should

allocate the number of people that are scheduled at any given time for a particular task.

Defined Responsibilities :

Every task that is scheduled should be assigned to a specific team member.

Defined Outcomes :

Every task that is scheduled should have defined outcome, normally a work product.

Word products are often combined in deliverables.

15


Defined Milestones :

Every task or group of tasks should be associated with project milestones. A

milestone is accomplished when one or more work products has been reviewed for quality

and has been approved.

Each of this principle is applied as the project schedule evolves.

Tasks Performed Number Of Days

Required

Start Date End Date

Selecting the field

of interest

6 6/07/2009 12/7/2009

Searched companies

interested in

sponsoring B.E

15 13/7/2009 3/8/2009

Understanding the

problem statement

and the company

requirement

7 3/8/2009 10/8/2009

Collected

information about

the topic

7 10/8/2009 17/8/2009

Prepared the

abstract and decide

the modules

7 17/8/2009 24/08/2009

Prepared detailed

synopsis and

seminar related

information

6 24/08/2009 31/08/2009

Prepared for

seminar presentation

7 31/8/2009 7/09/2009

16


Decided to build a

s/w engg. Model of

the project

14 21/9/2009 5/10/2009

Submission of

preliminary report

8 14/10/2009 22/10/2009

Studied Java

Concepts

1 month 15/12/2009 15/1/2010

Designing for

Graphical User

Interface

15 18/1/2010 2/02/2010

Coding for modules

prepared

1 month 5/02/2010 4/3/2010

Software design

specification

4 5/03/2010 8/03/2010

Report Generation 20 9/03/2010 30/03/2010

17


2.9 SQA Plan

Introduction

Software quality assurance is an umbrella activity that is applied is at each step in the

software process. SQA encompasses procedures for effective application of methods and

tools, formal technical reviews, testing strategies and techniques, procedures for change

control, procedures for assuring compliance to standards and measurement and reporting

mechanism.

Purpose of Plan

The SQA plan provides a road map for instituting software quality assurance. The

plan serves as template for SQA activities that are instituted for each software project.

Management

Management section of the plan describes SQA’s place in the organizational

structure, SQA tasks and activities and their placement through out the software process and

the organizational roles and responsibilities relative to product quality.

2.10 Feasibility

The feasibility study involved in the conception of the project requires a study of the

environment as well as the risks involved in the development of the project. Proper

estimation has to be carried out to ensure timely delivery of components as well as the cost

effective solutions.

Technical Feasibility

The work for the project can be done with presently available equipment current

procedures, existing technology and available manpower . No new technology needs to be

introduced hence system is technically feasible. We are going to use programming language

18


JAVA for this product development hence we can say that technically the project is platform

independent.

Financial feasibility

The minimum hardware and software equipment required for running the system is

already available. The only cost incurred is that of developing and maintenance of the

system. Hence system is cost effective and economically feasible.

Operational feasibility

The system is designed keeping in mind the user requirements and can be implemented

with existing personnel. Implementing the system is not a major concern as system is user

friendly and easy to work.

Cost Feasibility

The costing feasibility of the project can be estimated using current estimation

models such as lines of code, which allows us to estimate cost as a function of size. Thus,

this also allows us to estimate and analyze the feasibility of competition of the system in the

given time frame. This allows us to have a realistic estimate as well as a continuous

evaluative perspective of the progress of the project.

19


CHAPTER 3

SYSTEM DESIGN

3.1 Design Considerations :

3.1.1 Assumptions and Dependencies

Related Software and hardware

In order to write a code using JAVA we need to install Netbeans-6.7.1and JDK1.6.

We use NetBeans refers to both a platform for the development of Java desktop applications,

and an integrated development environment (IDE) .

Operating system

With minor allowances for the peculiarities of particular operating systems, the

application can be modified to act largely platform independent since it has been written in

JAVA. The application has however been developed using Windows XP and will naturally

work without changes on the operating systems.

End user characteristics

The end user of system will be employees of a any organization or colleges. So

the system has been developed keeping in mind certain assumptions regarding knowledge

of LAN based system . The system can be deployed in company or colleges having a LAN

administration.

3.1.2 General constraints

The project operates under a number of design and implementation constraints.Some

of these are as outlined below:

Hardware and Software constraints

Since the project has been developed entirely using JAVA and object oriented

methodology, it is largely independent. The project can be run on any platform. However, it

still needs a JAVA framework to run (Net Beans).

20


End user constraints

As mentioned above the major constraints for the end user is having a Java framework

on his computer.Also he should be familiar with the the operation with the system to a

certain extent,although a help document will be provided to oriented users.

Design Methodology

The design is a primarily top down approach, identifying all the distinct modules in the

system and the interfaces between them and then moving down into each module to design

the increasingly more detailed aspects such as the beans and classes being used for

implementation.

Database and Repository requirements

We intend to use a temporary database for the storage of data like file system.

Network connection

As the name suggest the project is nothing but LAN. It is the most important thing in

the project.

3.2 JAVA Language

When the chronicle of computer languages is written, the following will be said: B led to

C, C evolved into C++, and C++ set the stage for Java. To understand Java is to

understand the reasons that drove its creation, the forces that shaped it, and the legacy that it

inherits. Like the successful computer languages that came before, Java is a blend of the best

elements of its rich heritage combined with the innovative concepts required by its unique

environment. The key considerations were summed up by the Java team in the following list

of buzzwords:

• Simple

• Secure

• Portable

• Object-oriented

21


• Robust

• Multithreaded

• Architecture-neutral

• Interpreted

• High performance

• Distributed

• Dynamic

3.3 Design Strategy

User Assistance

Following provisions are made for assisting the user

Reporting : Error reporting performed through pop-up responses.

User docs: Documents for users through User manuals.

Error Handling Reporting

Following error handling will be provided:

User input validation

Return values of the file operations and other functions.

Scalability

Following care is taken to improve scalability:

Worst case size of lists is considered.

Loops in the code are scrutinized for worst-case iterations.

Security

Some security measures are implemented such as authorization of mobile user.

Migration

If we are updating existing software, we will make it as easy as possible for end users

to migrate from previous versions to new versions by considering following things:

22


Using same names for applications, parameters and menu commands as that in

previous one.

Using the same configurable variables as in previous version.

Using the same parameter units as in previous version.

3.4 UML Diagrams

3.4.1 USE CASE DIAGRAM

3.4.2 CLASS DIAGRAM

3.4.3 SEQUENCE DIAGRAM

3.4.4 ACTIVITY DIAGRAM

3.4.5 COLLABORATION DIAGRAM

3.4.6 COMPONENT DIAGRAM

3.4.7 PACKAGE DIAGRAM

3.4.8 DEPLOYMENT DIAGRAM

23


3.4.1 Use Case Diagram

Figure: 3.4.1

Section Purpose

Description When a person registers as an authenticated and valid user then he

is empowered with some operations which he uses according to his

needs and convenience.

Actors Administrator and Mobile User

Preconditions User must be one who has already being enrolled.

24


3.1 Class Diagram

25


3.4.3 Sequence Diagram

26


3.4.4 Activity Diagram

27


3.4.5 Collaboration Diagram

28


3.4.6 Component Diagram

29


3.4.7 Package Diagram

30


3.4.8 Deployment Diagram

31


CHAPTER - 4

IMPLEMENTATION DETAILS

4.1 HARDWARE TOOLS

LAN

PCs (At least two)

Network Cards

GSM Modem

4.2 SOFTWARE TOOLS

J2SE JDK 1.6

NetBeans 6.7.1

Tomcat Apache Server 6.0

Nokia PC Connectivity SDK

4.3 Coding

//Server Side Coding

class MonitorTimerTask extends TimerTask {

public Server parent;

int progress;

public MonitorTimerTask(Server parent) {

this.parent = parent;

progress = 0;

}

public void run() {

32


if(!parent.runningMonitor) {

return;

}

progress++;

if(progress == 6) {

progress = 0;

}

parent.jLabelProcess.setIcon(new ImageIcon(System.getProperty("user.dir") + "\\src\\

zImgPack\\" + progress + ".png"));

if(progress>0) {

return;

}

// see if some clients are offline more than 5 seconds...

if(parent.jCheckAutoRemove.isSelected()) {

for(int i=0;i<parent.clientDB.size();i++) {

long timeNow = Calendar.getInstance().getTimeInMillis();

long timeThen = parent.clientDB.get(i).refreshTime.getTimeInMillis();

if(((timeNow - timeThen)/1000) > 5) {

parent.clientDB.remove(i);

i--;

}

}

parent.updateClients();

parent.updateProcesses();

}

// monitor any client information

File fromClientDir = new File(System.getProperty("user.dir") + "\\FROM CLIENTS");

File clientRequests[] = fromClientDir.listFiles();

33


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

try {

// read object

ObjectInputStream in1 = new ObjectInputStream(new

FileInputStream(clientRequests[i]));

ClientInfo ci = (ClientInfo)in1.readObject();

in1.close();

// process info

parent.processClient(ci);

// delete file after using

clientRequests[i].delete();

}catch(Exception e) {

System.out.println("Exception: " + e);

}

}

// monitor sms

File smsFile = new File(System.getProperty("user.dir") + "\\autoSMS\\out\\last.txt");

if(smsFile.exists()) {

try {

BufferedReader br = new BufferedReader(new FileReader(smsFile));

String msg, temp;

msg = "";

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

msg += temp;

}

br.close();

new File("" + System.getProperty("user.dir") + "\\autoSMS\\out\\last.txt").delete();

parent.addText("SMS RECEIVED!",true);

34


StringTokenizer st = new StringTokenizer(msg,"$$");

Vector <String> msgBroken = new Vector <String> ();

while(st.hasMoreElements()) {

msgBroken.add(st.nextToken());

}

// verify sender

if(msgBroken.get(0).contains(parent.parent.ss.adminNumber)) {

StringTokenizer st2 = new StringTokenizer(msgBroken.get(1),"##");

Vector <String> smsCommand = new Vector <String> ();

while(st2.hasMoreElements()) {

smsCommand.add(st2.nextToken());

}

if(smsCommand.size()==0) {

parent.addText("INVALID MESSAGE FORMAT!",false);

return;

}

if(smsCommand.get(0).equals(parent.parent.ss.passKey)) {

parent.addText("Sender Verified!",false);

smsCommand.remove(0);

}else {

parent.addText("SMS Authentication Failed!",false);

return;

}

if(smsCommand.get(0).equals("LISTALL") && smsCommand.size()==1) {

String msgResponse = "";

parent.addText("CMD: LIST CLIENTS.",false);

msgResponse += "CLIENTS: ";

35



msgResponse += parent.clientDB.get(i).name;

}

sendToAdmin(msgResponse);

}else if(smsCommand.get(0).equals("SD") && smsCommand.size()==2) {

parent.addText("CMD: SHUTDOWN CLIENT (" + smsCommand.get(1) +

").",false);

ClientCommand cc = new ClientCommand();

cc.clientName = smsCommand.get(1);

cc.command = 1;

parent.clientCommandDB.add(cc);

}else if(smsCommand.get(0).equals("STARTP") && smsCommand.size()==3)

{

parent.addText("CMD: START PROCESS (" + smsCommand.get(2) + ")

FOR " + smsCommand.get(1) + ".",false);



cc.command = 2;

cc.parameters.add(smsCommand.get(2));


}else if(smsCommand.get(0).equals("KILL") && smsCommand.size()==3) {

parent.addText("CMD: KILL (" + smsCommand.get(2) + ") FOR " +

smsCommand.get(1),false);



cc.command = 3;

if(!smsCommand.get(2).toUpperCase().endsWith(".EXE")) {

cc.parameters.add(smsCommand.get(2) + ".EXE");

}else {


36


}


}else if(smsCommand.get(0).equals("NEW") && smsCommand.size()==4) {

parent.addText("CMD: CREATE FILE (" + smsCommand.get(2) + ") FOR "

+ smsCommand.get(1),false);



cc.command = 4;




}else if(smsCommand.get(0).equals("DEL") && smsCommand.size()==3) {

parent.addText("CMD: DELETE FILE (" + smsCommand.get(2) + ") FOR "

+ smsCommand.get(1),false);



cc.command = 5;



}else if(smsCommand.get(0).equals("READ") && smsCommand.size()==3) {

parent.addText("CMD: READ FILE (" + smsCommand.get(2) + ") FOR " +




cc.command = 6;



}else if(smsCommand.get(0).equals("LIST") && smsCommand.size()==3) {

parent.addText("CMD: LIST FILES (" + smsCommand.get(2) + ") FOR " +



37



cc.command = 8;



}else if(smsCommand.get(0).equals("MSG") && smsCommand.size()==3) {

parent.addText("CMD: MESSAGE FOR (" + smsCommand.get(1) +

")",false);



cc.command = 7;



}else if(smsCommand.get(0).equals("MSGB") && smsCommand.size()==2) {

parent.addText("CMD: MESSAGE BROADCAST.",false);



cc.clientName = parent.clientDB.get(i).name;

cc.command = 7; // message



}

}else if(smsCommand.get(0).equals("COMP") && smsCommand.size()==2) {

parent.addText("CMD: CODE COMPILE.",false);



cc.clientName = parent.clientDB.get(i).name;

cc.command = 7; // message



}

}else {

38


parent.addText("INVALID MESSAGE FORMAT!",false);

sendToAdmin("INVALID MESSAGE FORMAT!");

}

}else{

parent.addText("SENDER NOT AUTHORISED!",false);

}

br.close();

}catch(Exception e) {

System.out.println("Error Interpreting Message Text: " + e);

}

}

}

39


4.4 ScreenShots

Servlet

40


Servlet is first program to run on the Server side

Servlet is used for communication purpose between Server and Client

Server Main Form

This is main menu provided to the Administrator at Server side

This is used for handling various activities for Administrator at Server Side.

41


Server Form

This is main form provided to Administrator at Server Side.

Administrator can perform various functions on active Clients such as start new

process, shut down client, create file on client machine etc.

42


Client Form

This is GUI provided for Client to view the different activities performed by

Administrator on itself.

Also used to see the messages sent from Administrator.

43


CHAPTER - 5

DEBUGGING AND TESTING

5.1 Testing :

Software Testing is an empirical investigation conducted to provide stakeholders with

information about the quality of the product or service under test, with respect to the context

in which it is intended to operate. This includes, but is not limited to, the process of executing

a program or application with the intent of finding software bugs.

Testing can never completely establish the correctness of computer software. Instead,

it furnishes a criticism or comparison that compares the state and behaviour of the product

against oracles—principles or mechanisms by which someone might recognize a problem.

These oracles may include (but are not limited to) specifications, comparable products, past

versions of the same product, inferences about intended or expected purpose, user or

customer expectations, relevant standards, applicable laws, or other criteria.

Over its existence, computer software has continued to grow in complexity and size.

Every software product has a target audience. For example, the audience for video game

software is completely different from banking software. Therefore, when an organization

develops or otherwise invests in a software product, it presumably must assess whether the

software product will be acceptable to its end users, its target audience, its purchasers, and

other stakeholders. Software testing is the process of attempting to make this assessment.

5.1.1 Static vs. dynamic testing

There are many approaches to software testing. Reviews, walkthroughs or inspections

are considered as static testing, whereas actually executing programmed code with a given

set of test cases is referred to as dynamic testing. The former can be, and unfortunately in

practice often is, omitted, whereas the latter takes place when programs begin to be used for

the first time - which is normally considered the beginning of the testing stage. This may

actually begin before the program is 100% complete in order to test particular sections of

44


code (modules or discrete functions). For example, Spreadsheet programs are, by their very

nature, tested to a large extent "on the fly" during the build process as the result of some

calculation or text manipulation is shown interactively immediately after each formula is

entered.

5.1.2 Testing methods

Software testing methods are traditionally divided into black box testing and white

box testing. These two approaches are used to describe the point of view that a test engineer

takes when designing test cases.

5.1.2.1 Black box testing

Black box testing treats the software as a black box without any knowledge of

internal implementation. Black box testing methods include equivalence partitioning,

boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability

matrix, exploratory testing and specification-based testing.

5.1.2.2 Specification-based testing

Specification-based testing aims to test the functionality according to the requirements.

Thus, the tester inputs data and only sees the output from the test object. This level of testing

usually requires thorough test cases to be provided to the tester who then can simply verify

that for a given input, the output value (or behavior), is the same as the expected value

specified in the test case.

Specification-based testing is necessary but insufficient to guard against certain risks.

5.1.2.3 Advantages and disadvantages

The black box tester has no "bonds" with the code, and a tester's perception is very

simple: a code MUST have bugs. Using the principle, "Ask and you shall receive," black box

testers find bugs where programmers don't. BUT, on the other hand, black box testing is like

a walk in a dark labyrinth without a flashlight, because the tester doesn't know how the back

end was actually constructed. That's why there are situations when 1. A black box tester

writes many test cases to check something that can be tested by only one test case and/or 2.

Some parts of the back end are not tested at all. Therefore, black box testing has the

45


advantage of an unaffiliated opinion on the one hand and the disadvantage of blind exploring

on the other.

5.1.2.4 White box testing

White box testing, by contrast to black box testing, is when the tester has access to the

internal data structures and algorithms (and the code that implement these)

Types of white box testing

The following types of white box testing exist:

Code Coverage - creating tests to satisfy some criteria of code coverage. For

example, the test designer can create tests to cause all statements in the program

to be executed at least once.

Mutation testing methods.

Fault injection methods.

Static Testing - White box testing includes all static testing.

Code completeness evaluation

White box testing methods can also be used to evaluate the completeness of a test

suite that was created with black box testing methods. This allows the software team

to examine parts of a system that are rarely tested and ensures that the most important

function points have been tested.

Two common forms of code coverage are:

Function Coverage, which reports on functions executed

Statement Coverage, which reports on the number of lines executed to

complete the test.

They both return coverage metric, measured as a percentage.

5.1.2.5 Grey Box Testing

In recent years the term grey box testing has come into common usage. This involves

having access to internal data structures and algorithms for purposes of designing the test

cases, but testing at the user, or black-box level.

Manipulating input data and formatting output do not qualify as grey-box because the

input and output are clearly outside of the black-box we are calling the software under test.

This is particularly important when conducting integration testing between two modules of

46


code written by two different developers, where only the interfaces are exposed for test. Grey

box testing may also include reverse engineering to determine, for instance, boundary values

or error messages.

5.1.2.6 Acceptance testing

Acceptance testing can mean one of two things:

A smoke test is used as an acceptance test prior to introducing a build to the main

testing process.

Acceptance testing performed by the customer is known as user acceptance

testing (UAT).

5.1.2.7 Regression Testing

Regression testing is any type of software testing that seeks to uncover software

regressions. Such regressions occur whenever software functionality that was previously

working correctly stops working as intended. Typically regressions occur as an unintended

consequence of program changes. Common methods of regression testing include re-running

previously run tests and checking whether previously fixed faults have re-emerged.

5.1.2.8 Non Functional Software Testing

Special methods exist to test non-functional aspects of software.

Performance testing checks to see if the software can handle large quantities of

data or users. This is generally referred to as software scalability. This activity of

Non Functional Software Testing is often times referred to as Load Testing.

Usability testing is needed to check if the user interface is easy to use and

understand.

Security testing is essential for software which processes confidential data and to

prevent system intrusion by hackers.

In contrast to functional testing, which establishes the correct operation of the

software (correct in that it matches the expected behavior defined in the design

requirements), non-functional testing verifies that the software functions properly even when

it receives invalid or unexpected inputs. Software fault injection, in the form of fuzzing is an

47


example of non-functional testing. Non-functional testing, especially for software, is

designed to establish whether the device under test can tolerate invalid or unexpected inputs,

thereby establishing the robustness of input validation routines as well as error-handling

routines. Various commercial non-functional testing tools are linked from the Software fault

injection page; there are also numerous open-source and free software tools available that

perform non-functional testing.

5.1.3 Testing process

A common practice of software testing is performed by an independent group of

testers after the functionality is developed before it is shipped to the customer. This practice

often results in the testing phase being used as project buffer to compensate for project

delays, thereby compromising the time devoted to testing. Another practice is to start

software testing at the same moment the project starts and it is a continuous process until the

project finishes.

In counterpoint, some emerging software disciplines such as extreme programming

and the agile software development movement, adhere to a "test-driven software

development" model. In this process unit tests are written first, by the software engineers

(often with pair programming in the extreme programming methodology). Of course these

tests fail initially; as they are expected to. Then as code is written it passes incrementally

larger portions of the test suites. The test suites are continuously updated as new failure

conditions and corner cases are discovered, and they are integrated with any regression tests

that are developed. Unit tests are maintained along with the rest of the software source code

and generally integrated into the build process (with inherently interactive tests being

relegated to a partially manual build acceptance process).

Testing can be done on the following levels:

5.1.3.1 Unit testing tests the minimal software component, or module. Each unit (basic

component) of the software is tested to verify that the detailed design for the unit has

been correctly implemented. In an object-oriented environment, this is usually at the

class level, and the minimal unit tests include the constructors and destructors.

48


In computer programming, unit testing is a software design and development method

where the programmer verifies that individual units of source code are working

properly. A unit is the smallest testable part of an application. In procedural

programming a unit may be an individual program, function, procedure, etc., while in

object-oriented programming, the smallest unit is a method, which may belong to a

base/super class, abstract class or derived/child class.

Ideally, each test case is independent from the others; Double objects like stubs, mock

or fake objects as well as test harnesses can be used to assist testing a module in

isolation. Unit testing is typically done by software developers to ensure that the code

other developers have written meets software requirements and behaves as the

developer intended.

5.1.3.2 Integration testing exposes defects in the interfaces and interaction between

integrated components (modules). Progressively larger groups of tested software

components corresponding to elements of the architectural design are integrated and

tested until the software works as a system.

Integration testing' (sometimes called Integration and Testing, abbreviated I&T) is

the phase of software testing in which individual software modules are combined and

tested as a group. It follows unit testing and precedes system testing.

Integration testing takes as its input modules that have been unit tested, groups them

in larger aggregates, applies tests defined in an integration test plan to those

aggregates, and delivers as its output the integrated system ready for system testing.

5.1.3.3 System testing tests a completely integrated system to verify that it meets its

requirements.

5.1.3.4 System integration testing verifies that a system is integrated to any external or third

party systems defined in the system requirements.

5.1.3.5 Regression testing is any type of software testing which seeks to uncover software

regressions. Such regressions occur whenever software functionality that was

previously working correctly stops working as intended. Typically regressions occur

as an unintended consequence of program changes. Common methods of regression

testing include re-running previously run tests and checking whether previously fixed

faults have re-emerged.

49


5.1.3.6 Alpha testing is simulated or actual operational testing by potential users/customers

or an independent test team at the developers' site. Alpha testing is often employed

for off-the-shelf software as a form of internal acceptance testing, before the software

goes to beta testing.

5.1.3.7 Beta testing comes after alpha testing. Versions of the software, known as beta

versions, are released to a limited audience outside of the programming team. The

software is released to groups of people so that further testing can ensure the product

has few faults or bugs. Sometimes, beta versions are made available to the open

public to increase the feedback field to a maximal number of future users.

5.1.3.8 Acceptance testing can be conducted by the end-user, customer, or client to validate

whether or not to accept the product. Acceptance testing may be performed as part of

the hand-off process between any two phases of development.

5.2 Debugging

Debugging is a methodical process of finding and reducing the number of bugs, or

defects, in a computer program or a piece of electronic hardware thus making it behave as

expected. Debugging tends to be harder when various subsystems are tightly coupled, as

changes in one may cause bugs to emerge in another.

5.2.2 Debugging process

Print debugging is the act of watching (live or recorded) trace statements, or print

statements, that indicate the flow of execution of a process.

Often the first step in debugging is to attempt reproduce the problem. This can be a

non-trivial task, for example in case of parallel processes or some unusual software bugs.

Also specific user environment and usage history can make it difficult to reproduce the

problem.

After the bug is reproduced, the input of the program needs to be simplified to make

it easier to debug. For example, a bug in a compiler can make it crash when parsing some

large source file. However, after simplification of the test case, only few lines from the

original source file can be sufficient to reproduce the same crash. Such simplification can be

made manually, using divide-and-conquer approach. The programmer will try to remove

50


some parts of original test case and check if the problem still exists. When debugging the

problem in GUI, the programmer will try to skip some user interaction from the original

problem description and check if remaining actions are sufficient for bug to appear. To

automate test case simplification, delta debugging methods can be used.

After the test case is sufficiently simplified, a programmer can use debugger to

examine program states (values of variables, call stack) and track down the origin of the

problem. Alternatively a tracing can be used. In simple case the tracing is just a few print

statements, which print out the values of variables in certain points of program execution.

Remote Debugging is the process of debugging a program running on a system

different than the debugger. To start remote debugging, debugger connects to a remote

system over a network. Once connected, debugger can control the execution of the program

on the remote system and retrieve information about its state .

Post-Mortem Debugging is the act of debugging the (core) dump of process. The

dump of the process space may be obtained automatically by the system, or manually by the

interactive user. Crash dumps (core dumps) are often generated after a process has terminated

due to an unhandled exception.

51


5.3 T

e

s

t

Cases

52

Test Case id

Test Case Name

Test Description

Expected Result

Actual Result Pass/Fail

1 To check if module responds correctly to any message sent from mobile

Valid message received

Process gets started

Process get started on server machine

Pass

Wrong message format

Process won’t get started

Dose not perform any action

Pass

1.5 Login Page

Enter correct username and password.

Going on the Tabbed Portal with Home Page tab open.

Going on the Tabbed Portal with Home Page tab open.

Pass

1.6 Login Page

Empty username and password fields

Displays Error Message Invalid username or password

Displays Error Message Invalid username or password

Pass

2.1 Registration Page

Empty any of the Field & Click on Submit

Displays Error Message “Fill Up All Entries”.

Displays Error Message “Fill Up All Entries”

Pass

2.2 Registration Page

Fill All the Entries with already existing username.

Displays Error Message “Enter Another Username”

Displays Error Message “Enter Another Username”

Pass

3.1 Contact Page

Enter First Name and Click on submit button

Searches users on Mapped-In and shows their Markers

Searches users on Mapped-In and shows their Markers

Pass


CHAPTER – 6

APPLICATIONS AND FUTURE ENHANCEMENT

53


6.1 Applications

LAN monitoring at the university/college level can be used for monitoring, logging

and retention of network packets that traverse university networks. The goal of this

project is to maintain confidentiality, integrity and availability of the university

network infrastructure and information assets.

LAN Monitoring at the office level can be used to monitor the office LAN by the

administrator at any time if at a particular point he/she cannot be present there.

He/she does not have to depend on any third party information regarding the LAN

and can instead check the LAN status himself using his mobile.

6.2 Future Enhancement

In its current version of the software, we have included basic functionalities to assist

network administrators in their job. Network administration though, includes a wide range of

responsibilities. In the future version to come, effort can be made to include as many

functions of a network administration is possible.

We are going to add this modules

Chatting

Compile And Run Java Program

Provide Application for Mobile handset

CHAPTER 7

CONCLUSION

54


SMS remains the most efficient communication system for pushing the content on to

the mobile devices. Usage of SMS has grown tremendously over the past few years and

many SMS based applications are the most prevalent services in the wireless world today.

SMS are already being used to control remote devices such as precision air-conditioning

systems, building automation systems, monitoring the temperature and switching on/off

electronic devices. Therefore adding SMS capabilities into your existing network and

managing the deskstops and servers is the obvious step in going forward.

The software developed is a server based software application that provides ability to

send and receive SMS messages through GSM network and communicates through

standard TCP/IP protocol. The software is capable of sending the notification to the network

administrator on his mobile device and thereafter the corrective action can be taken by the

network administrator by sending a SMS in a prescribed format. At present the software

provides limited features which can be further extended such as hardware/software inventory

of desktops on the network.

CHAPTER 8

BIBLIOGRAPHY

55


Websites

Java concepts - www.java.sun.com

Java tutorial - www.sun.com/java/tutorial.html

Mobile concepts - www.logixmobile.com

Networking concepts - www.inetworkmonitoring.com

GSM modem concepts - www.forum.nokia.com

Books

“Java complete Reference” by Herbert Schildt

“Microsoft Windows Server 2003 in 24 hours” by Joe Habraken.

“Computer Networks” by Andrew Tanenbum.

“Computer Networks” by Douglas Corner

“Software Engineering ” by Roger Pressman

“Fundamentals of Software Engineering” by Rajib Mall.

56

http://www.forum.nokia.com/

http://www.inetworkmonitoring.com/

http://www.logixmobile.com/

http://www.sun.com/java/tutorial.html

http://www.java.sun.com/