ASSIGNMENT NO.

02

LIBRARY MANAGEMENT SYSTEM

SUBMITTED TO:

Mr. SUMEDH PUNDKAR

SUBMITTED BY:

RASIKA CHAUDHARY(C-309)
MAYURI MULGIR(C-340)
SNEHAL PATIL(C-349)
SNEHA UKEY(C-364)
SWARNA WASNIK(C-369)

USHA MITTAL INSTITUTE OF TECHNOLOGY

SNDT WOMEN’S UNIVERSITY
SANTACRUZ(W)
MUMBAI-49
INTRODUCTION

This system can manage all the happenings of the Library. Book transactions including Book Registration,
Students Registration, Book Issuing, Current Status of a particular books etc. can be very easily handled by
this module. Overall this system can be very helpful and it can makes things easier.

The “LIBRARY MANAGEMENT SYSTEM” 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 Books and Students 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 student and
books available in the library.

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 users requirements. The computerization of the Library
Management will not only improves the efficiency but will also reduce human stress thereby indirectly
improving human recourses.
CLASS DIAGRAM

Identify the classes in the problem domain:

This is the first and most important step for creating the class diagram. What classes should you
include and how to identify them given a problem statement or a scenario? The solution is simple and
some time should be spent with the client / system engineers /your teacher in case you are making an
academic project or any concerned authority having the required business knowledge. The first step
however is creating a problem statement or establishing a set of requirements that the software should
fulfill. E.g. you need to create a small library management system. What are some of the requirements for
the system? Let’s try to make a problem statement or the scenario for your design. For the sake of simplicity
considers the following simple problem Statement. “The library management system would be used by the
librarian to keep track of books, library members and the borrowing activity. Not all books can be borrowed
by the members. Some books may only be available to review in the library; all such books are termed as
Reference books. There are 2 types of library members students and college faculty members. Faculty
members can also check out research papers and magazines where as students can only checkout books. The
system need to send alerts whenever a book that has to be returned within a specific date is not returned. An
email is sent to the librarian and the borrower. The system maintains a catalogue having a description of
each book that is available in the library”

Ways to identify Classes:

Do the Noun Analysis: Go through the problem statement again and again and try to figure out all the nouns
that you come across. In our case some strong contenders for the classes of the library management system
would be:
Librarian,Book,Member,Catalogue,Student_Member,Faculty_Member,Reference_Book,Issueable_Book,
Alert .
Perhaps there might be some nouns that I skipped but why?? I did that intentionally because of either of the
two reasons. Either there is no data associated with them. They have no role to play in the system i.e. they
don’t have any functions or actions associated with them. So by this we mean that “In order for a noun to be
an object or a class it should have some attributes or member data and some actions or member functions.

Resolving the relationships between classes:

Object oriented analysis and design is all about relationships between objects. Look for a certain type
of relationships. These include generalization/inheritance/specialization, composition / containership,
aggregation/ collections and associations. All of these are explained briefly below and discussed in terms
of our scenario. There are some key questions associated with object oriented design over here. How data is
passed between the classes? What classes should have the objects of another class?What classes create the
objects of other classes?What are some of the utility classes that the application requires? All these
questions play an important role in the design. Think in terms of hierarchy for
generalizations/inheritence:First of all check for hierarchy that may exist between the classes or the
objects.This would model the inheritance or generaliztion or the superclass/subclass relationship.In
natural language this might resolve to “type of” or “can be”. If you find such words in a problem statement
there might be a case of generalization. E.g. In our scenario take the three classes BOOK ,
REFERENCE_BOOK and ISSUEABLE_BOOK . So a book can be a reference book or an issue able book
or you can say that reference books and issue able books are the type of books. They all should ideally share
many characteristics which are common to all the three classes.What I mean to say is, whether it is any book
(reference or issue able) they all have ISBN number, author a language, a topic e.t.c so what is the
difference. The difference is implied by the business rule that reference books cannot be issued but only
reviewed. So for reference books we might add a Boolean data member called m_bReference and set it to
true or something. Same is the case with Member, Student_Member and Faculty_Member. Inheritance is
indicated in the class diagram with a filled black triangle pointing towards the base class and connecters
connecting it to all the derived classes. In our scenario the inheritance could be shown as the figure below:

Think of the Part-Whole Relationships:

