A

PROJECT REPORT

ON

LIBRARY MANAGEMENT SYSTEM

Project Guide:- Submitted By:-

Mr. KAMLESH PUROHIT UMESH UPADHYAY

SENIOR LECTURER MCA V SEM.
DEPARTMENT OF MCA
 SUBMITTED BY:-
UMESH UPADHYAY
DEEPAK BHATT
MCA VTH SEM

CERTIFICATE
This is to certify that Umesh Upadhyay completed the project titled
“LIBRARY MANAGEMENT SYSTEM” under my guidance and
supervision.

He is submitting this project in the partial fulfillment of requirements

for the award of Master of Computer Application, Graphic Era
University.

This work is original and has not been published or submitted

elsewhere for any purpose what so ever. All sources of information
have been duly mentioned and duly acknowledged.

Project Guide:

Mr. Kamlesh Purohit

Senior lecturer (MCA Dept.)
Graphic Era University
Dehradun

ACKNOWLEDGEMENT
The opportunity to undertake this project was a very fulfilling
experience.

Completing a task is never one-man effort. It is often the result of

invaluable contribution of a number of individuals in a direct or
indirect manner that results in achieving success.

The completion of my project has been possible with the kind

cooperation and assistance of some persons whom I would like to
thank sincerely.

The report here is in fact a collective effort of few individuals. I would

like to thank my guide Mr. KAMLESH PUROHIT, for his guidance,
advice and generous support.

I am further thankful to my friends and colleagues who have inspired

me to complete the project undertook by me.

UMESH UPADHYAY
MCA V SEM.
 PREFACE

Software is a mechanism for automating business, industry and government and

medium for transferring new technology, a method of capturing valuable
expertise for use by others, a means of differentiating one company’s product
from its competitors and a window into corporation’s collective knowledge.

This software is meant for increasing usability, such that it is preferable for the
every class people but also for low class people. This software is quite user
friendly and self explanatory and requires no previous knowledge except an idea
of LIBRARY MANAGEMENT SYSTEM on site. The algorithm used for this
purpose is trusted over years and sufficiently secure and efficient.

We have implemented this through front end JAVA and back end MICOSOFT
ACCESS.

Some of the features of this software are its handiness and quick response.
 INDEX
1. Title page
1.1 Pictures
2. Requirement analysis and physical study
2.1Contents of synopsis
2.2 Synopsis
3. Software requirement specification
3.1 Contents of SRS
3.2 Data flow diagrams
4. DESIGNING
4.1 Contents of designing
4.2 E-R diagrams
4.3 Structured diagrams
5. FORMS
5.1 Snap shorts of forms
5.2 Tables
5.3 Reports
6. CODING
6.1 Front in coding
6.2 back in coding
7. TESTING
7.1 Introduction
7.2 Types of testing
8. Implementation

9. Maintenance

10. Limitations

11. Future scope of the project

12. Bibliography
ABSTRACT
 INTRODUCTION OF THE PROJECT

Today is the era of information technology. We are very much

dependent on information which basically means data in useful form.So,
information is essential for the fast solutions of our problems.

In information technology we cannot think without computers. Current

computers have the capacity to accumulate, manipulate, store and summaries
many types of data. The work that is normally done by a computer is called data
processing. The prime task of data processing system is collection and operation
of data. A data processing system needs several input data files to process to
produce meaningful results.

This project is on LIBRARY MANAGEMENT SYSTEM. It has been

developed to replace cumbersome manual system of personnel information. It has
also been developed to increase the efficiency in handling data and to minimize
the possible errors. We know that the maintenance of library of the organization
in registers etc. is very complicated whereas with the help of the system, it will
be easy to maintain the records and hence reduce the paper work.

This project also reflects on the response time which means the time
lag between the time the request was made and the time output was received, is
very less.
 Data security can also be ensured with the help of locks and
passwords which is not possible in manual system. so, with the help of this
system we can avoid the important information from falling into the hands of
unauthorized users.
Thus the administrator is the master authority to all the data
manipulation and hence this system is user friendly too.
 ANALYSIS OF PROJECT

FEASIBILITY STUDY:

First of all, before designing the system we try to find out that whether we can
develop the required software or not. The feasibility study involves analysis of
the problem and collection of data which would be the input to the system, the
processing required to be carried out on this data, the output required to be
produced by the system, as well as the study of various constraints on the
behavior of the system.

In this context we can say that the software feasibility has four solid
dimensions:-

 TECHNOLOGY:-
Is the development of software product technically
feasible? Is it within the state of art? Can defects be reduced to a level
matching the applications need?

 FINANCE:-
Is it financially feasible? Can development be
completed at a cost the software organization, its clients or the market can
afford?

 TIME:-
Will the project be completed in time to beat the
market competition?

 RESOURCES:-
Does the organization have the resources needed for
the project to be implemented successfully?
 Hardware and Software requirement

Installation Requirements:-

(1). Software Requirements:-

1 MSDN library
2 Crystal Report
3 JAVA
4 MS-ACCESS
5 Microsoft Windows Me or M.S. XP or any equivalent
processor
6 Case Studio 2.22

(2). Hardware Requirements:-

1 Intel Processor (P II) or Higher or any equivalent
Processor.
2 Minimum 32MB RAM.
3 A Floppy Drive.
4 A CD-Drive.
 Problem Planning & Scheduling

Project “LIBRARY MANAGEMANT SYSTEM” developed according to the

following work plan. A work plan is central to the software approach for solving
crises.

S.No Phases Duration Start Finish

1. Requirement Analysis 1 week. 12-03-08 19-03-08

