Contents

 Preface………………………………………………………
 Product Specification………………………………………………...
• Problem Identification…………………………………
• Product features…………………………………….
• Advantages…………………………………………..
• Limitations……………………………………..
 Software Engineering Paradigm……………………………………
• Introduction………………………………………
• Paradigm Used………………………………………
 Software Requirement Specification……………………………………
 Technologies Used …………………………………………….
• Java………………………………………………………
• JDBC………………………………………………………
• JMF………………………………………………………
• RMI……………………………………………………….
• Java Applets …………………………………………
• Java Swings…………………………………………….
• MS-Access …………………………………………………
 Project Modules…………………………..………………………………
 Structure Analysis & Design Techniques………………………………
• Zeroth level DFD…………………………………………..
• First level DFD……………………………………………..
• Entity Relationship Diagram………………………………
 Database Design…………………………………………………………
 Data Dictionary………………………………………………………….
 Code Optimization………………………………………………………
 Testing Plans……………………………………………………………..
 Output Screens………………………………………………………….
 Software & Hardware Requirement………………………………….
 Future Prospects……………………………………………………….
 References
• Books
• Website
Preface
In today’s world, the ever increasing use of computers in business and other aspects
has raised a concern over data security. The private data of any organization is critical
to them and need to be hidden from the outside world. An access to data over whole
network openly cannot be considered reliable.

Our project is motivated by the increasing concern over data security. Network
security is the means of ensuring privacy and protecting personal data. Main ponder
is given on maintaining the data of clients and keeping it secure. In our project we
have developed a concept for making security more difficult to breach over a private
network .

Project will be based upon the technology which is platform independent and reliable.
Here the need for all this which also include security is Java 2 Platform. Only the
name is enough. We will be using many features of it starting from Java Applets,
Jdbc, RMI etc.

This project is a complete implementation of a client-server model. In this we have

performed the communication between the client and the server with the help of Java
RMI.

In this project the client can get text, image, audio or video files encrypted through
the server. The files can be decrypted and viewed by the client any time he desires
with the help of the server. The client can use the security services only once he gets
registered at the server after submitting a registration request. The server
administrator has the complete authority to accept, reject or keep the request of client
pending.

We have created a separate login for administrative user and a general user. An
administrator will have separate login id which is password protected and the
administrator account can not be accessed by anybody else.
Product Specification

Problem Definition

The problem that has been undertaken is “Network Security”. In our project we have
developed a concept for making security more difficult to breach over a private
network .
The basic theme is to use RMI(Remote Method Invocation) to access any data that is
on the server . Any critical data is not placed on the client machine in original form.
The data is encrypted using self designed algorithms and to access the data a client
machine(any machine other than server in the network) needs to invoke RMI server.
Then an encrypted copy of data is provided to client .
To read and extract the data client invokes a method on remote server which provides
the decrypted data. The decrypted data can be viewed by the client. So full security is
provided as whole data is encrypted and no data is stored at any machine in original
format.
Also before providing any services to a client, the client is authenticated using
username and password.

Encryption & Decryption

In cryptography, encryption is the process of transforming information (referred to as
plaintext) using an algorithm (called cipher) to make it unreadable to anyone except
those possessing special knowledge, usually referred to as a key. The result of the
process is encrypted information (in cryptography, referred to as ciphertext). In many
contexts, the word encryption also implicitly refers to the reverse process, decryption
(e.g. “software for encryption” can typically also perform decryption), to make the
encrypted information readable again (i.e. to make it unencrypted).
Encryption has long been used by militaries and governments to facilitate secret
communication. Encryption is now used in protecting information within many kinds
of civilian systems, such as computers, networks (e.g. the Internet e-commerce),
mobile telephones, wireless microphones, wireless intercom systems, Bluetooth
devices and bank automatic teller machines. Encryption is also used in digital rights
management to restrict the use of copyrighted material and in software copy
protection to protect against reverse engineering and software piracy.

Product Features

 Text file encryption

 Image file encryption.
 Audio recording and encryption.
 Photo taking through Webcam and encryption
 Audio file encryption.
 Webcam file encryption.
 Desktop capturing and encryption on demand.
 Audio menu.
 Text messaging encryption.

Advantages

 Our software encrypts your data so no one can see it, even those working on
the server or those working on other nodes in the network.
 Secure data transfer over the network is ensured by transferring only the bytes
instead of files.
  Encryption algorithm is implemented through random number generation. So,
the decryption code is hidden from administrator also.
 Our software can be used by any organization or institute to ensure security of
its confidential or sensitive data.
 Our software provides the facility of capturing remote desktop for client.
 Audio and Webcam files can not be opened after encryption which makes it
almost impossible for any intruder to decrypt the file.

Limitations
 No space has been provided to the client on server for storing any crucial
information.
 Single level security is provided during client authentication.
 The same concept is used for securing different kind of user data.
 TCP/IP protocol is being used for transferring bytes over the network but SSL
2.0 provides better security features.
Software Engineering
Paradigm

