1.

INTRODUCTION
1.1 MOTIVATION
Computer lab maintained is a very simple application which can be used in
any college by the inchrge. Any member with VALID ID CARD can get issue of a
particular component that he wanted. In this application the inchrge should check the
component availability in the database if the component is available then the inchrge
can issue the component to the member if the component is not available he cannot issue
the component to the member. In this application i.e. the computer lab maintance can
display the members that are in the college, and it displays the components available in
the lab, it displays the Final Report Respectively. This simple application displays the
Issue report and also displays the component’s list form the database that are available in
the lab through the component Availability Form.
1.2 Problem Definition
This section is explained about the background of current system scenario.
Rational Unified Process (RUP) is used to visualize the system flow on how the systems
are runs. All the problems in the current system will be listed and explained in detail. The
logical problem analysis method basically falls into three parts such as identifies the
problems, choosing the best solution and implement the solution.
1.3 OBJECTIVES OF THE PROJECT
 To provide each and every detail of the component present in the database if it
is available.
 To provide the records of the member present in the institution.
 To generate the reports for the final details for the lab.
 To build a monitoring system that is able to monitor and manage all lab
operations efficiently.
 To store properly the lab items in order to maintain their security.
 To ensure and preserve details of the various issues and keep a track on their
return.

1
  To build a system that can receive input and generate automatically output in easy
way and short time.

2. LITERATURE SURVEY
2.1 INTRODUCTION
The literature review and project methodology is a chapter that describes the
analysis and findings on passed research, case study or research that relates with this
project, computer lab maintance and it also review the selected approach or
methodology used in this system detail.
2.2 EXISTING SYSTEM
Earlier this process was done manually by entering the details of the user and
component in a particular component and was very hectic to the inchrge to maintain
those details. This process has become very complex in course of time and burden in
this process.
2.3 PROBLEMS IN EXISTING SYSTEM
 It is time taking process for the inchrge and user.
 It is very difficult to maintain the details of the user and component where it
was entered manually.
2.4 PROPOSED SYSTEM
We provide maintance service for lab computer like server, network ...Etc
here, the security and uniform maintance will provide. It is very easy to maintain the
details of the component& labs, etc., Hence this process is the most convenient in all
aspects compared to the existence system.

2
 3. ANALYSIS
3.1 INTRODUCTION
This chapter will cover the problem analysis, requirement analysis and conclusion
of the analysis. From the analysis, the criteria and problem of the current system will be
analyze and characterized.
3.2 Software Requirement Specification
3.2.1 Software Requirement

Working Platform : Windows

Front-End Tool : JDK 1.6.0
Back-End Tool : ORACLE10g

3.2.2 Hardware Requirement

Processor : Intel Pentium 4

Ram : 1GB
Hard Disk : 60GB
Operating System : Windows XP
3.3 Content Diagram of the Project (Architecture)

The system requires two-tier architecture for its execution on the client-server
architecture, if the database is remote.
CLIENT AND SERVER
A machine, probably one per user, could be designed such that the data I kept on
one more shared files servers. The users of such systems architectures or such systems
themselves are called CLIENTS. The communication generally takes the form of a
request message from the client to the server asking for some work to be done like the
retrieval of the payments information or the report generation of the total expenses in the

3
current application. The server then does the work and sends back the reply. Usually
there are many clients using small number of servers.
4. DESIGN
4.1 Introduction
The design phase is consisting of 3 activities. The activities are:
a. Logical design
This activity involves class diagram and interaction diagram
b. Interface design
The activity includes navigation design, output design and input design.
c. Database design
This activity defines logical data model, detail explanation for each entity,
description of the association, cardinality and relationship.
4.2 Project Diagrams(ER/UML)
ER Diagram

The Entity-Relational data model allows us to describe the data involved in real-
world enterprise in terms of objects (entities) and their relationships and is widely used to
develop an initial data base Database Design
The ER model is important for its role in database design. It provides a useful
concept that allows changing the detailed and informal description of what users want to
a precise and formal description that can be implemented in a DBMS. Within the overall
design process, the ER model is used in a phase called conceptual database design. Even
though the ER model describes the physical database model, it is basically useful in the
design and communication of the logical data base model.

4
 ER_diagram:-

COMPONENTS
LAB
C.NAME
L _ID N-1 C.ID
1-N C.STATUS S/W
L_INCHRGE Allot C.STATUS H/W

Consit

1-N

USER

U-ID