2. Design 2 week. 23-03-08 06-03-08

3. Coding 3 weeks. 22-04-08 12-05-08

4. Testing 1 week. 13-05-08 20-05-08

5. Maintenance ……..
 PROBLEM DEFINITION AND ITS SPECIFICATION:-

This project is on LIBRARY MANAGEMENT SYSTEM. It has been developed

to replace cumbersome manual system of personnel information. It has also been
developed to increase the efficiency in handling data and to minimize the
possible errors. We know that the maintenance of library of the organization in
registers etc. is very complicated whereas with the help of the system, it will be
easy to maintain the records and hence reduce the paper work.

This project also reflects on the response time which means the time
lag between the time the request was made and the time output was received, is
very less.

CORRECTNESS-

A good design should correctly implement all the functionalities of the system.

UNDERSTANDABILITY-

A good design should be easily understandable.

EFFICIENCY-

It should be efficient

MAINTAINABILITY-
It should be easily amenable to change.

The goal of the design phase is to transform the requirements specified in the
SRS

Document into a structure that is suitable for implementation in some

programming language. I technical terms, during the design phase the “software
architecture” is derived from the SRS document.
 0 LEVEL DFD

LIBRARY READERS
READER SATISFACTION
 1 LEVEL DFD

LIBRARY READERS
READERS SATISFACTION

ISSUE RETURN ENQUIRY

 2LEVELDFD

REDAERS
READER SATISFACTION
LIBRARY

ISSUE ENQUIRY
CANCELLATION

BOOK LIBRARY CONFIRMED RETURN BOOK

STATUS ENTRY ISSUE AVAILABILITY
 LIST OF REPORTS GENERATED:-

1- Information Report –
Checks whether a user or a non user. If user, data is retrieved else data is added to
database.

2- Checking Report –
Checks the books details.

3- Conformation Report –

Organize book and it also verifies the book. If book is available then give the
conformation report to the reader.

4- Expectance Report –

The book is allotted to the user as per the required rules.

 LIMITATION OF THE PROJECT

USE OF ZIP CARDS:

As we have a very easy procedure for

withdrawing money from ATM i.e. AUTOMATIC TELLER
MACHINE with the help of zip cards. It would be equally
convenient if we have such zip cards for library purpose.
However it is a difficult task to introduce such a system
presently.
But with the advancement in technology it may be
possible to provide such a facility to the readers in the years to
come. Some of the other limitations are:

• Not fulfill all the requirements.

The project is just a trial to fulfill some of the requirements of library

managements. It is an effort towards reducing the manual work done by
the employee to handle the storage and the excess of the library
requirements.

• It does although it is not a complete project but I tried to solve some of the
 Problems in the project.

• RELIABILITY-if the software is not completed on time due to lack of

management skills, or if any new person is working on the project etc. then
cost also increases, and acts as an hindrance in software development.

• Error can occur in the software implementation.

 FUTURE OF THE PROJECT

 The system is simple to operate.

 The system will make systematic recording of all information regarding
books and issue entries.
 Searching of some information about any particular book issue and fine
related will be very fast as compared to that maintained in registers where the
searching is sequential and takes a much long time.
 Data duplication is reduced as compared to manual system where same
information may have been stored at several places thus leading to confusion.
 In the future further modules can be added to increase the
specification of a project.

 The software can be made online so that anybody could access the
software and check the availability of books.

Addition of new records, updating and modification of existing records

and deletion of old records is less time

REQUIRMENT ANALYSIS
 AND
SPECIFICATIONS

REQUIREMENT ANALYSIS
 Requirement Analysis involves obtaining a clear and thorough understanding of
the product to be developed, with a view to removing all ambiguities and
inconsistencies from the initial customer perception of the problem.
Without a clear understanding of the problem, it is almost impossible to develop
a satisfactory solution. Therefore many basic questions pertaining to the project
such as the following should be understood clearly by the analyst:

1. What is the problem?

2. Why is it important to solve the problem?
3. What are the possible solutions to the problem?
4. What exactly are the data inputs to the system and what exactly are the
data outputs by the system?
5. What are likely complexities that might arise while solving the
problem?

During requirement analysis, the analysts usually carry out the following two main
activities:

• Requirements gathering:
This involves interviewing the end-users and customers to collect all
possible information regarding the system. However in the absence of a
working system, much more imagination and creativity on the part of the
system analyst is required.

• Analysis of gathered requirements:

The main purpose of analysis of the collected information is to clearly
understand the exact requirements of the customer and resolve anomalies,
 conflicts, and inconsistencies in the gathered requirements. Such anomalies
and inconsistencies in the gathered requirements are resolved by further
discussions with the end-users and customers.

After the analyst has collected all the required information regarding the system
to be developed, and has removed all inconsistencies and anomalies from the
specification, he starts to systematically organize the requirements into a SRS
document.

C0NTENTS
 OF
SRS

1. INTRODUCTION

1.1. OBJECTIVE
This document aims at defining the overall software requirements for
‘COMPUTERIZING THE FIRM’. Efforts have been made to define the
requirements exhaustively and accurately. The final product will be having only
features and functionalities mentioned in this document and assumptions for any
additional functionality and feature should not be made by any of the parties
involved in developing/testing/implementing/using this product. In this case it is
required to have some additional features, a formal change will need to be raised
and subsequently a new release of this document and/or product will be
produced...
Definitions, Acronyms, and Abbreviations

Following abbreviations have been used throughout this document:

• Emp : Employee.
• DBA: Database Administrator

Overview