Introduction
To solve actual problems in an industry setting, a software engineer or a team of
engineers must incorporate a development strategy that encompasses the process,
methods and tools layers and the generic phases.This strategy is often referred to as a
process model or a software engineering paradigm. It is chosen based on the nature
of the project and application, the methods and tools to be used, and the controls and
deliverables that are required. All software development can be characterized as a
problem solving loop in which four distinct stages are encountered: status quo,
problem definition, technical development, technical development and solution
integration .
Status quo represents current state of affairs; problem definition identifies the specific
problem to be solved; technical development solves the problem through the
application of some technology, and solution integration delivers the results to those
who requested the solution in the first place. Regardless of the process model chosen ,
all of the stages coexist simultaneously at some level of detail. Various process
models are as below:

 The Linear Sequential model.

 The Prototyping model.
  The RAD model.
 The Incremental model.
 The Spiral model.

Paradigm Used
The spiral model, also known as the spiral lifecycle model, is a systems development
method (SDM) used in information technology. This model of development combines
the features of the prototyping model and the waterfall model. The spiral model is
intended for large, expensive, and complicated projects.

The steps in the spiral model can be generalized as follows:

1. The new system requirements are defined in as much detail as possible. This
usually involves interviewing a number of users representing all the external
or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.
3. A first prototype of the new system is constructed from the preliminary
design. This is usually a scaled-down system, and represents an approximation
of the characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure:

a) evaluating the first prototype in terms of its strengths, weaknesses, and

risks.
b) defining the requirements of the second prototype.
c) planning and designing the second prototype.
d) constructing and testing the second prototype.

5. At the customer's option, the entire project can be aborted if the risk is deemed
too great. Risk factors might involve development cost overruns, operating-
cost miscalculation, or any other factor that could, in the customer's judgment,
result in a less-than-satisfactory final product.
6. The existing prototype is evaluated in the same manner as was the previous
prototype, and, if necessary, another prototype is developed from it according
to the fourfold procedure outlined above.
 7. The preceding steps are iterated until the customer is satisfied that the refined
prototype represents the final product desired.
8. The final system is constructed, based on the refined prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is
carried out on a continuing basis to prevent large-scale failures and to
minimize downtime.

Software Requirement
Specification
Requirements analysis is the first technical step in the software process. It is at this
point that a general statement of software scope is refined into a concrete
specification that becomes the foundation for all software engineering activities that
follow. Analysis must focus on the information, functional and behavioral domains of
a problem. To better understand what is required, models are created, the problem is
partitioned and representations that depict the essence of requirements and, later,
implementation detail are developed.

The introduction of the software requirement specification states the goals and
objectives of the software describing it in the context of the computer-based system.

The information description provides a detail description of the problem that the
software must solve. Information, flow and structure are documented. Hardware,
software and human interfaces are described for external system elements and
internal software functions.

A description of each function required to solve the problem is presented in the

functional description. A processing narrative is provided for each function, design
constraints are sated and justified, performance characteristics are stated, and one or
more diagrams are included to graphically represent the overall structure of the
software and interplay among software functions and other system elements.

The behavioral description section of the specification examines the operation of the
software as a consequence of external events and internally generated control
characteristics. Validation criteria is the most important section of SRS. Specification
of validation criteria acts as an implicit review of all other requirements. SRS also
includes a bibliography and appendix. In many cases SRS may be accompanied by an
executable prototype, a paper prototype or a preliminary user’s manual.

Technologies Used
Java
Write Once, Run Anywhere

Sun identifies "Write once, run anywhere" as the core value proposition of the Java
platform. Translated from business jargon, this means that the most important
promise of Java technology is that you only have to write your application once--for
the Java platform--and then you'll be able to run it anywhere.

Security

Another key benefit of Java is its security features. Both the language and the
platform were designed from the ground up with security in mind. The Java platform
allows users to download untrusted code over a network and run it in a secure
environment in which it cannot do any harm: it cannot infect the host system with a
virus, cannot read or write files from the hard drive, and so forth. This capability
alone makes the Java platform unique.

Network-centric Programming
Sun's corporate motto has always been "The network is the computer." The designers
of the Java platform believed in the importance of networking and designed the Java
platform to be network-centric. From a programmer's point of view, Java makes it
unbelievably easy to work with resources across a network and to create network-
based applications using client/server or multitier architectures. This means that Java
programmers have a serious head start in the emerging network economy.

Dynamic, Extensible Programs

Java is both dynamic and extensible. Java code is organized in modular object-
oriented units called classes. Classes are stored in separate files and are loaded into
the Java interpreter only when needed. This means that an application can decide as it
is running what classes it needs and can load them when it needs them. It also means
that a program can dynamically extend itself by loading the classes it needs to expand
its functionality.

Internationalization

The Java language and the Java platform were designed from the start with the rest of
the world in mind. Java is the only commonly used programming language that has
internationalization features at its very core, rather than tacked on as an afterthought.
While most programming languages use 8-bit characters that represent only the
alphabets of English and Western European languages, Java uses 16-bit Unicode
characters that represent the phonetic alphabets and ideographic character sets of the
entire world. Java's internationalization features are not restricted to just low-level
character representation, however. The features permeate the Java platform, making it
easier to write internationalized programs with Java than it is with any other
environment.

Performance

Java programs are compiled to a portable intermediate form known as byte codes,
rather than to native machine-language instructions. The Java Virtual Machine runs a
Java program by interpreting these portable byte-code instructions. This architecture
means that Java programs are faster than programs or scripts written in purely
interpreted languages, but they are typically slower than C and C++ programs
compiled to native machine language. Keep in mind, however, that although Java
programs are compiled to byte code, not all of the Java platform is implemented with
interpreted byte codes. For efficiency, computationally intensive portions of the Java
platform--such as the string-manipulation methods--are implemented using native
machine code.