Now we know what might be the possible hierarchies in your system and what might be the common
data members and the common functions. What are the differences and how the qualify to be another class.
Another important type of relationship in terms of Object Oriented Analysis and Design is the “Part of”
or “Part Whole” relationship. In Natural language, you might come across “has a” words to quickly
identify these kind of relationships. In the list of candidate classes observe which of the objects the part of
other objects is. This can also be taken as collection.To give you some examples for common scenarios. A
Windows form is a collection of many controls.An automobile is composed of many parts.A shopping cart
has many itemsA university is comprised of many campuses Here you want to ask a simple question to
resolve the type of relationship and to know whether it is an aggregation or a composition. “Is the whole
destroyed when the part is destroyed” or “It doesn’t make a difference to the Whole if the part is
destroyed”. Now going through this example list. A form would still exist if any of the control is
destroyed; the form serves it purpose properly. This implies an aggregation .An automobile wont function
properly if any of its parts are destroyed e.g. it cannot function if the tires, steering, battery is taken out so
this implies composition. A university will still exist if a campus is destroyed. So it depends upon the
scenario and the business rules.

Returning to our depicted scenario the only part whole relationship noticeable is perhaps the
catalogue. A catalogue has list of books available in the system with a short description of each. The
catalogue is not destroyed if a book is destroyed so I would use aggregation in the design. In UML
aggregation is shown with an empty diamond where as composition is shown with a solid black diamond.

The Uses relationship – Association:

Many objects use the methods/functions of other classes for utility. The objects are somehow
related might be statically or dynamically but there is not a hierarchy or a part whole relationship.
Such relationships are called association and can be mostly identified with “makes use of” or “uses”
in the problem statement. E.g. There is a class called “Pen” which exposes a method called “Draw ()”.
There is also a “Shape” class having a method called“drawShape ( )” . In the implementation of
“drawShape( )” it internally calls / invokes the “Draw ()” method exposed by Pen. In our scenario A
librarian uses the book and student information to issue a book.The catalogue needs a reference of the book
to add or update itselfAnd probably some more:
Fig: Class diagram for library management system
Fig: Class diagram for library management system
Classes Attributes Operations

Library management system userType Login

userName Register
userPass Logout
userInfo
User userId verifyUser
userName search
userInfo checkAccount
userPass
searchString

Keyboard searchString acceptSearchString

userInfo
Librarian userName verifyLibrarian
userPass search
userInfo
searchString
LibraryInventory listOfBooks add
delete
update
check
LibraryDatabase nameOfDatabase openDatabase
closeDatabase
updateDatabase
Browser accountInfo displayAccountInfo
itemInfo displayItemInfo
navigate
Item itemId displayDueDate
type giveFeedBack
title showDetailsInfo
category
publisher

Book author renew

inbox homeDelivering
requestNewBooks

AccountInfo formattedListOfREnewedBooks formatAccountInfo

ItemInfo formattedTitle formatItemInfo
formattedInfo
Account listOfRenewedItem calculateFine
listOfReservedItem
fine
VIPUser
RegularUser
Fig: Class diagram for library management system with UML
STATE DIAGRAM

Changes in the system that occur, such as a background thread while the main process is running, are
called "sub states." Even though it affects the main state, a sub state is not shown as a part of the
main state. Hence, it is depicted as contained within the main state flow.

As you saw above, a state is represented by a rectangle with rounded edges. Within a state, its Name,
variables, and Activities can be listed as shown in Figure 6.1.

Figure 6.1: the structure of the state element

DATA FLOW DIAGRAM

When building a data flow diagram, the following items should be considered:

• Where does the data that passes through the system come from and where does it go,

• What happens to the data once it enters the system (i.e., the inputs) and before it leaves the system

• What delays occur between the inputs and outputs (i.e., identifying the need for data stores).

Steps to draw data flow diagram

• Start from the context diagram. Identify the parent process and the external entities with their
netinputs and outputs.

• Place the external entities on the diagram. Draw the boundary.

• Identify the data flows needed to generate the net inputs and outputs to the external entities.

• Identify the business processes to perform the work needed to generate the input and output data
flows.

• Connect the data flows from the external entities to the processes.

• Identify the data stores.

• Connect the processes and data stores with data flows.

• Apply the Process Model Paradigm to verify that the diagram addresses the processing needs of all
external entities.

• Apply the External Control Paradigm to further validate that the flows to the external entities are
correct.

• Continue to decompose to the nth level DFD. Draw all DFDs at one level before moving to the next
level of decomposing detail. You should decompose horizontally first to a sufficient nth level to
ensure that the processes are partitioned correctly; then you can begin to decompose vertically.
Fig: Functional diagram for library management system
Fig: Functional diagram for library management system