The rest of this SRS document describes the various system requirements,
interfaces, features and functionalities in detail.

1.2. SCOPE
The software product ‘ COMPUTERIZATION OF A FIRM’ will be an MIS and
Reporting application that will be used for keeping information regarding
employee, their salary and also the information regarding raw goods , their
testing etc. This application will manage the information about the testing of raw
material, supply of finish goods in better way. This software will manage a huge
data in a better and less time consumed way. This application help the user to
access the information in a better way by having some valid user id and other
security mechanisms.
This application will also generate printable reports regarding lists the different
employee’s of a company regarding any aspect .This system also generated
printable salary sheet for the individual employee at his request.
This application will greatly simplify and speed up the result preparation and

1.3. OVERALL DESCRIPTION

The strategic of this software is:

• Handle processing of new employee.
• Handle processing of query processing and Report generation.
• Have improved data capture technology, methods and the decision support.

The primary users of the new system would be the management and the staff of
the Jindal vegetable product ltd. This system will store with new employee detail,
row material test records, and processing and report generation and keep the
record of marketing and supply of final product.
1.4. INTERFACES

The application will be a window-based, self-contained and independent software

product.

1.4.1. User Interfaces

The application will be user-friendly and menu based interface. Following

screens will be provided:

• A login screen for entering the username, password, and identify proof
(Administrator, Data Entry) will be provided. Access to different screens
will be based upon the role of the user.
• There will be a screen for capturing and displaying information regarding
lab analysis.
• There will be a screen for capturing and displaying information regarding
the salary of an employee.
• There will be a screen for capturing and displaying information regarding
the payment slip of an employee.
• There will be a screen for capturing and displaying regarding the market
supply of final goods.

1.4.2. Hardware interfaces

 1. Screen resolution of at least 800*600-required for proper and complete
viewing of screens. Higher resolution would not be a problem.
2. Support for printer (dot-matrix/DeskJet/inkjet etc.-any will do)-that is,
appropriate drivers are installed and printer connected printer will be
required for printing of reports.
3. Standalone system or network based-not a concern, as it will be possible to
run the application on any of these.

1.4.3.Operating System Interfaces

Any windows-based operating system (windows 95/98/2000/xp/NT).

1. SQL as the DBMS—for database. Future release of the application will
aim at upgrading to oracle 9i as the DBMS.
2. Crystal Reports 9 –for generating and viewing reports.
3. Visual Basic 6.0 –for coding/developing the software.

Software mentioned in points 3 and 4 above, will be required only for

development of the application. The final application will be packaged as an
independent setup program that will be delivered to the client.

(e).CONSTRAINTS

(i). Memory constraints

At least 64MB RAM and 2 GB space on hard disk will be required for running
the application.

(ii) Time:-
The initial version of the system must be operational in two months
The system must be developed in accordance with the fast development
methodology

FUNCTIONAL REQUIREMENTS
(i).FUNCTONAL PARTITIONS

There are two type of user for this software first is the administrator that has the
authority to make changes in the database .second is the guest user that only
access the information about the company, it also helps and support the user by
providing various check during the data entry.

(ii). FUNCTONAL DESCRIPTION

OBJECTS NAMING CONVENTION

FORM APPLICATION DESIGN FORM

MODULES MODULE OF APPLICATION

INPUT BOX STORE INPUT DATA IN VARIABLE SUPPLIED

BY KEYBOARD.
MSGBOX MESSAGE BOX

TEXTBOX INPUT TEXT DATA INSIDE IT BY USER

COMMAND BUTTON CLICK IT AND IT ACTIVATE SOMR DEFINE

PROCESSING

OPTOIN BUTTON DEFINE OPTION FOR USER

BUILT IN FUNCTION LIKE-STR (), VAL (), MID (), ETC.

MDI MULTIPLE DOCUMENT INTERFACE

LABEL DISPLAY CAPTION DATA

NON FUNCTIONAL REQUIREMENT

(i). Site Adaptation Requirements

The terminals at client site will have to support the hardware and software
specification in the above sections.

(ii). Assumptions and Dependencies

The numbers of options taken up by a member each time does not change.
The subject types do not change.

BEHAVIOUR DESCRIPTION

(a). SYSTEM STATES

Following were the modules that are to be use in this software.

(i). Employee module: - this module is use to store employee details,

information about salary as well as maintain the salary register

(ii).Testing module: - this module is to maintain lab analysis report and

Plant analysis report.

(iii).Production Module: -
This module is use to maintain raw material details, production & expenditure
details as well as supply details of finished goods.

Working:-
Input is given to validation process and according to this input process will
decide whether it will fed to employee module to store in database as employee
information or just fed it into testing module as input for further processing. In
testing module records are maintain for tested goods and after all processing
finished goods details are maintain in supply module.

(b). EVENT & ACTION

As there are many checks which to be included such as if there is any field
containing only no. then in should only accept no. ,&also no field should be
empty if it is necessary field, if it is then the system will generate error
message .like this various action are define for which system had to take action.

VALIDATION CRETERIA

A USER ACCOUNT

1. The system requests that the Administrator enters the user information.
This includes:

• User Name
• User Id-should be unique for each user account.
 • Password
• Role

2. Once the user selects the user account it is not allowed to enter in main form.

UPDATE A USER ACCOUNT

1. The system requests that the Administrator enters the User ID.
2. The Administrator enters the User ID. The system retrieves and displays the
user account information.
3. The Administrator makes the desired changes to the user account information.
This includes any of the information specified in the Add a User Account sub-
flow.
4. Once the administrator updates the necessary information, the system updates
the user account record with the updated information.