Programmer Efficiency and Time-to-Market

The final, and perhaps most important, reason to use Java is that programmers like it.
Java is an elegant language combined with a powerful and well-designed set of APIs.
Programmers enjoy programming in Java and are usually amazed at how quickly they
can get results with it. Studies have consistently shown that switching to Java
increases programmer efficiency. Because Java is a simple and elegant language with
a well-designed, intuitive set of APIs, programmers write better code with fewer bugs
than for other platforms, again reducing development time.

Java Database Connectivity (JDBC)

It has been estimated that half of all software development involves client/server
operations. A great promise of Java has been the ability to build platform-independent
client/server database applications. In Java 1.2 this has come to fruition with Java
DataBase Connectivity (JDBC).
There is a “standard” database language, Structured Query Language (SQL-92).
JDBC is designed to be platform-independent, so doesn’t need to worry about the
database while programming.
JDBC, like many of the APIs in Java, calls to the logical operations when gathering
data from a database: connect to the database, create a statement and execute the
query, and look at the result set.
To allow this platform independence, JDBC provides a driver manager that
dynamically maintains all the driver objects that were database queries will need.
The driver objects register themselves with the driver manager at the time of loading,
and we can force the loading using Class.forName( ).
To open a database, we must create a “database URL” that specifies:
1. That we’re using JDBC with “jdbc”
2. The “sub protocol”: the name of the driver or the name of a database
connectivity mechanism. Since the design of JDBC was inspired by ODBC,
the first sub protocol available is the “jdbc-odbc bridge,” specified by “odbc”
3. The database identifier. This varies with the database driver used, but it
generally provides a logical name that is mapped by the database
administration software to a physical directory where the database tables are
located. For our database identifier to have any meaning, we must register the
name using our database administration software. (The process of registration
varies from platform to platform.)
All this information is combined into one string, the “database URL.” For example, to
connect through the ODBC sub protocol to a database identified as “people,” the
database URL could be:

String dbUrl = "jdbc:odbc:news";

When we’re ready to connect to the database, we call the static method
DriverManager.getConnection( ), passing it the database URL, the user name, and a
password to get into the database. We get back a Connection object that we can then
use to query and manipulate the database.
Once the connection is made with DriverManager.getConnection( ), we can use the
resulting Connection object to create a Statement object using the createStatement( )
method. With the resulting Statement, we can call executeQuery( ), passing in a string
containing an SQL-92 standard SQL statement.
The executeQuery( ) method returns a ResultSet object, which is quite a bit like an
iterator: the next( ) method moves the iterator to the next record in the statement, or
returns false if the end of the result set has been reached.
We’ll always get a ResultSet object back from executeQuery( ) even if a query results
in an empty set (that is, an exception is not thrown). Note that we must call next( )
once before trying to read any
record data. If the result set is empty, this first call to next( ) will return false. For
each record in the result set, we can select the fields using (among other approaches)
the field name as a string. Also note that the capitalization of the field name is
ignored – it doesn’t matter with an SQL database. We determine the type we’ll get
back by calling getInt( ), getString( ), getFloat( ), etc. At this point, we’ve got our
database data in Java native format and can do whatever we want with it using
ordinary Java code.

Java Application

JDBC-ODBC Bridge

SQL Command Result Set

ODBC Driver

Proprietary protocol

Database
Working With Streams In Java

A Java program uses a stream to either read data items from a source or to write
data items to a destination. Think of a stream as a conduit by which a sequence of
bytes flows from a source to specific program code or from specific program code
to a destination. That conduit can be likened to a wire on which an electrical current
flows, or to a river of water on which boats and barrels float. Stream sources
include files, memory buffers, network sockets, threads, and other streams. Stream
destinations include the same entities as stream sources, and other entities (such as
printers). When a stream of data items flows from a source, that stream is referred
to as an input stream. Similarly, when a stream of data items flows to a destination,
that stream is referred to as an output stream.
Java divides streams into input and output categories.Each class is located in the
java.io package.
Different types of streams:
File Stream Classes

Buffered Stream Classes

Data Stream Classes

JMF
JMF handles time-based media, media which changes with respect to time.

The JMF architecture is organized into three stages:

JMF is built around component architecture. The components are organized into a
number of main categories:

• Media handlers
• Data sources
• Codecs/Effects
• Renderers
• Mux/Demuxes
RMI
Remote method invocation (RMI) an object-oriented variant of remote procedure call,
is the technique of invoking a method of a remote object by using the same syntax
used in local method invocation. A remote object has an interface that specifies
names, argument types, and result types of methods that can be invoked from remote
address spaces.

Mechanism of RMI
Name

Server
Client Process register Server Process
lookup

Client RMI [1] Remote

Program Object
result=remote_obj.method(args)

Proxy represents server object

Proxy Skeleton

Networkk
k
Java RMI allowed programmer to execute remote function class using the same
semantics as local functions calls
Architecture
• The server must first bind its name to the registry
• The client lookup the server name in the registry to establish remote
references.
• The Stub serializing the parameters to skeleton, the skeleton invoking the
remote method and serializing the result back to the stub.

Remote Machine

bind
RMI Server

Registry
skeleton

return call lookup

stub

RMI Client

