You are on page 1of 9

Library Management System Description

Introduction - The purpose of the system is to allow for storing details of a large number
of books and allow for add, search, borrow, return facilities separately to administrator,
staff and students. Different privileges are given to different types of users.

Using the OOSE (Object Oriented Software Engineering) we try to express the
requirements as use cases consisting of actors and how they interact with the system. We
define the objects and use cases as system objects. We define the functions and attributes
within these system objects.
Actors –
1. Administrator (Category User)
2. Staff (Category User)
3. Students (Category User)
4. Library Account (Category System)
5. Book (Category System)
6. Transaction (Category System)
7. Report (Category System)
8. Search (Category System)
9. Registration (Category System)
Objects that define the system-
1. Book (Attributes: title, author, isbn, price:
Functions: add book, remove book
Extended Functions: login, login_failed,
search_book, requisituion_ist)
2. Transaction (Attributes: student_id, book_id,staff_id
Functions: borrow_book, return_book
Extended functions: search_student,
search_staff, search_book)
3. Registration (Attributes:
student_name,student_rollno,student_id,
Staff_name, staff_designation, staff_id)
Functions: register_student, register staff
Extended Function: login, login_failed,
search_student, search_staff, search_unsuccessful)
4. Report (Attributes : book_id , student_id,date_of_return
Functions: defaulters_list, borrower_list
requisition_list
Extended Functions: login, login_failed)
5. Search (Attributes: student_id,book_id,staff_id
Functions: login, login_failed, search_book,
search_student, search_staff, search_unsuccessful)
6. Administrator (Attributes: name, administrator_id
Extended Functions: login, register, search,
transaction, report)
7. Staff (Attributes : name, staff_id
Extended Functions: login, register, search, view)
8. Student (Attributes: name, student_id
Functions: login, search)
9. Login (Attributes: student_id,administrator_id,staff_id,
Password,
Functions: login, login_failed
Extended Functions: register_student,
regisater_staff)
10. View/Edit (Attributes: student_id,staff_id,administrator_id
Functions: view_student, edit_student,
view_book, edit_book, view_staff, edit_staff,
Extended Functions: login, login_failed,
search_student, search_book, search_staff,
search_unsuccessful)
Use Cases-
1. Use Case #1 Registration
Primary Actors: Administrator, Staff
Pre- Condition: The student should have a valid college membership document
which contains his name, date_of_birth, course, rollno to obtain library
membership. The same criteria apply for registration of library and other staff
members including the administrator.
Main Scenario
1. To register a student the administrator or staff has to first login.
2. After login the administrator or staff searches for the existing
students.
3. If the student is already registered there is no need to register him.
4. If the student is not already registered then his name, roll_no is to be
entered for registration .
5. A student_id for library membership is generated and provided to the
Student.
6. To register a staff member the administrator has to first login.
7. After successful login he searches among the existing staff members.
8. If the staff member is already registered there is no need to register him.
9. If the staff member is not already registered then his name , designation is
Entered.
10. After successful registration the staff member is provided with a unique id.
Alternate Scenarios
1. The administrator or staff fails to login.
2. Administrator or staff can search for his id among existing
members.
3. If he is already a member and unable to login he should contact the
administrator otherwise he should get re-registered.

Login

Search for student/staff

ADMINSITRATOR
Enter data to register

STUDENT
Generate library id

STAFF
Re-register for failed
login

Send non-registration
msg for members
found
2. Use Case #2 Search
Primary Actors Administrator, Staff, Students
Pre-Condition: The book or student to be searched should have been registered in
the database of the library management system.
Main Scenario
1. The student or staff or administrator logins to the system.
2. If the login is successful. student or staff or administrator enters the book
name or ISBN or author name and presses search
3. If the search is successful then that book is displayed on the screen.
4. To search for a student the administrator or staff logins to the system.
5. If the login is successful then it is possible to search for any student by
entering his id.
6. To search for a staff member the administrator enters his login id.
7. If successful he can search for any of the staff members.
Alternative Scenario
1. The login fails.
2. The student or staff or administrator can re-register themselves
3. If the search is unsuccessful then the administrator should add that
members.
4. If the book search is unsuccessful then that book should be added.

Login

Enter book-id
ADMINSITRATOR
View book details

Enter student or staff-


id
STUDENT
View student or staff

STAFF Re-register for failed


login