U-NAME

5
RECTANGLES: This represents entity set.

HEXAGON:
This represents relationships among entity sets, which are connected to the
rectangles by lines.
LINES:
This represents attributes to entity sets and entity sets to relationships.
ENTITY:
An entity is a “thing” or “object” in the real world i.e. distinguishable from other
objects. The Entity-relationship model is based on a collection of basic objects, called
entities and the relationship among these objects
ENTITIES:
An entity is a basic object of ER-model which is an object in real world that can
be distinguished and can exists independently.
ENTITY SET:
Similar entities, i.e., the entity having similar properties are grouped together to
form entity set.
ATTRIBUTES:
The properties of entities are called attributes. For example, if we consider a
component as an entity, then each component will have its own name, status, copies. All
these are the attributes of the component.
RELATIONSHIP:
It defines the association among two entities. Suppose, consider components and lab
are two entities. These entities are associated as “ consit contains lab”. Hence “contains”

is the relationship between the two entities, components and lab.

6
ENTITIES OF THE ER-DIAGRAM:
1. LAB
2. COMPONENTS
3. USER
ATTRIBUTES OF EACH ENTITY:
1. LAB
a. l_ id
b. l_inchrge

2. COMPONENTS
a. c_id
b. c_name
c. c_status s/w
d. c_status h/w

3. USER
A. uid
B. u name
C. u duration

RELATIONSHIP BETWEEN ENTITIES:

The relationship between lab and allot is “contains”, between is component is

consit to the user
KEY CONSTRAINTS:
Key constraints are used in relations to uniquely identify some records of the
relation. A key constraint can be defined as a statement that consists of minimal subset of
attributes that uniquely determine a record in a table. This set of attributes that work in

7
accordance with the key constraint is called candidate key. A candidate key is a
collection of fields that uniquely identifies a tuple.

COMPOSITE KEY:
It consists of more than one attribute that uniquely identifies a tuple in a relation.
All the attributes that form a set of them taken together determines a unique row in a
table.

SUPER KEY:
It is a combination of both candidate key and composite key. That super key is a
set of attributes or a single attribute that uniquely identifies tuple in a relation.

PRIMARY KEY:
Only a single attribute can uniquely identify a particular record. More
specifically, it can be defined as the candidate key who has been selected as key identifies
unique records.
By the above we have different keys for the attributes.

ENTITIES AND ATTRIBUTES

LAB:
Lab is an entity that contains the following attributes.
L id : lab id
Data type : number (primary key)
L inchrge : lab inchrge
Data type : varchar2

LAB
L id L inchrge

8
COMPONENT:
Component is the relation between allot and consit.
cid : component id
Data type : number (foreign key)
C name : component name
Data type number (foreign key)
C status s/w : component status of s/w
Data type : varchar2
C status h/w : component status of h/w
Data type : varchar2

Component
C id C name c status s/w c status h/w

Consit:
Consist is the relation between user and lab
C id : component id
Data type : number (foreign key)
C name : component name
Data type number (foreign key)
C status s/w : status of component
Data type : varchar2
U name : user name
Data type : varchar2
U id :user id

9
 Data type : varcher2

Consist

C id C name C status s/w Uname U id

user :
user is the entity having the following attributes.
uid : user identity
Data type : number (primary key)
u name: user name
Data type : varchar2
U duration : duration of user
Data type : varchar2

User
u id u name u duration

UML Activity diagram

An activity diagram is a variation or special case of a state machine, in which
the states are activities representing the performance of operations and the transitions are
triggered by the completion of the operations. An activity diagram can be used to model
10
an entire business process. The purpose of an activity diagram is to provide a view of
flows and what is going on inside a use case or among several classes. However, activity
diagram can also be used to represent a class’s method implementation. Object, An
activity model is similar to a state chart diagram, where a token represents an operation.
An activity is shown as a round box, containing the name of the operation. When an
operation symbol appears within an activity diagram or other state diagram, it indicates
the execution of the operation. Executing a particular step within the diagram represents a
state within the execution of the overall method. The same operation name may appear
more than once in a state diagram, indicating the invocation of the same operation in
different phases.
An outgoing solid arrow attached to an activity symbol indicates a transition
triggered by the completion of the activity. The name of the implicit event need not be
written, but the conditions that depend on the result of the activity or other values may be
included.
An activity diagram is used mostly to show the internal state of an but external
events may appear in them. An external event appears when the object is in a “wait
state”, a state during which there is no internal activity by the object and the object is
waiting for some external event to occur as the result of an activity by another object. The
two states are wait state and activity state. More than the one possible event might take
the object out of the wait state; the first one that occurs triggers the transition. A wait
state is the “normal state”.
Activity and state diagram express a decision when conditions are used to indicate
different possible transitions that depend on Boolean conditions of container object.
Actions may be organized into swim lanes, each separated from neighboring swim lanes
by vertical solid lines on both sides. Each swim lane represents responsibility for part of
the overall activity and may be implemented by one or more objects.