Local Machine
Stub and Skeleton
• A client invokes a remote method, the call is first forwarded to stub.
• The stub is responsible for sending the remote call over to the server-side
skeleton
• The stub opening a socket to the remote server, marshaling the object
parameters and forwarding the data stream to the skeleton.
A skeleton contains a method that receives the remote calls, unmarshals the
parameters, and invokes the actual remote object implementation.

call

skeleton
Stub

RMI Client RMI Server

Java Applets return
A Java applet is an applet delivered in the form of Java bytecode. Java applets can run
in a Web browser using a Java Virtual Machine (JVM), or in Sun's AppletViewer.

Applets are used to provide interactive features to web applications that cannot be
provided by HTML. Since Java's bytecode is platform independent, Java applets can
be executed by browsers for many platforms.Java applets are executed in a sandbox
by most web browsers, preventing them from accessing local data.

Advantages of applets
• The same applet can work on "all" installed versions of Java at the same time,
rather than just the latest plug-in version only.
• it runs in a sandbox, so the user does not need to trust the code, so it can work
without security
approval.
• it is supported by most web browsers.
• it can run at a comparable (but generally slower) speed to other compiled
languages such as C++.
• it can be a real time application.
 • it can move the work from the server to the client, making a web solution
more scalable with the number of users/clients.

Disadvantages of applets
• it can't start up until the Java Virtual Machine is running, and this may have
significant startup time the first time it is used
• if it is uncached, it must be downloaded (usually over the internet), and this
takes time
• if the JRE crashes it will take the browser down with it
• if there is a server error, then it may not be able to retrieve mandatory files.

MS Access
Microsoft Office Access, previously known as Microsoft Access, is a relational
database management system from Microsoft which combines the relational
Microsoft Jet Database Engine with a graphical user interface and software
development tools. It is a member of the 2007 Microsoft Office system.

Access can use data stored in Access/Jet, Microsoft SQL Server, Oracle, or any
ODBC-compliant data container. Skilled software developers and data architects use
it to develop application software. Relatively unskilled programmers and non-
programmer "power users" can use it to build simple applications. It supports some
object-oriented techniques but falls short of being a fully object-oriented development
tool.

Features
One of the benefits of Access from a programmer's perspective is its relative
compatibility with SQL (structured query language) —queries may be viewed and
edited as SQL statements, and SQL statements can be used directly in Macros and
VBA Modules to manipulate Access tables. Users may mix and use both VBA and
"Macros" for programming forms and logic and offers object-oriented possibilities.
MSDE (Microsoft SQL Server Desktop Engine) 2000, a mini-version of MS SQL
Server 2000, is included with the developer edition of Office XP and may be used
with Access as an alternative to the Jet Database Engine.

Starting in MS Access 2000 (Jet 4.0), there is a syntax that allows creating queries
with parameters, in a way that looks like creating stored procedures, but these
procedures are limited to one statement per procedure. Microsoft Access does allow
forms to contain code that is triggered as changes are made to the underlying table (as
long as the modifications are done only with that form), and it is common to use pass-
through queries and other techniques in Access to run stored procedures in RDBMSs
that support these.

Java Swings

Swing is a GUI toolkit for java. It is one part of the Java Foundation Classes(JFC).
Swings includes Graphical User Interface(GUI) widgets such as text boxes, buttons,
split-panes and tables.

Swing widgets provide more sophisticated GUI components than the earlier Abstract
Window Toolkit. Since they are written in pure java, they run the same on all
platforms, unlike the AWT which is tied to the underlying platform’s windowing
system. Swing supports pluggable look and feel – not by using the native platform’s
facilities, but by roughly emulating them. This means you can get any supported look
and feel on any platform.

The disadvantage of light-weight components is possibly slower execution. The

advantage is uniform behaviour on all platforms.
Project Modules

User Module

User Registration
To register the user for using the security services. The user sends a request to the
server giving his details and in turn receives an application ID from the server.

User Login
Before using the data security services the user needs to enter the user ID and
password which are verified by the server.

Password Change
The user can change his password.

Update Profile
The user can update his profile.

Administrator Module
Start Server
Administrator starts the RMI server.

Register Client
The client gets registered in RMI server.

Show Requests
The requests of all the clients wishing to get registered are shown one by one. The
administrator can accept, reject or keep the request pending.

User List
List of all the users is shown and administrator can view the details of any particular
user at a time. The administrator can also delete any user account.

Encryption Module

Text File Encryption

Any text file can be encrypted by the client by invoking a remote method on the
server.

Image File Encryption

An image file can be encrypted by the client by invoking a remote method on the
server.

Audio File Encryption

Any audio file can be encrypted by the client by invoking a remote method on the
server.
The client can also record an audio which is then encrypted by server and encrypted
file is stored on client machine.
Webcam File Encryption
Any video file can be encrypted by the client by invoking a remote method on the
server.

Decryption Module

Text File Decryption

Any encrypted text file can be decrypted by the client by invoking a remote method
on the server.

Image File Decryption

An encrypted image file can be decrypted by the client by invoking a remote method
on the server.

Audio File Decryption

Any encrypted audio file can be decrypted by the client by invoking a remote method
on the server.

Webcam File Decryption

Any encrypted video file can be decrypted by the client by invoking a remote method
on the server.

Desktop Capturing Module

The client can view the remote desktop by invoking a remote method on the server.
DFD
0 Level DFD
 Start Server Register Client

