Project Report

On
LIBRARY MANAGEMENT SYSTEM

Submitted By

Mr. GADIYAKARI VENKAT RegdNo:18B91A0562

 
                 

           DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

S.R.K.R ENGINEERING COLLEGE
(Affiliated to JNTU UNIVERSITY, KAKINADA)

BHIMAVARAM-534204
(2020-2021)

i
 DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

S.R.K.R. ENGINEERING COLLEGE

BHIMAVARAM

CERTIFICATE
This is to certify that this is a bonafide work on “The design and Implementation of
Library Management System” and has been submitted by Mr. G. Venkat
(18B91A0562) in partial fulfillment of the requirements for the award of the degree of
Master of Technology in Computer Science and Technology, during the academic
year 2020-2021. The candidate worked right under my Supervision and guidance.

Lecturers In-Charge Head of the Department

Sri L.V. Srinivas, Prof. V. Chandra Sekhar,

Assistant Professor, Head of the Department,

Department of CSE, Department of CSE,

S.R.K.R. Engineering College, S.R.K.R. Engineering College,

Bhimavaram. Bhimavaram.

ii
 TABLE OF CONTENTS

S.N CONTENTS Page

o No
1. ABSTRACT 1
2. SOFTWARE REQUIREMENT SPECIFICATION 2
2.1. Introduction 2
2.2. Current System 3
2.3. Proposed System 3
3. UML DESIGN 8
3.1. Use Case Diagram 9
3.2. Class Diagram 13
3.3. Sequence Diagram 14
3.4. Collaboration Diagram 17
3.5. State Chart Diagram 20
3.6. Activity Diagram 23
4. SYSTEM DESIGN DOCUMENT 27
4.1. Introduction 27
4.2. Current Software Architecture 28
4.3. Proposed Software Architecture 28
4.4. Subsystem Services 29
4.5. Database Design 31
5. IMPLEMENTATION SCREENS 33
6. SYSTEM TESTING 35
7. CONCLUSION 39
8. REFERENCES 40

iii
 LIST OF FIGURES

Fi P
gure age
no Name of Figure no
3.
1 Use case diagram 7
3.
2 Class diagram 8
3.
3 Sequence diagram for User 9
3. 1
5 Sequence diagram for Admin 0
3. 1
6 Activity diagram 1
3. 1
7 State chart diagram 2

v
 LIST OF ABBREVIATIONS

 HTTP: Hypertext Transfer Protocol.

 JDBC: Java Database Connectivity.

 HTML: Hypertext Markup Language.

 PHP: Hypertext Preprocessor.

 JS: JavaScript.

 CSS: Cascading Style Sheets.

vi
 1. ABSTRACT

A Library Management System is software that manages and stores books information
electronically according to student needs. The system helps both students and library managers
to keep a constant track of all the books available in the library. It allows both the admin and the
student to search for the desired book. It becomes necessary for colleges to keep a continuous
check on the issued books, returned books, and even calculate fines. This task if carried out
manually would be tedious and prone to errors. These errors can be avoided by allowing the
system to keep track of information such as issue date, return date, and even fine information,
and thus there is no need to keep manual track of this information which thereby avoids chances
of mistakes.
Thus this system reduces manual work to a great extent allows smooth flow of library activities
by eliminating the possibility of errors.

vii
 2. SOFTWARE REQUIREMENT SPECIFICATION
2.1 Introduction:
The Library Management System is an application for assisting a librarian in managing a book library in
a university. The system would provide basic set of features to add/update members, add/update books,
and manage check in specifications for the systems based on the client's statement of need.

2.1.1 Purpose of the System:

Library Management System provides user friendly platform for keeping track of book information
online. The services that are provided here are checking for available books, updating book details, and
maintaining library members information.

2.1.2 Scope of the System:

 There are Two types of users –

1. Admin
2. Users (students)
 There are two types of Modules
Student Management Module:
Module used for managing student details.
Books Management Module:
Module which allows the admin to manage the information and details of the books.
 The user can search, borrow a book based on his/her requirement.
 The admin will issue the book and update the book status.

2.1.3 Objective:

The main objective of the Library Management System is to manage the details of Address,
Member, Issues, Books, Student.

2.1.4 Definitions, acronyms, and abbreviations:

User: A person who want to search, borrow, or return a book. Ex: Students
Administrator: A person who issues a book, updates the book details, and has centralized
control over the system.

2.2 Current System:

In the Current system, if a student wants to borrow a book, he/she goes to the counter of the
reference section and asks the librarian for the book he/she wants. If the book is in the stock, the
librarian gets the book, register the details of the book and the student, and then give the book to
the student.

2
2.3 Proposed System:
In future enhancement of the system, books and library members can be managed online.

2.3.1 Functional Requirements:

Functional requirements are the requirements which deals with the operational requirements of
the system and the requirements that are requested by the user.

User:

 User can Sign up.

 User can Login into the system.
 User can browse list of available books.
 User can view currently borrowed books.

Administrator:

 Administrator is the one who can manage the entire site and prevents unauthorised
access to database.
 Administrator takes the responsibility to manage library members information and
available books information.

2.3.2 Non-Functional Requirements:

Non-functional requirements describe user visible aspects of the system that are not directly
related with the functional behaviour of the system. Non-functional requirements include
quantitative constraints such as response time or accuracy.

2.3.2.1 Hardware considerations:

 Minimum Requirements

Software Processor RAM Disk Space

Google Intel Pentium III 128 MB 100 MB

Chrome-6
(or)
AMD –
800MHz

Xampp Intel Pentium III 3.5 GB

(or)
AMD –
800MHz

3
  Recommended Requirements:

Software Processor RAM Disk Space

Google Intel I3 (higher) 1GB 40GB

Chrome– 8
(or)
AMD – 1 GHz

VsCode Intel I3 (higher) 2GB (higher) 40 GB

(or) 1GB
AMD – 1 GHz

Software considerations:

 UML : Rational rose

 Operating system : Windows XP, Windows 7, Windows 8, Windows 10
 DBMS : MySQL
 Web technology : HTML, CSS, JavaScript,PHP
 Web server : Xampp

2.3.3 SYSTEM MODELS:

Object oriented design is concerned with developing an object-oriented model of a software

system to implement the identified requirements. It is the process of defining components,
interfaces, objects, classes, attributes, and operations that will satisfy the requirements. We
typically start with candidate objects defined during analysis but add much more rigor to their
definitions. Then we add or change objects as needy to refine a solution.

Object oriented design can yield the following benefits.

Maintainability:

Through simplified mapping to the problem domain, which provides for less analysis effort, less
complexity in system design, and easier verification by the user.

Reusability: Reusability of the design saves time and cost.

2.3.4 Use case Diagram:

4
A use case is a list of actions or event steps typically defining the interactions between a Actor
and a system to achieve a goal. The actor can be a human or other external system.

2.3.4.1 Identification of Actors:

Actors represent system users. They help delimit the system and give a clearer picture of what
the system should do. It is important to note that an actor interacts with but has no control over
the use cases.
An actor is someone or something that:
• Interacts with or uses the system.
• Provides input to and receives information from the system.
• Is external to the system and has no control over the use cases.
An actor can be represented as shown below:
1.A class rectangle with the label <<actor>>
<<actor>>

Administrator
2. The stick figure with the name of the actor below.

Administrator user

Actors identified are:

1. Administrator.
2. User.

2.3.4.2 Identification of Use cases:

In its simplest form, a use case can be described as a specific way of using the system
from a user’s (actors) perspective.

A more detailed description might characterize a use case as:

• A pattern of behaviour the system exhibits.
• A sequence of related transactions performed by an actor in the system.
• Delivering something of value to the actor.
Use cases provide a means to:
• Capture system requirements.
• Communicate with the end users and domain experts.
• Test the system.

Use cases are the best discovered by examining the actors and defining what the actor will be do
with the system. Since all the needs of a system typically cannot be covered in one use case, it is
usual to have a collection of use case. Together this uses case collection specifies all the ways of
using the system.

5
2.3.4.3 Constructions of Use case diagrams:

Use-case diagrams graphically depict the system behaviour (use cases). These diagram’s present
a high-level view of how the system is used as viewed from an outsider’s(actor’s) perspective.
A use-case diagram can contain:
• Actors (“things” outside the system)
• Use cases (system boundaries identifying what the system should do).
• Interactions or relationships between actors and use cases in the System include the
associations, dependencies, and generalizations.

2.3.4.4 Use Case Description:

Use case name : Main use case