11
12
USE CASE DIAGRAMS

In many design processes, the use case diagram is the first that designers will work with
when starting a project. This diagram allows for the specification of high level user goals
that the system must carry out. These goals are not necessarily tasks or actions, but can
be more general required functionality of the system. More formally, a use case is made
up of a set of scenarios. Each scenario is a sequence of steps that encompass an
interaction between a user and a system. The use case brings scenarios together that
accomplish a specific goal of the user. A use case can be specified by textually describing
the steps required and any alternative actions at each step.
The use case diagram allows a designer to graphically show these use cases and the
actors that use them. An actor is a role that a user plays in the system. It is important to
distinguish between a user and an actor (better thought of as a role). A user of the system
may play different roles through the course of his, her or its job (since an actor may be
another system).
USECASE DIAGRAM

Login

Lab

User
components Incharge

13
Sequence diagrams

Once the use cases are specified, and some of the core objects in the system are
prototyped on class diagrams, we can start designing the dynamic behavior of the system.
Typically, an Interaction diagram captures the behavior of a single case by showing the
collaboration of the objects in the system to accomplish the task. These diagrams show
objects in the system and the messages that are passed between them. There are two types
of Interaction Diagrams -
Sequence diagram for components:-

L:lab C:components U:user

1. Consist of all components 2.allot to the user

3.

3. Enter into the lab

4. Ask the details

5. Enter details

6. Allot the system

7. Provide the duration of time

8. Exit

14
 Collaboration diagrams

A role is a slot for an object within a collaboration that describes the type of object that
may play the role and its relationships to other roles. However, a sequence diagram does
not show the relationships among the roles or the association among the objects. An
object role is shown as a vertical dashed
Collaboration diagram for computer lab maintance:-

1.provide all facilities

2.user will enter
C: components
L: lab

5.user enter the details

6.use the system

3. Provideto the user

4. Ask the details

U :user 7.Provideduratio
Time

IDENTIFYING CLASSES

We have different methods to identify classes. But for the unified approach we generally
use the ‘use-case driven, sequence/collaboration modeling approach’. But in general we
can combine these approaches to identify the classes for he given problem. The use-case
driven approach identifies the classes and their behaviors through sequence/collaboration
modeling. The process of creating or collaboration diagrams is a systematic way to think
about how a use case can take place; and by doing so, it forces us to think about objects
involved in the application. The following are the classes identified for my application.

15
 LAB : lab is a class that contains the lab details of the lab
COMPONENTS : components are a class that contains the components.

USER : User is a class that contains the user details.

IDENTIFYING RELATIONSHIPS
The objects do not exist independently. They have to interact with other objects to
perform the given responsibilities. The relationship among objects is based on the
assumptions each makes about the other objects, including what operations can be
performed and what behavior results.
CLASS DIAGRAM:

1 * COMPONENTS
Lab

- c id
-Lab id -c name
1 -c status s/w
-Lab inchrge -c status h/w

+Insert ()
+Update ()
+Delete ()
+Select ()

1...*
*
CONSIT Requests
USER
-c id
-c name
-c status s/w - U id
-c status h/w -U name
-U duration 1
ALLOT

-u id
-u inchrge +Insert ()
+Delete ()
+Update ()
16
+Select ()
5. IMPLEMENTATION RESULTS
5.1 INTRODUCTION

In the implementation results the project computer lab maintance system can be
compiled and executed through different ways as discussed
- We can compile the main file of the project using javac mainframe/loginframe.java.
- And execute the file by using java filename.java.
-There is also another form of execution we can write javac *.java in one line and in
another line we can write java filename and save it as run.cmd.
-By clicking the run.cmd automatically all the files in the project will be compiled and
executed and the frames that we require will be displayed.

5.2 EXPLANATION OF KEY FUNCTIONS

The key functions that are present in the project are discussed as shown below.
- In the computer lab maintance we can check the availability of the
components in the database through the components availability form.