Homepage User registration

Login Client application

Change pwd Exit

Text Text Decryption

Encryption

Text Messaging
Text messaging Decryption
Encryption

Audio
Audio Record Decryption
Encryption

Webcam File Webcam file

Encryption Decryption

Dessktop
capturing Desktop
Application: capturing
Encryption
Network Decryption
Security
 Input
Process Valid
frmUserRegister to store UserInfo
Invalid data
UID

Input
frmUserLogin Process PasswordInfo
to store
Invalid data

UID

Process
to check
UserID Enabled the tools.

User Registration and Login

 Send the TCP/IP
Remote RMI Server side
encrypte
machine server stub
d bytes.

1. Fetch the bytes

TCP/IP 2. Obtain user’s 1.Create a
key from file
database 2. Write the
3. Encrypt bytes encrypted
using key. bytes into
file.

1. Read
Send bytes
data from
by invoking
file.
RMI Choose a text Client side Client
2. Convert
method. file to encrypt stub machine
file into
(encText)
bytes.

Text File Encryption

 Send the TCP/IP
Remote RMI Server side
decrypte
machine server stub
d bytes.

1. Fetch the bytes

TCP/IP 2. Obtain user’s 1.Create a
key from file
database 2. Write the
3. Decrypt bytes decrypted
using key. bytes into
file.

1. Read
Send bytes
data from
by invoking
file.
RMI Choose a text Client side Client
2. Convert
method. file to decrypt stub machine
file into
(decText)
bytes.

Text File Decryption

 TCP/I
Remote RMI Server P
machine server side stub
1. Create file.
2. Get reference
Call of file in BIS.
getImage 3. Read from BIS.
. 4. Write into
1. Create file. bytes.
TCP/I 2. Get
P reference of file TCP/IP
in BOS. TCP/IP
3. Write bytes
into BOS. Download
Send filename encrypted bytes 1. Create file.
by invoking & image by 2. Get
RMI method. invoking RMI reference of
(download) method file in BOS.
(download). 3. Write bytes
into BOS.
1. Read
Upload bytes data from
by invoking file.
RMI method 2. Convert Choose an Client
(upload) file into Client side
image file
bytes. stub
to encrypt machine

Image File Encryption

 1. Create new
Get Get 1. Create new FileOutputStrea
reference reference BAOS. m (FOS) for
of file in of IS in 2. Read data temp.dat. temp
IS. BIS. from BIS. 2. Encrypt byte .dat
3. Write data in array. temp.da
creat
BAOS. 3. Write byte t ed.
4. Convert BAOS array into FOS. created.
in byte array.

Input

1. Get reference of file

in FOS.
2. Create new
Grab BufferedImage (BI)
Encrypt
Convert pixels according to image
pixels using
file into of size.
rowFlipPixel temp.jp
image. image. 3. Get reference of
. g
FOS in JPEG Image created.
Encoder.
4.Encode FOS into BI.

getImage
 TCP/IP Bytes
Remote RMI Server side
machine server stub

TCP/IP 1. Decrypt
Call
bytes.
decByte 1. Get
2. Return
s reference of
Bytes
bytes.
file in FOS.
2. Write
bytes into
FOS.

1. Create a file.
Send bytes
2. Get reference
by invoking
of file in BIS. Choose an
RMI Client side Client
3. Read from image file to
method. stub
BIS and write decrypt
(imgdec) machine
into bytes.

]
Image File Decryption
 Send the TCP/IP
Remote RMI Server side
encrypte
machine server stub
d bytes.

1. Fetch the bytes

TCP/IP
2. Obtain user’s
key from 1. Create a file
database 2. Get reference
Send bytes by 3. Encrypt bytes of file into BOS.
invoking RMI using key. 3. Read encrypted
method. bytes.
(encAudio) 4. Write
encrypted bytes
into file.

1. Get reference of
captured file into Call
BufferedInputStream Request to captur Client
. stop e Request to Client side
2. Read from file. recording Audio record. stub
machine
3. Write into bytes.

Audio File Recording and Encryption

 1. Get Audio format.
2. Set audio format in
TargetDataLine(TDL).
3. Get reference of audio device
according to audio format.
4. Open audio line.
5. Start audio line.
6. Start saveThread &
captureThread.

1. Get audio format.

2. Set Audio format in TDL.
3. Get reference of TDL in saveLine. 1. Create new
4. Create new Audio file. ByteArrayOutputStream
5. Open saveLine. (BAOS).
6. Start saving. 2. Read from audio line
7. Get reference of saveLine in into buffer.
AudioInputStream(AIS). 3. Write from buffer into
8. Write from AIS into audio file. BAOS.

CaptureAudio
 Send the TCP/IP
Remote RMI Server side
encrypte
machine server stub
d bytes.

1. Fetch the bytes

TCP/IP 2. Obtain user’s
key from 1. Create file.
database 2. Write the
3. Encrypt bytes encrypted
using key. bytes into
file.

1. Read
Send bytes
data from
by invoking
file. Choose an
RMI Client side Client
2. Convert audio file to
method. stub machine
file into encrypt.
(encAudio)
bytes.

Audio File Encryption

 Send the TCP/IP
Remote RMI Server side
decrypte
machine server stub
d bytes.

1. Fetch the bytes

TCP/IP 2. Obtain user’s
key from 1.Create file.
database 2. Write the
3. Decrypt bytes decrypted
using key. bytes into
file.