Participating actors : User, Administrator
Entry conditions : User enter the Library Management System.
Flow of events :
1. Users browse the list of available books.
2. User can visit the library and borrow his /her book if available.
3. Admin issues the book.
4. Admin will update the book information as well as member information.
Exit condition: The system stores the information in the database and respond with profile
modified successfully.

Special requirements: The response should be obtained within 30sec.

2.4. GLOSSARY:

HTTP:
Hypertext Transfer Protocol is a transaction-oriented client or server protocol between web
browser and web server.

HTML:
Hypertext Mark-up Language. It is a mark-up language used to design static web pages. An
HTML file can be created using text editor.

CSS: Cascading Style Sheets is a language that describes the style of an HTML document. CSS
describes how HTML elements should be displayed.

PHP: PHP is a server-side scripting language designed for web development but also used as a
general-purpose programming language

6
 3. UML DESIGN

3.1 Use Case Diagram:

 A use-case diagram is a graph of actors, a set of use cases enclosed by a system

boundary, communication (participation) associations between the actors and the use
cases, and generalization among the cases.

Fig.3.1 use case diagram

7
3.2 Class Diagram:

 The class diagram describes the attributes and operations of a class and the constraints
imposed on the system. The class diagrams are widely used in the modeling of object-
oriented systems because they are the only UML diagrams which can be mapped with
object-oriented languages.

Fig 3.2 class diagram

8
3.3 Sequence Diagram:

 A sequence diagram is an interaction diagram that details how operations are carried
out – what messages are sent and when. Sequence diagrams are organized according
to time. Time progresses as you go down the page. The objects involved in the
operations are listed from left to right according to when they take part in the message
sequence.

Fig 3.3 Sequence diagram for User

9
3.4 Activity Diagram:

 An activity diagram is a visual representation of any system’s activities and flows of

data or decisions between activities.
 They are flow charts that are used to show the workflow of a system.
 They show the flow of control from activity to activity in the system

Fig 3.4 activity diagram

10
3.5 State chart Diagram:

 A state chart diagram describes a state machine. Now to clarify it state machine can
be defined as a machine which defines different states of an object, and these states
are controlled by external or internal events.

Fig 3.5 state chart diagram

11
3.6 Component Diagram:

 Component diagrams are used to model physical aspects of a system. Physical aspects
are the elements like executables, libraries, files, documents etc which resides in a
node.
 So, component diagrams are used to visualize the organization and relationships
among components in a system.

3.7 Deployment Diagram:

 Deployment diagrams are used to visualize the topology of the physical components of a
system where the software components are deployed.
 This diagram consists of nodes and their relationships.

12
 4. SYSTEM DESIGN DOCUMENT
4.1 Introduction:
Online university complaint management system is the technology in which the complaint is filed by
the students/faculty through online. Here the advantage is the users need not to go anywhere to
register a complaint

4.1.1 Purpose of the system:

The main purpose of this project is to develop online complaint system.

4.1.2 Design Goals:

Design goals originate from the nonfunctional requirements specified during requirements elicitation
and from technical and management goals specified by the project.

Based on performance criteria:

 Response time: After the request has been issued, user request is acknowledged within 30
seconds.
 Throughput: System can accomplish more tasks in a fixed period of time.
 Memory: Space required to run system should be as possible as minimum.

Based on dependability criteria:

 Robustness : System should have the ability to identify the invalid input
 Availability : System should provide the 24x7 facility to the user.
 Fault tolerance : System should operate even in the erroneous conditions.
 Security : System should have the ability to withstand malicious attacks.
 Safety : System should have the ability to avoid endangering human lives, even in
the presence of errors and failures.

Based on cost criteria:

 Development cost : Cost of developing the initial system is as possible as minimum.

 Deployment cost : Cost of installing the system and training the users is as possible as
minimum.
 Upgrade cost : Cost of translating data from the previous system is as possible as
minimum.
 Maintenance cost : Cost required for bug fixes and enhancement to the systems is as
possible as minimum.
 Administration cost : Cost required to administer the system is as possible as minimum.

13
Based on maintenance criteria:

 Extensibility : It should be easy to add functionality or new classes to the system.

 Modifiability : It should be easy to change the functionality of the system.
 Adaptability : It should be easy to port the system to different application domains
 Portability : It should be easy to port the system to different platforms.
 Readability : It should be easy to understand the system from reading the code
 Traceability of requirements : It should be easy to map the code to specific requirements.