DESIGN
DOCUMENT
SO FTWARE D E
Software design deals w i
described in the SR S doc
program ming language. F
conventional program m ina
during the designed phas
• Different modules

• Control relationshi
SOFTWARE DESIGN APPROACHES:-

There are fundamentally two different approaches to software design-function

oriented design and object oriented design. However these two approaches
are radically different.

 Function –Oriented Design :- The following are the salient

features of the typical function-oriented design approaches:

1. A system is viewed as something that performs a set of functions.

Starting at this high-level view of the system, each function is

successfully refined into more detailed functions. This functions
may consist of the following sub functions:
• Assign –membership –number
• Create –member-record
• Print-bill

2. The system state is centralized and shared among different function,

e.g. data such as member-records is available for references and

updating to several function such as-
• Create-new-member
• Delete-member
• Update-member-record
Several function-oriented design approaches have been developed.
The function oriented design is further broadly divided into two categories as
follows:-
STRUCTURED DESIGN:-

The aim of the structured design is to transform the results of the structured
analysis into a structure chart. A structure chart represents the software
architecture, i.e.; the various modules making up the system, the module
dependency and the parameters that are passed among the different
modules. Hence the structure chart representation can be easily
implemented using some programming language. Since the main focus in a
structure chart representation is on module structure of software and the
interaction among the different modules, the procedural aspects are not
represented.

DETAILED DESIGN:-

During detailed design the pseudo code description of the processing

and the different data structures are designed for different modules of
the structure chart. These are usually described in the form of module
specifications. The MSPEC for non-leaf modules describe the
different conditions under which the responsibilities are delegated to
the lower-level module. To develop the MSPEC of a module, it is
usually necessary to refer to the DFD model and the SRS document
to determine the functionally of the module.
Object-Oriented Design :

In the object-oriented design approach, the system is viewed as a collection of

objects. The system state is decentralized among the objects and each object
manages its own state information.

Objects have their own internal data which defines their state. Similar objects
constitute a class. In other words, each object is a member of some class.
Classes may inherit features from a super class. Conceptually, objects
communicate by message passing.
 DESIGNING
Enunciating the characterization of a good software design which remains
accurate for a large variety of problems is not easy. The definition of “a good
software design” can vary depending on the application for which it is being
designed. Characteristics that every good software designs are listed below:

1. CORRECTNESS-
A good design should correctly implement all the
functionalities of the system.

2. UNDERSTANDABILITY-
A good design should be easily understandable.

3. EFFICIENCY-
It should be efficient

4. MAINTAINABILITY-
It should be easily amenable to change.

The goal of the design phase is to transform the requirements specified in the SRS
Document into a structure that is suitable for implementation in some programming
language. I technical terms, during the design phase the “software architecture” is
derived from the SRS document.
 CASE STUDIO

Case studio 2 is a professional database designing too. Case studio 2 is designed

to visually create and maintain ERD (Entity Relationship Diagram) for numerous
databases. it is an ideal choice for companies and developers who want to work
with their own databases in the most comfortable way.

CASE studio 2 is a very intuitive database designing and management tool

using well arranged ER-diagrams, through which complex SQL-scripts for
physical creation of tables for various databases (Oracle , DB2, UDB, Ms-
SQL,Interbase,MySQL,PostgreSQL,Sybase,Informix and more) can be
generated. Data flows between tables can also be easily described by creating
appropriate Data flow diagrams. When creating ERD the program considers
individual database options such as referential integrity, constraints, domains,
triggers etc.
 FEATURES OF CASE STUDIO