1. Read
Send bytes
data from
by invoking
file. Choose an
RMI Client side Client
2. Convert audio file to
method. stub machine
file into decrypt.
(decAudio)
bytes.

Audio File Decryption

 Send
the TCP/IP
Remote RMI Server
encrypt
machine server side stub
ed
bytes.

1. Fetch the
bytes
TCP/IP 2. Obtain 1.Create a
user’s key from file
database 2. Write
3. Encrypt the
bytes using encrypted
key. bytes into
file.

Send 1. Read
bytes by data from
invoking file.
RMI 2. Choose a Client
Client side
method. Convert video file to
stub
(encVideo file into encrypt. machine
) bytes.

Webcam File Encryption

 Send the TCP/IP
Remote RMI Server side
decrypte
machine server stub
d bytes.

1. Fetch the bytes

TCP/IP 2. Obtain user’s 1. Create
key from file.
database 2. Write the
3. Decrypt bytes decrypted
using key. bytes into
file.

1. Read
Send bytes
data from
by invoking
file. Choose an
RMI Client side Client
2. Convert audio file to
method. stub machine
file into decrypt.
(decVideo)
bytes.

Webcam File Decryption

Database Design
Database Design is an iterative process. For the database to meet its objectives, its
design must be complete and consistent. All the significant inputs should be used in
the design process including the inputs of the users. Designing a database requires
gathering details about the application and transactions that are to be supported and
the class of the user that will use the system. Following are the steps involved in the
database design:-

Definition of the problem

The first step in designing a database is identifying and roughly outlining the
problem.

Analysis of existing system and procedures:

In the second phase analysis of existing system and procedures, the impact of the
proposed system on the operations of the departments must be considered.

Preliminary Design:
A preliminary design of the proposed system is derived in this step. This design is
evaluated against the initial requirements. The users are consulted and required
changes are made to the design.

Computing system Design:

Since the database is to be implemented on an existing computer system, the choice
was limited for a database system. The existing system must be able to meet the
storage and processing needs of the proposed DBMS.

Final Design:
In this phase the preliminary design of the database in phase III is translated into
DBMS specific conceptual scheme.
While designing the database following factors must be kept in mind:-
 Database must be designed in such way that can be structured and so that any
pertinent relation between entities can be represented.
 Database should be design keeping in view the previous requirements of the
system and whether the system can be built according to the proposed design.
 Can it be improved, to reduce the need to reconstruct or reorganize the data
when new application requirements arise.
 Database is to be designed in a way so as to eliminate the redundancy of data.
Data Dictionary
During the design it was decided to maintain two tables in the database UserReg.The
listing of tables is given in the following pages:-

1.Table Name:UserInfo

S.NO NAME TYPE SIZE Remark

1 Uid Text 50 -.-
2 Name Text 50 -.-
3 FatherName Text 50 -.-
4 DOB Date -.-
5 Gender Text 50 -.-
6 Address Text 100 -.-
7 City Text 50 -.-
8 State Text 50 -.-
9 Country Text 50 -.-
10 EMail Text 50 -.-
11 Phone Text 50 -.-
12 Password Text 50 -.-
13 Security Text 50 -.-
question
14 Answer Text 50 -.-
Code Optimization
Code optimization involves the application of rules and algorithms to program code
with the goal making it faster, smaller, more efficient and so on. Often these types of
optimizations conflicts each other. For instance, faster codes usually end up larger,
not smaller. Optimization can be performed at several levels (Ex. Source code,
intermediate representations), and by various parties, such as the developer or the
compiler /optimizer.

Why optimize the Code:-

If it’s such a bad idea, why optimize at all? Well, in an ideal world u wouldn’t. But
the reality is that sometimes the biggest problem with a program is that requires
simply too many resources (memory, CPU, network bandwidth, or a combination)
may be limited.

Some points for code Optimization

 If your code already works, optimizing s a sure way to introduce new and
possibly subtle, bugs.
 Optimization tends to make code harder to understand and maintain.
 Some of the techniques presented here increase speed by reducing the
extensibility of the code.
 Optimizing code for one platform may actually make it worse on another
platform.
  A lot of time can be spent optimizing, with little gain in performance, and
can result in obfuscated code.

Testing Plans
A good test plan is the cornerstone of a successful testing implementation. While
every testing effort may be unique, most test plans include a common content
framework. The scope and purpose of the test plan are as follows:

• Purpose - Describe why the test plan was developed--what the objectives are.
This may include documenting test requirements, defining testing strategies,
identifying resources, estimating schedules and project deliverables.
• Background - Explain any events that caused the test plan to be developed.
This can include implementing improved processes, or the addition of new
environments or functionality.
• Technical Architecture - diagram the components that make up the system
under test. Include data storage and transfer connections and describe the
purpose each component serves including how it is updated. Document the
layers such as presentation/interface, database, report writer, etc. A higher
level diagram showing how the system under test fits into a larger automation
picture also can be included if available.
• Specifications - list all required hardware and software including vendors and
versions.
• Scope - briefly describe the resources that the plan requires, areas of
responsibility, stages and potential risks.
 • Project Information - identify all the information that is available in relation
to this project. User documentation, project plan, product specifications,
training materials and executive overview materials are examples of project
information.

Requirements

This section of the test plan lists all requirements to be tested.