Based on end user criteria:

 Utility : System should support the work of the user well.

 Usability : It should be easy for the user to use the system.

4.1.3 Definitions, Acronyms and Abbreviations:

User:

User is a person who uses the system and can perform some of the actions.

Administrator:

Administrator is the person who manages the system.

4.1.4 Overview:
In this system the user is provide with the login/signup forms with which the user can register a
complaint and the admin is provide with the separate username and password through which he can
check the complaints and check statusesof complaints and finally the admin is provide with the
another ui page in this he can update the complaint status.

4.2 Current software Architecture:

At present in this system the user is provide with the service to register the complaint and check the
complaint status. The admin is provide with the permission to take the necessary actions and to
inform the resolver staff about the registered complaint. The admin provides the permissions to view
the complaint and update the complaint status.

4.3 Proposed System Architecture:

In future enhancement of the user the edit of the given complaint can be done online by using login
of the user.

14
4.3.1 Overview:
The system provide the user to register the complaint through online. So that the students/staff need
not to go for file a complaint. Admin will directly take the necessary actions through the resolver
staff and he will check the complaints and update the complaint status.

4.3. Subsystem decomposition:

This describes the decomposition into subsystem and the responsibilities of each. This is the main
product of system design domain. This decomposition aimed to reduce the complexity of the
solution.

Fig 4.1 Subsystem decomposition

4.3.2.1 Admin Subsystem:

It is responsible for checking the complaints and updating the status of complaints

4.3.2.2 User subsystem:

It is responsible for register and edit the complaints and check the status of registered complaints

4.3.3 Hardware/Software mapping:

Hardware/software mapping describes how subsystem is assigned to hardware and off-the-shelf
components. It is also leads to definition of additional subsystem dedicated to move data from one
node to another, dealing with concurrency and reliability issues.

Selecting a hardware configuration also includes selecting a virtual machine on which the system
should be built such as OS and any software components needed. The operating systems used are
Windows 7 and the database management system is Oracle.

Deployment diagram :

4.3.4 Persistent data and management:

Persistent data outlive a single execution of the system. The entity objects identified during analysis
are persistent objects. They are identified by examining all that must survive system shutdown,
either in case of a controlled shut down or unexpected crash.

15
Persistent data management describes the persistent data stored by the system and the data
management infrastructure required for it. In this system, the data stored by the administrator should
be persistent.

Persistent data objects should be stored using a definite storage management system. We use a
relational database management system for the sake of concurrency management, access control and
crash recovery.

4.3.5 Access control and security:

The system provides different access control to different users. Our system provides better
authentication to maintain security for accessing relevant functionalities like the user is not allowed
to modify the games and database and the administrator can only update the games and database.

4.3.6 Global software control:

Global software control describes how requests are initiated and how subsystems synchronize. This
section should list and address synchronization and concurrency issues.

Control flow is the sequencing of actions in a system. In object-oriented systems, sequencing actions
include deciding which operations should be executed and in which order. Control flow is a design
problem.

Our system follows procedure driven flow of control. We wait for the user to submit his input and
then provide the required functionality.

4.3.7 Boundary conditions:

Boundary condition describes the start-up, shut down and error behavior such as data corruption and
network outages of the system are dealt with. If new use cases are discovered for system
administration, these should be included in the requirement analysis document.

Boundary conditions are found by examining each subsystem and each persistent object. The user is
altered when he tries to get in with wrong entering of data.

For each persistent object, we identify when it is created or destroyed.

For each type of component failure, the users are informed of the failure and hence the effects are
tolerated.

4.4 Subsystem services:

The system is decomposed into subsystem which provides associated functionalities. This
decomposition aimed to reduce the complexity of the solution domain.

4.4.1 Admin Subsystem:

It is responsible for check the complaints and update the status of complaint in the system and
maintaining the system.

16
4.4.2 User subsystem: It is responsible for register and edit a complaints and to check the status of
registered complaints

4.4.3 Communication Subsystem:

It establishes communication between subsystems.

4.5 Database Design:

Database design is the process of producing a detailed data model of a database. This logical data
model contains all the needed logical and physical design choices and physical storage parameters
needed to generate a design on a Data Definition Language, which can then be used to create a
database. It can be thought of as the logical design of the base data structures used to store the data.
In the relational model these are the tables and views.

Table Name LOGIN TABLE FOR ADMIN/USER

S.N Field Name Type Description
o
1. Name Varchar(30) Name of the admin/user

2. password varchar(20) Password set by the administrator/user

Table Name: REGISTRATION FOR USER

S.N Field name Data type Description

o
1. User name Varchar(30) Name of the user

2. Reg no Varchar(30) Registration number of user

3. Mobile no Int(20) Phone No of user

4. password Varchar(10) Password set by the user

17
 5. IMPLEMENTATION SCREENS

Home page:

Service Page:

18
Gallery Page:

19
 6. SYSTEM TESTING
A primary purpose of testing is to detect software failures so that defects may be uncovered and
corrected. This is a non-trivial pursuit. Testing cannot establish that a product functions properly
under all conditions but can only establish that it does not function properly under specific
conditions. The scope of present software testing includes examination of code as well as execution
of that code in various conditions as well as examining the quality aspects of code: does it do what it
is supposed to do and do what it needs to do.

Software testing methods are traditionally divided into white-box, black-box.

White box testing focus on the internal structure of the component.

Black box testing focus on input/output behavior of the component.

6.1 Testing Levels

Tests are frequently grouped by where they are added in the software development process, or by the
level of specificity of the test.

 Unit testing refers to tests that verify the functionality of a specific section of code,
usually at the function level.
 Integration testing is any type of software testing that seeks to verify the interfaces
between components against a software design. Software components may be integrated
in an iterative way or all together.
 System testing is a completely integrated system to verify that it meets its requirements.
 System integration testing verifies that a system is integrated to any external or third
party systems defined in the system requirements.
 Regression testing tests new functionality in a program. It is done by running all of the
previous unit tests written for a program, if they all pass, then the new functionality is
added to the code base.
 Acceptance testing is conducted by a user to verify that the system meets the acceptance
criteria.

20
6.2 Test Cases

In general, a test case is a set of test data and test programs and their expected results. A test case
in software engineering normally consists of unique identifier, requirement references from a design
specification, preconditions, events, a series of steps (also known as actions) to follow, input, output
and it validates one or more system requirements and generates pass or fail.
Test Case 1: Testing on Login

Test Objectives: Validating Login of anUser.

TEST INPUT OUTPUT PASS/

CONDITION SPECIFICATION SPECIFICATION FAIL
Entering wrong If correct specifications 1. Direct to next page PASS
specifications are entered
or null values
in registration If wrong specifications 2. Displays error message FAIL
page are entered

Success Case: Correct Specifications are entered and its direct to next page.

21
 Fig. Screenshot of login page

Fig. Screenshot of Directed page

Failed Case: User trying to submit null valuesand wrong credentials.

Fig. Screenshot of Login page with Wrong Credentials

22
Fig. Screenshot of Login page with Error Message

Fig. Screenshot of Login page with Empty Username

23
Fig. Screenshot of Login page with Emptypassword

Fig.Screenshot of registration page

24
Fig. Screenshot of compalint registartion page

Fig. Screenshot of Complaints page

25
 Fig. Screenshot of Change Status page for admin

7.CONCLUSION
Our project is to provide online platform to the students/staff to register complaints. Here the
advantage is the students/staff need not to go anywhere to submit complaints.

This site has been computed successfully and was also tested successfully by taking test cases.
It is friendly and has required options which can be utilized by the user to perform desired
operations.

This site was developed using HTML,CSS as front end and PHP as back end in windows
environment. The goals that are achieved by the site are:

 User friendly.
 Portable and flexible for future enhancement.

Future enhancements:

26
 It is not possible to develop a system that makes all the requirements of the user. User
requirements keep changing as the system is being used. Some of the future enhancements that
can be done to this system are:

 As the technology emerges, it is possible to upgrade the system and can be adaptable to
desired environment.
 Because it is based on object-oriented design, any future changes can be easily adaptable.
 Based on future security, it can be improved using emerging technologies.

8.REFERENCE

 Web Technologies by c.xavier

 Uml user guide by Jacobson,Rambaugh,Booch
 Object oriented software engineering by Brendbruegge and Allenh.Dutoit
 www.w3schools.com

27