There are quite lot features of case studio which make it more useful for
developing any database software.
These are:-
1. Visual creation of Entity Relationship Diagrams (ERD's)
2. Reverse Engineering - enables you to load a structure of supported database
into the CASE studio 2
3. Graphic editing of the Data Flow Diagrams (DFD's)
4. Version manager allows you to compare your models.
5. Generation scripts for SQL databases, including triggers.
6. Gallery for saving and storing most frequently used parts of models
7. Generation of very detailed RTF and HTML reports.
8. Definition of user defined variables and templates used to generate scripts.
9. To Do List feature- available for: Model, Entity, Relationship, Dictionary,
Triggers and Users.
10. COM interface with type-library casestud.tlb.
11. Users, User Groups and User Permission support.
12. Referential integrity (Declarative or via Triggers)
13. Data dictionaries.
14. Support of JScript and VBScript.

DATA FLOW DIAGRAMS

The DFD (also known as bubble chart) is a simple graphical formalism that can
be used to represent a system in terms of the input data generated by the system.
The main reason why the DFD technique is so popular is probably because of the
fact that DFD is a very simple formalism-it is simple to understand and use. A
DFD model uses a very limited number of primitive symbols as shown below to
represent the functions performed by a system and the data flow among these
functions.

External Entity Process Data Flow

Data Store Output

Starting with a set of high level functions that a system performs, a DFD model
hierarchically represents various sub functions. In fact any hierarchical model is
simple to understand. Human mind is such that it can easily understand any
hierarchical model of a system-because in a hierarchical model, starting with a
very simple and abstract model of a system, different details of the system can be
slowly introduced through different hierarchies.

ENTITY-RELATIONSHIP MODEL:-
 The entity-relationship (E-R) data model was developed to facilitate
database design by allowing specification of an enterprise schema that represent
the overall logical structure of a database. The E-R data model is one of the
several semantic data model; the semantic aspect of the model lies in its
representation of the meanings and interactions of real-world enterprises onto a
conceptual from the E-R model. The E-R model employs three basic notations:
entity sets, relationship sets, and attributes.

The entity-relationship (E-R) data model is based on a perception of a real

world that consists of a collection of basic object, called entities, and of
relationship among these object. An entity is “thing” or “object” in the real world
that is distinguishable from other object.

A relationship is an association among several entities .The set of entities

of the same type and he set of all relationship of the same type are termed an
entity set and relationship set , respectively.

The notions of an entity set and a relationship set are not precise, and it is
possible to define a set of entities and the relationships among them in a number
of different ways.
NOTATION OF E-R DIAGRAM:-

The overall logical structure of a database can be expressed graphically by an E-

R diagram, which is built up from the following components:

• Rectangle, which is represent entity sets

• Ellipse, which represent attributes

• Diamonds, which represent the set of relationship among a member

from each of several entity sets

• Lines, which link attributes to entity sets and entity sets to relationships
 ER Diagram of library

stud_nam
stud_id Ag
e
e
Prev record

Issue Book
no.
Dat_iss
ue
Library past_ fine
Dat_ret

Ag
stu_id stu_name
e
Book_name

Return Book_n
Return o
Dat_issu
e
No fine
accept
FORMS
LOGIN FORM
TABLES
 CODING:-

The input to the coding phase is a design document .During the coding phase,
different modules identified in the design document are coded according to the
respected module specification. Recall that at the end of the design phase, we not
only have the module structure (e.g. structure chart) of the system but also the
module speciation where the data structures and algorithms for each module are
specified. Therefore, we can say that the objective of the coding phase is to
transform the design of the system, as given by its module specification, into a
high level language code and to unit test this code. Organization engineers have
to follow these standards rigorously due to the following reason:
• Coding standards give the uniform appearance to the codes written by
different engineers.

• It provides sound understanding of the code.

• It encourages good programming practices.

import javax.swing.*;

import java.awt.*;

import java.awt.event.*;

import javax.swing.table.*;

import java.sql.*;

import java.util.*;

public class MyLibrarian

static JFrame fr2,fr3,fr4,fr5,fr6,fr7,fr8,fr9,fr10,fr11,fr12,fr13,fr14;

static JPanel p2,p3,p4,p5,p6,p7,p8,p9,p10,p11,p12,p13,p14;

JButton LOGIN=new JButton("LOGIN");

JButton
ADD,AddNewBook,DELETE,DelOldBook,ADDNEWUSER,AddThisUse
r,DELEXISTUSER,DelThisUser,CHANGEPW;

JButton
MARKEOI,CHANGEMYPW,QUERY,RUNQUERY,REPORT,ISSUE_B
OOK,ADD_BORROWER,AddThisBorrower;
JButton
CLOSE_BORROWER,CloseThisBorrower,VIEW_REC,MODIFY_REC,s
howItButton;

JLabel jLabel, jLabel1, jLabel2,l1,l2,l3,l4,l5,l6,l7,l8,l9,l10;

JTextField
section,bookname,author,price,availcode,currentborrower,serno,boname,bo
address;

JTextField
bophoneno,borrowerNewMagazine,borrowerPhoneNo,borrowerLastMagaz
ine;

JPasswordField loginpass,oldpw,newpw,newpwc;

JTextField
username,password,Designation,loginpassback,usrname,fboserial,loginna
me;

JTextField
borrowerSerialno,borrowerName,borrowerAddress,borrowerLastBook,borr
owerStatus;

JTextField borrowerNewBook;

//JTextField loginname = new JTextField(20);

//JTextField loginpass = new JTextField(20);

GridBagLayout gridbag = new GridBagLayout();

GridBagConstraints c = new GridBagConstraints();

String t1;

String url="jdbc:odbc:BANK";

String driver="sun.jdbc.odbc.JdbcOdbcDriver";

String
sql,sq,sqUsr,sbookd,sdUsr,squpdate,dialogmessage,serialno,squpdate_boo
k,squpdate_mag;

int dialogtype = JOptionPane.PLAIN_MESSAGE;

String dialogs = "SUCCESS";

String dialogf = "FAILURE";

String dialogd = "DELETION OK ?";

String dialogw = "WARNING !!!";

DefaultTableModel defaulttablemodel = new DefaultTableModel();

boolean DelFlag,AddFlag,DelUsrFlag,AddUsrFlag;

Font dataFont = new Font("times new roman",Font.PLAIN,15);

String loginnameback;

//GregorianCalendar gCal;

//Following is required for running a query on database.

JCheckBox jCheckboxq1, jCheckboxq2, jCheckboxq3, jCheckboxq4,

CheckBoxListener myListener = new CheckBoxListener();

JRadioButton jRadiobuttonq1, jRadiobuttonq2;

ActionListener rlistener = new RadioListener();

ButtonGroup bgq = new ButtonGroup();

GridBagConstraints c5 = new GridBagConstraints();

JComboBox jComboboxq1, jComboboxq2;

ComboBoxListener cbListener = new ComboBoxListener();

JTextField givencondition;

JTextArea resultArea;

JLabel jLabelq1, jLabelq2;

int
SerialNoSel=0,BookNameSel=0,AuthorSel=0,PriceSel=0,CurrentBorrowe
rSel=0;

String Combo1sel="SerialNo", Combo2sel="=";

String sr;

String condsel="No Condition";

String qry = "";

//Following is required for Book Reports

Object[] data = new Object[5];

//DefaultTableModel defaulttablemodel = new DefaultTableModel();

JTable jtable = new JTable(defaulttablemodel);

String tempname = "";

int tempcnt;

//Following is required to generate proper message

String msgsel1="Are You Sure?";

String msgesel2;

int n;

JFrame frame;

public static void main(String[] args) {

MyLibrarian c1=new MyLibrarian();

public MyLibrarian()

//setupMenuBar();

login();

void login()

fr2=new JFrame("Login Panel MyLibrarian v1.0");

fr2.setVisible(true);
 fr2.setSize(600,300);

fr2.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

p2=new JPanel();

p2.setLayout(gridbag);

p2.setBorder(BorderFactory.createTitledBorder(BorderFactory.creat
eEtchedBorder(),"Login Panel"));

jLabel1 = new JLabel("Enter Username : ");

jLabel1.setFont(dataFont);

//c.weighty = 0.0; //Vertical Space

c.ipady = 1; //Height of
Component

c.ipadx = 1; //Width of Component

c.anchor = GridBagConstraints.WEST;

c.gridwidth =1; //1 columns wide

c.gridx = 0; //aligned with button 0 --

Very Important

c.gridy = 0; //0th Row -- Very Important

 // Add all these features to this Label
"jLabel1"

gridbag.setConstraints(jLabel1, c);

p2.add(jLabel1);

loginname = new JTextField(10);

// loginname.setEchoChar('*');

c.ipady = 1;

c.ipadx = 1;

//c.weighty = 0.0;

c.anchor = GridBagConstraints.WEST;

c.gridwidth = 2;

c.gridx = 1;

c.gridy = 0;

gridbag.setConstraints(loginname, c);

p2.add(loginname);
 jLabel2 = new JLabel("Enter Password : ");

jLabel2.setFont(dataFont);

c.ipady = 1;

c.ipadx = 1;

//c.weighty = 0.0;

//c.anchor = GridBagConstraints.WEST;

//c.gridwidth = 1;

c.gridx = 0;

c.gridy = 1;

gridbag.setConstraints(jLabel2, c);

p2.add(jLabel2);

loginpass = new JPasswordField(10);

loginpassback = loginpass;

loginpass.setEchoChar('*');

c.ipady = 1;
 c.ipadx = 1;

//c.weighty = 0.0;

//c.anchor = GridBagConstraints.WEST;

//c.gridwidth = 2;

c.gridx = 1;

c.gridy = 1;

gridbag.setConstraints(loginpass, c);

p2.add(loginpass);

LOGIN = new JButton("LOGIN");

c.ipady = 1;

c.ipadx = 1;

c.weighty = 0.0;

c.anchor = GridBagConstraints.CENTER;

c.gridwidth = 0;

c.gridx =0;

c.gridy =4;
 gridbag.setConstraints(LOGIN, c);

p2.add(LOGIN);

else if(s=="RUN QUERY")

QueryBuilder();

else if(s=="RUN THIS QUERY")

handleQuery();

else if(s=="REPORTS")

BookReports();

else if(s=="ADD NEW BORROWER")

{
 addnewborrower();

else if(s=="ADD THIS BORROWER")

BORROWER_ADD();

else if (s=="ISSUE BOOK")

sql = "SELECT * FROM login WHERE

username='"+var1+"' AND password='"+var2+"'";

Class.forName(driver);

Connection connection=DriverManager.getConnection(url);

Statement statement = connection.createStatement();

boolean hasResults = statement.execute(sql);

if(hasResults)

ResultSet result =
statement.getResultSet();
 if(result!=null)

displayResults(result);

connection.close();

catch(Exception ex)

void displayResults(ResultSet r) throws SQLException

ResultSetMetaData rmeta = r.getMetaData();

//Get Metadata from resultset

int foundrec = 0;

int numColumns=rmeta.getColumnCount();

while(r.next())
 {

String param3 =
r.getString(3).trim();

// 3rd field in the table 'login' ,

database 'bank.mdb'

if (param3.equals("Accounts"))

// for login 'a' , password 'a' ,

if his deparment is "Accounts"

// u found record , so set

foundrecord = 1

foundrec = 1;

showAccountloginsuccess();

else if(param3.equals("Main"))

// for login 'm' , password 'm' ,

if his deparment is "Main"

// u found record , so set

foundrecord = 1
 foundrec = 1;

showMainloginsuccess();

if(foundrec==0)

//if foundrecord is zero , invalid login

dialogmessage = "Please Re-Login";

dialogtype =
JOptionPane.WARNING_MESSAGE;

//show message

JOptionPane.showMessageDialog((Component) null,
dialogmessage, dialogw, dialogtype);

//make login and password textboxes

empty

loginname.setText("");

loginpass.setText("");

}
 void showAccountloginsuccess()

//fr2.setVisible(false);

dialogmessage = "Login Succssful !!!";

dialogtype =
JOptionPane.INFORMATION_MESSAGE;

//show message

JOptionPane.showMessageDialog((Component) null,
dialogmessage, dialogs, dialogtype);

loginname.setText("");

loginpass.setText("");

showAccountprograms();

void showMainloginsuccess()

{
 dialogmessage = "Login Succssful !!!";

dialogtype =
JOptionPane.INFORMATION_MESSAGE;

//show message

JOptionPane.showMessageDialog((Component) null,
dialogmessage, dialogs, dialogtype);

loginname.setText("");

loginpass.setText("");

showMainprograms();

void showMainprograms()

fr6=new JFrame("Task Performer My Librarian v1.0 ");

fr6.setVisible(true);

fr6.setSize(600,300);

p6=new JPanel();

p6.setLayout(gridbag);
 Calendar cal = Calendar.getInstance(TimeZone.getDefault());

String DATE_FORMAT="dd-MM-yyyy";

java.text.SimpleDateFormat sdf = new

java.text.SimpleDateFormat(DATE_FORMAT);

sdf.setTimeZone(TimeZone.getDefault());

//System.out.println("Now : "+sdf.format(cal.getTime()));

String t1 = sdf.format(cal.getTime());

p6.setBorder(BorderFactory.createTitledBorder(BorderFactory.createEtche
dBorder(),"Main "+loginnameback+" Logged in"));

l2=new JLabel(t1);

c.ipady=2;

c.ipadx=2;

c.anchor=GridBagConstraints.WEST;

c.gridx=3;

c.gridy=0;

gridbag.setConstraints(l2,c);
 p6.add(l2,c);

ADD = new JButton("ADD NEW BOOK");

c.ipady = 2;

TE.addActionListener(new ButtonHandler());

ADDNEWUSER = new JButton("ADD NEW USER");

c.ipady = 2;

c.ipadx = 2;

c.weighty = 0.0;

c.anchor = GridBagConstraints.WEST;

c.gridwidth = 1;

c.gridx = 0;

c.gridy = 2;

gridbag.setConstraints(ADDNEWUSER, c);

p6.add(ADDNEWUSER);
 ADDNEWUSER.addActionListener(new
ButtonHandler());

DELEXISTUSER = new JButton("DELETE EXISTING USER");

c.ipady = 2;

c.ipadx = 2;

c.weighty = 0.0;

c.anchor = GridBagConstraints.WEST;

c.gridwidth = 1;

c.gridx = 0;

c.gridy = 3;

gridbag.setConstraints(DELEXISTUSER, c);

p6.add(DELEXISTUSER);

DELEXISTUSER.addActionListener(new
ButtonHandler());

w JLabel("New Magazine : ");

 c.ipady=2;

c.ipadx=2;

c.anchor=GridBagConstraints.WEST;

c.gridx=2;

c.gridy=5;

gridbag.setConstraints(l10,c);

p14.add(l10,c);

borrowerNewMagazine = new JTextField("

");

c.ipady=2;

c.ipadx=2;

MODIFY_REC.addActionListener(new
ButtonHandler());

fr14.getContentPane().add(p14);

JFrame.setDefaultLookAndFeelDecorated(true);

}
void UpdateBorrowerRecord()

try

Class.forName(driver);

Connection
connection=DriverManager.getConnection(url);

Statement statement = connection.createStatement();

temp2 =
temp2.trim();

String temp5 =
borrowerStatus.getText();

temp5 = temp5.trim();

int foundclosedrec = 0;
 System.out.println(temp5);

if (temp5.equals("C"))

foundclosedrec = 1;

dialogmessage =
"Cannot Update.Closed Record";

dialogtype =
JOptionPane.INFORMATION_MESSAGE;

//show message

JOptionPane.showMessageDialog((Component) null,
dialogmessage, dialogf,dialogtype);

return;

//System.out.println(temp);

//System.out.println(temp1);

//System.out.println(temp2);
 if (foundclosedrec==0)

squpdate_book = "UPDATE
borrower_record SET bolastbook='"+temp1+"' WHERE boserial =
'"+temp+"'";

squpdate_mag = "UPDATE
borrower_record SET bolastmagazine='"+temp2+"' WHERE boserial =
'"+temp+"'";

Class.forName(driver);

Connection
connection=DriverManager.getConnection(url);

Statement statement =
connection.createStatement();

statement.executeUpdate(squpdate_book);

statement.executeUpdate(squpdate_mag);

connection.close();

dialogmessage = "Borrower
Record Updated";
 dialogtype =
JOptionPane.INFORMATION_MESSAGE;

//show message

JOptionPane.showMessageDialog((Component) null,
dialogmessage, dialogs,dialogtype);

borrowerNewBook.setText("");

borrowerNewMagazine.setText("");

java.text.SimpleDateFormat sdf = new

java.text.SimpleDateFormat(DATE_FORMAT);

sdf.setTimeZone(TimeZone.getDefault());

//System.out.println("Now : "+sdf.format(cal.getTime()));

String t1 = sdf.format(cal.getTime());

}
TESTING
 Overview
Software testing is the process used to help identify the correctness,
completeness, security and quality of developed computer software.
With that in mind testing can never completely establish the correctness of
arbitrary computer software in computability theory , a filed of computer
science ,an elegant mathematical proof concludes that it is impossible to solve the
halting problem, the question of weather an arbitrary computer program will
enter an infinite loop or halt and produce output. In other words , testing is
criticism or comparison that is comparing the actual value with expected one.

There are a wide variety of types of software tests that may be used for building
energy simulation software, each with a different objective or scope. The goal of
software testing is to cost effectively identify and communicate as many potential
problems with the s\w as possible and iterate with the development team until the
identified bugs are eliminated. Please note that creating a bug free s\w is not a n
obtainable goal, since there are too many possible inputs and too many possible
paths through the program. From the development teams prospective a successful
test is one that reveals problem, all other tests are unnecessary. From the users
perspective, a successful test is one that shows that the s\w results match some
type of standard with an adequate level of accuracy.
There are many approaches to software testing, but effective testing of complex
products is essentially a process of investigation, not merely a matter of creating
and following route procedure. One definition of testing is” the process of
questioning a product in order to evaluate it.” Although most of the intellectual
processes of testing are identical to that of review or inspecting, the word testing
is connoted to mean the dynamic analysis of the product – putting the product
through its paces. The quality of the application can, and normally does, vary
widely from system to system but some of the common quality attributes include
reliability, stability, portability, maintainability and usability.

LEVELS OF TESTING

1. UNIT TESTING:

The first level of testing is called unit testing. In this different modules are tested
against the specifications produced during design of the modules. Unit testing is
essentially for verification of the code produced during the code phase, and hence
the goal is to test the internal logic of the modules. The programmer of the
module typically does it. Others consider a module for integration and use only
after it has been unit tested satisfactorily. Due to its close association with
coding, the coding phase is frequently called “coding and unit testing”. As the
focus of this unit testing level is on testing code, structural testing is the best
suited for this level. In fact, as structural testing is not very suitable for large
programs, it is used mostly at the unit testing level.

2. INTEGRATION TESTING:

The next level of testing is often called as integration testing. In this, many
unit modules are combined into subsystems, which are then tested. The goal
here is to test whether modules can be integrated properly. Hence, the
emphasis is on testing interfaces between modules. The testing activity can be
 considered testing the design. The integration plan specifies the steps and
order in which modules are combined to realize the full system. After each
integration step, the partially integrated system is tested. An important factor
that guides the integration is the module dependency graph.

3. SYSTEM TESTING:

System tests are designed to validate a fully developed system to assure that it
meets its requirements. There are essentially three main kinds of system
testing:
• ALPHA TESTING: alpha refers to the system testing carried out by the test
team within the developing organization.
• BETA TESTING: beta testing the system testing performed by a select
group of friendly customers.
• ACCEPTANCE TESTING: acceptance testing is the system testing
performed by the costumer to determine whether to accept or reject the
delivery of the system

System testing is normally carried out in a planned manner according to the

system plan document. System plan identifies all testing related activities that
must be performed, specifies the schedule of testing, and allocates resources.
Immediately after requirement specification phase, a system test plan can be
prepared which documents the plan for system testing. System test plan can be
prepared on the basis of SRS document. The result of system and integration
testing are documented in the form of test reports.

TYPE OF TESTING

1. BLACK BOX TESTING:

This testing is also known as functional testing. The basis for deciding test cases
in functional testing is requirement or specifications of the system or modules.
For the entire system test cases are designed from the requirements specification
document from the system. For modules created during design, test cases for the
functional testing are decided from module specification produced during the
design.

The most obvious functional testing procedure is exhaustive testing, which as we

have stated, is impractical. One criterion for generating test cases is to generate
them randomly. However there are number of techniques that can be used to
select test cases that have been found to be very successful in detecting errors.
Some of them are:
1. EQUIVALENCE CLASS PARTITIONING:

In this we divide the domain of all the inputs into set of equivalence classes.
That is what we want to identify classes of test cases such that the success of one
test case in a class implies the success of others. It is often useful to consider
equivalence classes in the output. For an output equivalence class, the goal is to
generate test cases such that the output of that test case lies in the output
equivalence class.

2. BOUDARY VALUE ANALYSIS:

In boundary value analysis, we choose an input for a test case from an

equivalence class, such that the input lies at the edge of the equivalence class.
Boundary value rest cases are also called “extreme cases”.

2. CAUSE-EFFECT GRAPHING:

It is the technique that aids in selecting combinations of input conditions in a

systematic way. A cause is a distinct input condition, and an effect is in distinct
output condition. Each condition forms a node in the cause-effect graphing.
Beyond generating high-yield test cases, it also aids the understanding of the
functionality of the system, because the tester must identify the distinct causes
and effects.
 4. SPECIAL CASES:

It depends on the data structure and the function of the module. There are no
rules to determine special cases, and the tester has to use his intuition and
experience to identify such test cases. Consequently, determining special cases is
also called as “error guessing”.

2. WHITE BOX TESTING:

Each white box testing strategy is based on some heuristic. One testing is said
strong than other if I detect some more errors than first one does. When two
strategies detect errors different from other with respect to some errors, they are
called complementary.

1. STATEMENT COVERAGE: It aims to design test cases so that each is

executed once. The principal idea is that unless we execute a statement, we have
no way of determining the errors.

2. BRANCH COVERAGE: in this, test cases are designed to make each branch
condition assume true or false value in turn. It is also known as “edge testing”.

3. CONDITION COVERAGE: In this cases are designed to make each

component of a composite conditional expression assume both true and false
values. The number of test cases increases exponentially with number of
component condition.
4. PATH COVERAGE: It requires us to design test cases such that all linearly
independent paths in the programs are executed least once. These paths are
defined in terms of control-flow graph of the program.
 Maintenance

Maintenance of a typical software product requires much more effort then the
effort necessary to develop the product itself. Many studies carried out in the past
confirm this and indicates that the relative effort of development of a typical
software product to its maintenance effort is roughly in the 40:60 ratio.
Maintenance involves performing any one or more of the following three kinds of
activities;

• Correcting errors that were not discovered during the product

development phase. This is called corrective maintenance.

• Improving the implementation of the system, and enhancing the

functionalities of the system according to the customers
requirements. This is called perfective maintenance.

• Porting the software in a new environment. e.g.; porting may be

required to get the software work to work on a new computer
platform or with a new operating system. This is called adaptive
maintenance.
BIBLIOGRAPHY
 BIBLIOGRAPHY:-
1. Pressman R- software engineering

2. Agarwal Singh- software engineering

3. Rambhaugh- Object oriented modeling and design

4. Korth-Data base system concepts

5. Rajib Mall , prentice hall of India

6. Fundamentals of Software Engineering

7. Software engineering-A Practitioner’s Approach

8. The Complete reference of MS access

Other References:
1) Website- www.google.com

2) Library management system

3) Graphic era library