• Functional Test Requirements - all functions to be tested, such as creating,

editing and deleting records, are listed. This can be a fairly comprehensive
listing for a full system test, or it may refer to another document.
• Design Requirements - testing the user interface, menu structures or other
forms of design elements also should be listed.
• Integration Requirements - the requirements for testing the flow of data
from one component to the other may be included if it will be part of the test
plan.

Test Strategy

This section describes how the test objectives will be met for each type of testing that
may be part of the test plan: unit, function, integration, system, volume, stress,
performance, configuration and/or installation testing. For each subset, following
details will be mentioned:

• Objective - the overall objective this strategy is designed to meet. For a

complete system test, this may be a statement that all functional requirements
must behave as expected or as documented.
 • Technique - document how test cases were developed, the tool(s) used to
store them and where they can be found, how they will be executed, and the
data to be used. Make notes here if tests are to be performed in cycles, or in
concert with other testing efforts.
• Special Considerations - unique or necessary system setup, data or other test
dependencies; environment conditions or other aspects that are required to
establish a known state for testing.
• Test Cases - list or refer to the actual test cases that will be carried out to
implement the plan. (See Anatomy of a Test Case on page 7 of this issue.)
• Completion Criteria - record the criteria that will be used to determine
pass/fail of tests and the action that is to be taken based on test results.
• Assumptions - describe any outside projects or issues that may impact the
effectiveness or timeliness of the test effort.
• Tools - document the tools that will be employed for testing. Cite the vendor,
version and the help desk number to call for support.

Resources

The resource roles and responsibilities that will be required for test plan execution
will be identified.

• Project Plan - develop a project plan showing the phases, tasks, and
resources. Update the project plan as needed to reflect such events as changes
in deadlines or available resources.

Schedule

The schedule in which the application under test is to be made available for testing,
and the estimated time for executing test cases will be documented. Specify if
frequent builds will be provided on a regular basis during the test cycle, or when
system components are expected to be ready for testing.

Deliverables
All the deliverables that are associated with the testing effort, and where copies of
these deliverables or documents may be located are listed. This includes the test plan
itself, test scripts, test cases and project plan.

Defect Tracking and Reporting

The tool and process used to record and track defects will be documented. Any
reports to be produced will be listed and recipients, frequencies, delivery mechanisms
and examples will be included. Team resources involved in the defect tracking
process will be identified.

Ratings, categories or classifications used to identify or prioritize defects will be

described. Following are sample categories for prioritizing defects:

• Critical - denotes an unusable function that causes an abend or general

protection fault, or when a change in one area of the application causes a
problem elsewhere.
• Severe - a function does not perform as required or designed, or an interface
object does not work as presented.
• Annoyance - function works but not as quickly as expected, or does not
conform to standards and conventions.
• Cosmetic - not critical to system performance: misspelled words, incorrect
formatting, vague or confusing error messages or warnings.

Approval

The test plan will be reviewed by all responsible for its execution, and approved by
the test team, product and development managers. Provision for approval signatures
at the bottom of the test plan will be given. A walkthrough meeting with all parties in
attendance is the most effective method of obtaining test plan approval.

Results
When the test effort is complete, the results will be documented. Any discrepancies
between the plan and the actual implementation will be identified, and how those
discrepancies were handled will be documented.

Testing strategies that can be used:

White Box Testing Strategy

White box testing strategy deals with the internal logic and structure of the code.
White box testing is also called as glass, structural, open box or clear box testing. The
tests written based on the white box testing strategy incorporate coverage of the code
written, branches, paths, statements and internal logic of the code etc.

In order to implement white box testing, the tester has to deal with the code and hence
is needed to possess knowledge of coding and logic i.e. internal working of the code.
White box test also needs the tester to look into the code and find out which
unit/statement/chunkof the code is malfunctioning.

Advantages of White box testing are:

i) As the knowledge of internal coding structure is prerequisite, it becomes very easy

to find out which type of input/data can help in testing the application effectively.
ii) The other advantage of white box testing is that it helps in optimizing the code
iii) It helps in removing the extra lines of code, which can bring in hidden defects.

Disadvantages of white box testing are:

i) As knowledge of code and internal structure is a prerequisite, a skilled tester is
needed to carry out this type of testing, which increases the cost.
ii) And it is nearly impossible to look into every bit of code to find out hidden errors,
which may create problems, resulting in failure of the application.

Types of testing under White/Glass Box Testing Strategy:

Unit Testing:
The developer carries out unit testing in order to check if the particular module or unit
of code is working fine. The Unit Testing comes at the very basic level as it is carried
out as and when the unit of the code is developed or a particular functionality is built.

Static and dynamic Analysis:

Static analysis involves going through the code in order to find out any possible
defect in the code. Dynamic analysis involves executing the code and analyzing the
output.

Statement Coverage:
In this type of testing the code is executed in such a manner that every statement of
the application is executed at least once. It helps in assuring that all the statements
execute without any side effect.

Branch Coverage:
No software application can be written in a continuous mode of coding, at some point
we need to branch out the code in order to perform a particular functionality. Branch
coverage testing helps in validating of all the branches in the code and making sure
that no branching leads to abnormal behavior of the application.
Security Testing:
Security Testing is carried out in order to find out how well the system can protect
itself from unauthorized access, hacking – cracking, any code damage etc. which
deals with the code of application. This type of testing needs sophisticated testing
techniques.