Add book/member if
Search fails
3. Use Case #3 Transaction
Primary Actors Administrator, Staff
Pre-Condition: To return or borrow any book it is important that the student or
staff member is registered with the library and the book to be borrowed is
available witj the library. To return the book the pre-condition is that the student
and the staff member is registered and that book data is available with the library.
Main Scenario
1. If a student wants to borrow or return a book the staff or administrator
should login to the system.
2. If login is successful the staff or administrator should enter the student id
to be searched.
3. If student search is successful the staff or administrator should enter the
book id.
4. If the book is available it can be borrowed.
5. If the book is available the staff and administrator should check
The report data for any pending fine.
6. If no fine is pending the book can be returned.
Alternate Scenarios
1. If the login fails the staff or administrator should re-register
Themselves.
2. If the student search is unsuccessful and no data is found then the
administrator should re-register the student.
3. If the book search is unsuccessful and book data is not found then
administrator must enter the book in requisition report.

Login

Search for book


ADMINSITRATOR
Search for student

Add book if search fails

STUDENT
Add student if search fails

STAFF Check pending fines for


a student

Borrow or return book


4. Use Case #4 Book (Add/Remove)
Primary Actors : Administrator, Staff
Pre-Condition : To add any book that book should be part of the requisition list
and to delete the book the book must be part of the library.
Main Scenario
1. The staff or administrator login to the system.
2. If login is successful then to add a book the staff or administrator must
search for the book.
3. If the book is not found then it is checked in the requisition list.
4. If the book is not currently available and is part of the requisition list it can
be added to the book database.
5. To remove a book it is again searched in the library system.
6. If it is found it should be checked in borrower_list.
7. If it is not in the borrowed list it can be removed.
Alternate Scenarios
1. If the login is unsuccessful then staff should re-register themselves.
2. If a book is to be added and on search it is already found it should not e
added again.
3. If book is to be removed and on search it is not found and is also not part
of borrowers_list then there is any need to remove it.

Login
ADMINSITRATOR

Search book STUDENT

Check book in requisition


list

Add book if in req-list

STAFF
Remove book in rem-list

Re-register for failed


login

Do not add book if


already in list
5. Use Case #5 Report

Primary Actors Administrator, Staff


Pre-Condition : To generate any report the staff or administrator should be
registered with the library and to generate report on any book or student they
should be part of the library system
Main Scenario
1. The staff or administrator logins to the system,
2. To generate report on defaulters the staff or administrator should first
search for that student.
3. If the student is found then he can be checked in the defaulters list.
4. To generate report on borrowed books the staff or administrator must
search for that book.
5. If found that book can be checked in the borrowed books list.
6. To generate report on requisition list of book the he staff or administrator
should first search for that book.
7. If book is not found then it should be checked in the requisition list.
Alternate Scenarios
1. If the login is not successful then staff or administrator should go to the
registration page.
2. If student is not found after search he should be re-registered.
3. If book is not found then that book should be added again before checking
it in the borrowers list.

Login

ADMINSITRATOR Search student

Generate defaulter report


STUDENT

Search for book

Generate re-list report

STAFF
Generate borrowed
books report

Re-register for failed


login
6. Use Case #6 Login
Primary Actors: Administrator, Staff, Student
Pre-Condition: If the student or staff or administrator wants to login then he
should have been first registered.
Main Scenario
1. To login the student or staff or administrator should first open the
Login page.
2. They should then enter their ids and passwords.
3. Once the id and password are verified they are moved to the options page
where they can search, view and perform other operations.
Alternate Scenario
1. The login fails after entering login and password.
2. It is the responsibility of the administrator to see that all staff and students
are properly registered and can login to the system

Open login screen

ADMINSITRATOR
Enter id

Enter password
STUDENT
Choose options if
successful

Re-login if wrong data


STAFF

Re-register for failed


login
7. Use Case #7 View/Edit
Primary Actors: Administrator, Staff
Pre-Condition: To view the details of any book or edit book details that book
should be part of the library database. To view or edit student or staff details that
student or staff should be part of the library database. Whoever is viewing or
editing should be registered with the library.
Main Scenario
1. To view details or edit details of any book the administrator or staff should
first login to the library system.
2. If login successfully they must search for that book by putting book id or
title or isbn.
3. If the book is found they should enter book id to view the details and also
edit it.
4. To view details or edit details of any student or staff the administrator or
staff should first login to the library system.
5. If login successfully they must search for that student or staff by putting
student id or staff id.
6. If the student or staff is found they should enter student id or staff id to
view the details and also edit it.
Alternate Scenarios
1. If login fails the administrator should re-register that staff
2. If book search is unsuccessful then that book cannot be viewed or edited.
3. If staff search is unsuccessful then that staff member cannot be viewed or
edited.

Login

ADMINSITRATOR Search student/staff

View/edit
student/staff

Search for a book


STUDENT
View/edit book details

STAFF
Re-register for failed
login

Add book/student/staff
if search fails

You might also like