- This project provides security to the data present in it because the username
& password can only be known to the inchrge.

17
5.3METHOD OF IMPLEMENTATION

5.3.1 FORMS
Login form
import java.awt.Dimension;
import java.awt.Panel;
import java.awt.Toolkit;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JOptionPane;
import javax.swing.JPasswordField;
import javax.swing.JTextField;

class Login extends JFrame implements ActionListener

{
JTextField txt_uname;
JPasswordField txt_upass;
JLabel lbl_uname,lbl_upass;
JButton bt_login,bt_cancel;
Connection con;
Statement st;
ResultSet rs;
JFrame Logfrm;
Panel panel;
String username="",password="";
Login()
{

try
{
Logfrm=new JFrame("ADMIN LOGIN");
panel=new Panel();

}catch(Exception e){}
setLayout(null);
lbl_uname=new JLabel("ENTER USER NAME :");

18
 lbl_upass=new JLabel("ENTER PASSWORD :");
txt_uname=new JTextField(15);
txt_upass=new JPasswordField(15);
bt_login=new JButton("LOGIN");
bt_cancel=new JButton("CANCEL");

bt_login.setActionCommand("Login");
bt_cancel.setActionCommand("Cancel");
txt_uname.setText("");
txt_upass.setText("");
panel.add(lbl_uname).setBounds(25,40,130,30);
panel.add(lbl_upass).setBounds(25,90,130,30);
panel.add(txt_uname).setBounds(145,45,110,25);
panel.add(txt_upass).setBounds(145,95,110,25);
panel.add(bt_login).setBounds(50,145,80,30);
panel.add(bt_cancel).setBounds(150,145,80,30);
bt_login.addActionListener(this);
bt_cancel.addActionListener(this);

panel.setLayout(null);

Logfrm.add(panel);
Logfrm.setSize(300,250);

Dimension screenSize =
Toolkit.getDefaultToolkit().getScreenSize();
Logfrm.setLocation((screenSize.width -
Logfrm.getWidth()) / 2, (screenSize.height - Logfrm.getHeight()) / 2);
Logfrm.setUndecorated(false);
Logfrm.setResizable(false);
Logfrm.setVisible(true);
}

public void actionPerformed(ActionEvent ae)

{
//System.out.println("within action method");
try
{
if(ae.getSource()==bt_login)
{

if(txt_uname.getText().equals(""))
JOptionPane.showMessageDialog(this,"User ID
shouldn't be blank","Error Message",JOptionPane.ERROR_MESSAGE);
else if(txt_upass.getText().equals(""))

19
 JOptionPane.showMessageDialog(this,"Password
shouldn't be blank","Error Message",JOptionPane.ERROR_MESSAGE);
else
{

Class.forName("oracle.jdbc.driver.OracleDriver");

con=DriverManager.getConnection("jdbc:oracle:thin:@localhost:1522:xe","VAMSI","V
AMSI");
st=con.createStatement();
rs=st.executeQuery("select * from VAMSI.LOGIN where
username='"+txt_uname.getText()+"' and password='"+txt_upass.getText()+"'");

if(rs.next())
{

JOptionPane.showMessageDialog(this,"Your Authentication Successful..");

Logfrm.dispose();
new menudemo1();
//new menudemo();
}
else
{

JOptionPane.showMessageDialog(this,"Please Enter the Correct UserID and

Password","Error Message",JOptionPane.ERROR_MESSAGE);
}

}
if(ae.getSource()==bt_cancel)
{

txt_uname.setText("");
txt_upass.setText("");

}catch(Exception e){}
}

20
}

public class loginform

{
public static void main(String[] args)
{
new Login();
}

Menu form:-
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class menudemo
{
public static void main(String args[])
{
new menudemo1();
}
}
class menudemo1 extends JFrame implements ActionListener
{
JFrame frame;
JMenuBar MenuBar;
JMenu Menu1,Menu2,Menu3,Menu4;
JMenuItem
MenuItem11,MenuItem12,MenuItem13,MenuItem21,MenuItem22,MenuItem31,MenuIte
m41;
JLabel l ,l1,l2,l3,l4;
JPanel p;
menudemo1()
{
frame=new JFrame("COMPUTER LAB
MAINTAINENCE");
MenuBar=new JMenuBar();
p=new JPanel();
frame.add(p);
Menu1=new JMenu("MASTER");
Menu2=new JMenu("TRANSACTIONS");
Menu3=new JMenu("REPORT");
Menu4=new JMenu("EXIT");
MenuItem11=new JMenuItem("lab");
MenuItem12=new JMenuItem("components");

21
 MenuItem13=new JMenuItem("user");
MenuItem21=new JMenuItem("consit");
MenuItem22=new JMenuItem("allots");

MenuItem31=new JMenuItem("report");

MenuItem41=new JMenuItem("quit");
Menu1.add(MenuItem11);
Menu1.addSeparator();
Menu1.add(MenuItem12);
Menu1.addSeparator();
Menu1.add(MenuItem13);
Menu1.addSeparator();
Menu2.add(MenuItem21);
//Menu2.addSeparator();
Menu2.add(MenuItem22);
//Menu2.addSeparator();
Menu3.add(MenuItem31);
//Menu3.addSeparator();

Menu4.add(MenuItem41);

MenuBar.add(Menu1);
MenuBar.add(Menu2);
MenuBar.add(Menu3);
MenuBar.add(Menu4);
MenuItem11.addActionListener(this);
MenuItem12.addActionListener(this);
MenuItem13.addActionListener(this);
MenuItem21.addActionListener(this);
MenuItem22.addActionListener(this);
MenuItem31.addActionListener(this);

MenuItem41.addActionListener(this);

l1=new JLabel();

l1.setText("COMPUTER LAB MAINTAINENCE");

Font f1=new Font("TimesNewRoman",Font.BOLD,20);
l1.setFont(f1);
l1.setForeground(Color.BLUE);

22
 p.add(l1).setBounds(300,170,500,50);
l2=new JLabel("ANDHRA LOYOLA INSTITUTE OF
ENGINEERING & TECHNOLOGY-VIJAYAWADA");
Font f2=new Font("TimesNewRoman",Font.BOLD,20);
l2.setFont(f2);
l2.setForeground(Color.magenta);
p.add(l2).setBounds(120,50,500,20);
l3=new JLabel("Guided By Rev.Fr.THAINESE S.J ");
Font f3=new Font("TimesNewRoman",Font.BOLD,15);
l3.setFont(f3);
l3.setForeground(Color.red);
p.add(l3).setBounds(200,200,500,20);

JLabel img = new JLabel(new ImageIcon("images\\

logo.PNG"));
img.setForeground(Color.BLUE);
p.add(img).setBounds(650,650,300,500);
l4=new JLabel("Designed By K.VANI");
Font f4=new Font("TimesNewRoman",Font.BOLD,16);
l4.setFont(f4);
l4.setForeground(Color.red);
p.add(l4).setBounds(8700,5600,800,90);
frame.setJMenuBar(MenuBar);
frame.setSize(900,600);
frame.setVisible(true);
}
public void actionPerformed(ActionEvent ae)
{
if(ae.getSource()==MenuItem11)
{
new lab1();
}
else if(ae.getSource()==MenuItem12)
{
new components1();

}
else if(ae.getSource()==MenuItem13)
{
new user1();

}
else if(ae.getSource()==MenuItem21)
{
JOptionPane.showMessageDialog(this,"you clicked
on consit");

23
 new consit1();
}
else if(ae.getSource()==MenuItem22)
{
JOptionPane.showMessageDialog(this,"you clicked
on allots");
new allot1();
}

else if(ae.getSource()==MenuItem31)
{
JOptionPane.showMessageDialog(this,"you clicked
on report");
new report1();
}

else if(ae.getSource()==MenuItem41)
{
frame.dispose();
}

}
}

24
LOGIN FORM

MAIN MENU FORM

25
LAB FORM

COMPONENTS FORM

26
USER

CONSIT FORM

27
ALLOT FORM

5.3.2 OUTPUT SCREENS

FINAL REPORT

28
6. TESTING & VALIDATION

6.1 INTRODUCTION

The test cases are generated by testing our software, after its designing process in the
development phase. The following are the types of testing:
Inspecting components:
Inspections find faults in a component by reviewing its source code
in a formal meeting.
Fagan’s inspection method includes 5 steps:
i. Overview
ii. Preparation
iii. Inspection meeting
iv. Rework
v. Follow-up

6.2 DESIGN OF TEST CASES & SCENARIOS

Unit testing
Unit testing focuses verification effort on the smallest unit of software design
(i.e.) the module. Unit testing exercise specific paths in a module’s control
structure to ensure complete coverage and maximum error detection. These test
focuses on each module individually, ensure that it functions properly as a unit.
Hence, the name is unit testing. Unit testing techniques:
Equivalence testing
It is a black box testing technique that minimizes the number of test cases. The
possible inputs are partitioned into equivalence classes, and test case is selected for each
class.
Boundary testing
It is a special case of equivalence testing and focuses on the conditions at the boundary of
the equivalence classes.

29
Path testing
It is a white box testing technique that identifies faults in the implementation of the
component.
State-based testing
It focuses on object-oriented systems. It compares the resulting state of the system with
the expected state.
Integration testing
It detects faults that have not been detected during unit testing, by focusing on small
group of components. Two or more components are integrated and tested, and once tests
do not reveal any new faults, additional components are added.
The following are the types of Integration Testing:
 Big bang testing:
It assumes that all the components are first tested individually and then
tested together as a single system. Here no additional test stubs or drivers
are needed.
 Top-down testing:
This method is an incremental approach to the construction of program
structure. Modules are integrated by moving downward through the
control hierarchy, beginning with the main program module. Test stubs
are used to simulate the components of lower layers. No test drivers are
needed.
 Bottom-up testing:
This method begins the construction and testing with the modules at the
lowest level in the program structure. Since the modules are integrated
from the bottom up, processing required for modules subordinate to a
given level is always available and the need for stubs is eliminated.
 Sandwich testing:
It combines the top-down and bottom-up strategies to make use of the best
of both strategies.

30
 System testing
System testing is series of different tests whose primary purpose is to fully
exercise the computer based system. Although each test has a different purpose,
all the work should verify that all system element have been properly integrated
and perform allocated functions.

TEST CASE FOR LOGINFORM

S. no Test condition Expected result

1. Enter invalid user id and invalid Should display invalid password
password warning message invalid entry

4. If either fields are blank and press ok Message box “User id should not
be blank.”
5. Valid user id & password Should display User
Authentication Successful and
Navigate to next window

7. FUTURE SCOPE
 One of the major future scope is making our system online. Connecting labs to
a common data centre will provide globalization to the labs, and then the user
will be able to search components all over the city and nearby areas.
 Reviews, rating, comparing of coponents and labs can also be incorporate.
 This would help the user to use through popular components and make his
selection based on the components rating.

31
 8. CONCLUSION
After we have completed the project we are sure the problems in the existing
system would overcome. The “COMPUTER LAB MAINTANCE” process made
computerized to reduce human errors and to increase the efficiency. The main focus of
this project is to lessen human efforts. The maintenance of the records is made efficient,
as all the records are stored in the ACCESS database, through which data can be retrieved
easily. The navigation control is provided in all the forms to navigate through the large
amount of records. If the numbers of records are very large then user has to just type in
the search string and user gets the results immediately. The editing is also made simpler.
The user has to just type in the required field and press the update button to update the
desired field.

The components and user are given a particular unique id no. So that they can
be accessed correctly and without errors. Our main aim of the project is to get the
correct information about a particular user and components available in the lab.

The problems, which existed in the earlier system, have been removed to a large
extent. And it is expected that this project will go a long way in satisfying user’s
requirements. The computerization of the computer lab will not only improves the
efficiency but will also reduce human stress thereby indirectly improving human
recourses.

32
 9. REFERENCES

1. Java network programming By Elliott Rusty Harold.

2. TCP/IP sockets in Java: practical guide for programmers
By Kenneth L. Calvert, Michael J. Donahue
3. Peter Butler, Centre for Labor Market Studies, University of Leicester, 7-9 Salisbury
Road, Leicester LE1 7QR, email: [email protected]
4. Khairunnisa Binate Aziz an, Faculty of Information and Communication Technology,
Kolej University Teknikal, Kebangsaan, Malaysia
5. Schildt, Java (The Complete Reference), Tat Mac Graw Hill, www.HerbAchildt.com,
ISBN No: 978-0-07-063677-4
6. H.M. Deitel, P.J.Dietel, Java (How to Program), Pearson Education, ISBN No: 81-317-
0954-x
7. Boris Biezer, Software Testing Techniques, Dreamtech Press, ISBN.No: 81-7722-260-0
8. Elmasri, Navathe, Fundamentals of Database Systems, Pearson Education, ISBN No:
978-81-7758-476-9
9. Grady Booch, Object Oriented Analysis And Design, Pearson Education, ISBN No: 81-
389-0878-x

33