Mutation Testing:
A kind of testing in which, the application is tested for the code that was modified
after fixing a particular bug/defect. It also helps in finding out which code and which
strategy of coding can help in developing the functionality effectively.

Besides all the testing types given above, there are some more types which fall under
both Black box and White box testing strategies such as: Functional testing (which
deals with the code in order to check its functional performance), Incremental
integration testing (which deals with the testing of newly added code in the
application), Performance and Load testing (which helps in finding out how the
particular code manages resources and give performance etc.) etc.

Black Box Testing Strategy

Black Box Testing is not a type of testing; it instead is a testing strategy, which does
not need any knowledge of internal design or code etc. As the name "black box"
suggests, no knowledge of internal logic or code structure is required. The types of
testing under this strategy are totally based/focused on the testing for requirements
and functionality of the work product/software application. Black box testing is
sometimes also called as "Opaque Testing", "Functional/Behavioral Testing" and
"Closed Box Testing".

The base of the Black box testing strategy lies in the selection of appropriate data as
per functionality and testing it against the functional specifications in order to check
for normal and abnormal behavior of the system. Now a days, it is becoming common
to route the Testing work to a third party as the developer of the system knows too
much of the internal logic and coding of the system, which makes it unfit to test the
application by the developer.

In order to implement Black Box Testing Strategy, the tester is needed to be thorough
with the requirement specifications of the system and as a user, should know, how the
system should behave in response to the particular action.

Various testing types that fall under the Black Box Testing strategy are: functional
testing, stress testing, recovery testing, volume testing, User Acceptance Testing (also
known as UAT), system testing, Sanity or Smoke testing, load testing, Usability
testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing etc.

These testing types are again divided in two groups: a) Testing in which user plays a
role of tester and b) User is not required.

Testing method where user is not required:

Functional Testing:
In this type of testing, the software is tested for the functional requirements. The tests
are written in order to check if the application behaves as expected.

Stress Testing:
The application is tested against heavy load such as complex numerical values, large
number of inputs, large number of queries etc. which checks for the stress/load the
applications can withstand.

Load Testing:
The application is tested against heavy loads or inputs such as testing of web sites in
order to find out at what point the web-site/application fails or at what point its
performance degrades.

Ad-hoc Testing:
This type of testing is done without any formal Test Plan or Test Case creation. Ad-
hoc testing helps in deciding the scope and duration of the various other testing and it
also helps testers in learning the application prior starting with any other testing.

Exploratory Testing:
This testing is similar to the ad-hoc testing and is done in order to learn/explore the
application.

Usability Testing:
This testing is also called as ‘Testing for User-Friendliness’. This testing is done if
User Interface of the application stands an important consideration and needs to be
specific for the specific type of user.

Smoke Testing:
This type of testing is also called sanity testing and is done in order to check if the
application is ready for further major testing and is working properly without failing
up to least expected level.

Recovery Testing:
Recovery testing is basically done in order to check how fast and better the
application can recover against any type of crash or hardware failure etc. Type or
extent of recovery is specified in the requirement specifications.

Volume Testing:
Volume testing is done against the efficiency of the application. Huge amount of data
is processed through the application (which is being tested) in order to check the
extreme limitations of the system.

Testing where user plays a role/user is required:

User Acceptance Testing:

In this type of testing, the software is handed over to the user in order to find out if
the software meets the user expectations and works as it is expected to.

Alpha Testing:
In this type of testing, the users are invited at the development center where they use
the application and the developers note every particular input or action carried out by
the user. Any type of abnormal behavior of the system is noted and rectified by the
developers.

Beta Testing:
In this type of testing, the software is distributed as a beta version to the users and
users test the application at their sites. As the users explore the software, in case if
any exception/defect occurs that is reported to the developers.
Output
Screens
Software & Hardware
Requirement

Software Requirement:

Concept => Intranet Application

Technologies => Client-Server Technology

Front-End Tool => Applets, Swings

Back-End Tool => MS-Access

Environment => Private network

Hardware Requirements:

Machine => Intel 80x

HDD => 4.3 GB

RAM => 128MB

CD ROM => 48 X

Clock Speed => 450 MHz

Cost & Time Requirement

The cost depends upon the Hardware and Software used for viewing this
project and no other cost is required.

The time required for this project was about 4 months and this project required
a deep knowledge of Microsoft Visual Studio 2005 and steaming.
Future Prospects

In the present world of scenario computer software has become a driving force . It is
the engine that drives various decision making processes. It serves as the basis for
modern scientific investigation. It is embedded in systems of all kinds. Software is
virtually inescapable in a modern world as we move into 21st century. It will become
the driver for new advances in everything.

Our project can be extended to online transactions like e-banking , e-shopping , e-

billing .Important files and documents like files containing account number and other
personal details in banks can be encrypted and kept secure.

The project can also be implemented in a military background by making the security
even more tighter and by using more complex encryption algorithms. Multiple
encryption algorithms can be used which are even more difficult to crack. This would
help keep the crucial national strategic information secure.

References

BOOKS

 Complete Reference in Java - Herbert Nesfield & James Gosling

 Software Engineering – Roger S. Pressman

 Java Tutorial -- SUN MICROSYSTEM

 JDBC Complete -- TechMedia

WEBSITES
 www.sun.com
 www.mhhe.com/engcs/compsci/pressman
 www.osborne.com