LUKHDHIRJI ENGINEERING COLLEGE,

MORBI

LAB MANUAL OF

SOFTWARE ENGINEERING LAB

3161605

Faculty Name : Rakesh Parmar Student Name: Patel Tej

Roll No.: 220310116024
Semester:6th
Batch : A2
SOFTWARE REQUIREMENTS SPECIFICATION

Library management
system
Version 1.0
May 3,2025
 INDEX
[Link]. .Name of the Program Page Signature Remarks
No.
1. Write the complete problem statement

2. Write the software requirement

specification document

3. Draw the entity relationship diagram

4. Draw the data flow diagrams at level 0

and level 1

5. Draw use case diagram

6. Draw activity diagram of all use cases

7. Draw state chart diagram of all use cases

8. Draw sequence diagram of all use cases

9. Draw collaboration diagram of all use

cases

10 Assign objects in sequence diagram to

classes and make class diagram
 EXCERCISE NO. 1

AIM: To prepare PROBLEM STATEMENT for Library Management System .

In educational institutions and public libraries, managing books, members, borrowing transactions, and returns
manually leads to inefficiencies, human errors, and delays in service. Traditional systems often lack real-time
tracking, data consistency, and the ability to generate reports or search quickly. As libraries grow in size and user
base, the manual approach becomes increasingly unsustainable, affecting user satisfaction and operational
efficiency
Therefore, there is a need for a computerized Library Management System (LMS) that automates and streamlines
library operations such as catalog management, user registration, book issue/return tracking, overdue fine
calculation, and report generation. The system should provide a user-friendly interface for both librarians and
members, improve accuracy, reduce redundancy, and enhance accessibility of information.
 EXCERCISE NO. 2

Table of Contents

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions, Acronyms, and Abbreviations

1.4 References

1.5 Overview

2. The Overall Description

2.1 Product Perspective

2.2 Product Functions

2.3 User Characteristics

2.4 Constraints

2.5 Assumptions and Dependencies

3. External interface Requirements

3.1 User Interfaces

3.2 Hardware Interfaces

3.3 Software Interfaces

3.4 Communications Interfaces

4. System Features
4.1 Core Features
4.2 User Interface Features
4.3 System Administration Features

[Link] Non-Functional Requirements

5.1Performance Requirement
5.2 Software System Attributes
3.6.1 Reliability
3.6.2 Availability
3.6.3 Security
3.6.4 Maintainability
5.3 Business Rules
 6. Other Requirements
Appendix A: Glossary
Appendix S: Analysis Mode
1. Introduction
This section of the Software Requirements Specification (SRS) provides an overview of the requirements for the
Library Management System (LMS). It describes the purpose, scope, and context of the system, and provides
necessary background information for the reader.
1.1 Purpose
The purpose of this Software Requirements Specification (SRS) is to clearly and unambiguously define the
requirements for the development of a Library Management System (LMS). This document serves as a contract
between the development team and the stakeholders, outlining the features, functionality, performance, and
constraints of the system. It will be used by:
•The development team as a guide for system design and implementation.
•The testing team as a basis for verifying system functionality.
•The project manager for tracking project progress and ensuring that the system meets the stakeholders' needs.
•The stakeholders to confirm that the system will fulfill their requirements and expectations.
1.2 Scope
This Library Management System (LMS) will be a web-based application designed to manage and automate the core
operations of a library. The scope of this system includes, but is not limited to, the following functionalities:
•Catalog Management:
• Adding, updating, and deleting library resources (books, journals, audio-visual materials, etc.).
• Cataloging resources using [Specify cataloging standard, e.g., MARC, if applicable].
• Searching and browsing the library catalog by various criteria (title, author, subject, ISBN, etc.).
• Categorizing and classifying resources.
•Member Management:
• Registering new library members.
• Maintaining member information (personal details, contact information).
• Managing member categories (e.g., student, faculty, staff, visitor) and associated privileges.
• Tracking member borrowing history.
•Circulation Management:
• Issuing (borrowing) resources to members.
• Returning resources.
• Renewing borrowed resources.
• Managing holds/reservations for resources.
• Calculating and managing fines for overdue materials.
•Reporting:
• Generating reports on resource inventory, circulation statistics, member activity, and other relevant data.
•System Administration:
• User role management and access control.
• System configuration and maintenance.
This version of the system will not include the following:
•Inter-library loan functionality.
•Integration with external payment gateways for online fine payment.
•Digital resource management (e.g., e-books, online journals). ( If this is out of scope)
1.3 Definitions, Acronyms, and Abbreviations:

LMS Library Management System

ISBN International Standard Book Number

RFID Radio-Frequency Identification

1.4 References
The following documents are referenced in this SRS:
•IEEE Std 830-1998, Recommended Practice for Software Requirements Specifications.
•[Insert any other relevant documents, such as:]
• [Name of Library]'s Cataloging Guidelines.
• [Name of any relevant data dictionaries or standards].
• [Link]
1.5 Overview
The remainder of this document provides a detailed description of the requirements for the
Library Management System. The subsequent sections are organized as follows:
•Section 2, "Overall Description," provides a general overview of the system, including the
product perspective, user needs, and operating environment.
•Section 3, "Specific Requirements," details the functional and non-functional requirements that
the system must fulfill. Functional requirements describe the specific actions that the system must
be able to perform, while non-functional requirements describe the qualities that the system must
possess, such as performance, security, and usability.
2.1 Product Perspective
This subsection describes the context of the system and its relationship to other systems.
The Library Management System is a standalone, web-based application. It is not intended to replace any existing
library systems, but to provide a modern, user-friendly interface and efficient tools for managing library resources
and operations. It may, however, in future, be integrated with other systems. The system will interact with the
following:
•Library Database: The system will use a database (e.g., MySQL, PostgreSQL) to store information about library
resources, members, and transactions.
•Web Browser: Users will interact with the system through a standard web browser (e.g., Chrome, Firefox, Safari).
2.2 Product Functions
This subsection provides a high-level summary of the main functions that the system will perform.
The Library Management System will provide the following key functions:
•Resource Cataloging: Allow librarians to add, update, and manage the library's collection of resources.
•Member Management: Enable the registration, updating, and management of library member information.
•Circulation Control: Facilitate the borrowing, returning, and renewing of library resources.
•Reporting: Generate reports on various aspects of library operations, such as inventory, circulation, and member
activity.
•System Administration: Provide tools for system configuration, user management, and security.
2.3 User Characteristics
This subsection describes the different types of users who will interact with the system and their relevant
characteristics.
The primary users of the Library Management System will be:
•Librarians: These users will be responsible for managing the library's collection, member accounts, and
circulation. They are expected to be proficient in library operations and may have varying levels of computer
literacy.
•Library Members: These users will primarily search for resources, borrow and return materials, and manage their
own accounts. They are expected to have basic computer literacy and web browsing skills.
•System Administrators: These users will be responsible for the overall maintenance and configuration of the
system, including user access control, backups, and updates. They are expected to have technical expertise in
system administration.
2.4 Constraints
This subsection describes any limitations or constraints that may affect the development of the system.
The development of the Library Management System will be subject to the following constraints:
•Budget: The project must be completed within the allocated budget.
•Timeline: The system must be delivered within the specified timeframe.
•Technology: The system must be developed using the specified technologies (e.g., programming languages,
database management system).
•Standards: The system must comply with relevant library standards (e.g., MARC) and accessibility guidelines.
•Security: The system must adhere to security standards to protect sensitive data.
2.5 Assumptions and Dependencies
This subsection describes any assumptions that are being made about the project and any dependencies on external
factors.
The following assumptions and dependencies apply to the development of the Library Management System:
•The library has a stable internet connection.
•The library staff will be trained on how to use the new system.
•The database server and other necessary hardware will be available.
•The selected open source software components will remain available and supported.
3.1 User Interfaces
This subsection describes the characteristics of the interfaces through which users will interact with the system.
The Library Management System will provide a web-based user interface (UI) accessible through standard web
browsers. The UI will be designed to be:
•Intuitive and user-friendly: Easy to navigate and use for both librarians and library members with varying levels
of computer literacy.
•Consistent: Maintain a consistent look and feel across all pages and functionalities.
•Responsive: Adapt to different screen sizes and devices (desktops, laptops, tablets, and smartphones).
•Accessible: Comply with accessibility guidelines (e.g., WCAG) to ensure usability for users with disabilities.
The UI will include the following key elements:
•Navigation: A clear and consistent navigation menu to access different sections of the system.
•Search Functionality: A prominent search bar to allow users to search for resources in the library catalog.
•Forms: User-friendly forms for data entry (e.g., member registration, resource cataloging).
•Display of Information: Clear and organized display of resource details, member information, and other relevant
data.
•Reporting Interface: Tools for generating and viewing reports.
3.2 Hardware Interfaces
This subsection describes the hardware interfaces that the system will require.
The Library Management System will primarily interact with the following hardware:
•Server: A server to host the application and database. The server hardware requirements (e.g., processing power,
memory, storage) will depend on the expected load and performance requirements of the system.
•Client Devices: Standard desktop computers, laptops, tablets, and smartphones used by librarians and library
members to access the system through a web browser.
•Barcode Scanners: (Optional) Barcode scanners may be used by librarians for efficient check-in/check-out of
resources.
•Printers: Printers for generating reports, receipts, and other documents.
3.3 Software Interfaces
This subsection describes the software interfaces that the system will have with other software systems.
The Library Management System will interact with the following software components:
•Operating System: The server will require a stable operating system (e.g., Linux, Windows Server).
•Database Management System (DBMS): The system will use a DBMS (e.g., MySQL, PostgreSQL) to store and
retrieve data.
•Web Server: A web server (e.g., Apache, Nginx) will be used to host the web application.
•Programming Languages and Frameworks: The system will be developed using specific programming
languages (e.g., Python, PHP, Java) and frameworks (e.g., Django, Laravel, Spring).
•Web Browsers: Users will access the system through standard web browsers (e.g., Chrome, Firefox, Safari).
3.4 Communications Interfaces
This subsection describes the communication interfaces that the system will use.
The Library Management System will use the following communication interfaces:
•Network: The system will operate over a local area network (LAN) or a wide area network (WAN), such as the
internet.
•Protocols: The system will use standard network protocols, such as TCP/IP, HTTP, and HTTPS, for
communication.
[Link] Featureas
4.1 Core Features
4.1.1 Catalog Management
•Add Resource: The system shall allow librarians to add new resources to the catalog, including books,
journals, audio-visual materials, and other types of media.
•Update Resource: The system shall allow librarians to modify existing resource information, such as title,
author, ISBN, publication date, and physical location.
•Delete Resource: The system shall allow librarians to remove resources from the catalog.
•Search Resource: The system shall allow users to search for resources by title, author, subject, ISBN, and
other relevant criteria.
•Browse Resource: The system shall allow users to browse resources by category, genre, and other
classifications.
4.1.2 Member Management
•Register Member: The system shall allow new members to register and create accounts.
•Update Member: The system shall allow librarians to update member information, such as contact details,
address, and membership status.
•Manage Member Account: The system shall allow members to view and manage their account information,
including personal details, borrowing history, and fines.
•Member Categories: The system shall support different member categories, such as student, faculty, and
visitor, each with specific privileges.
4.1.3 Circulation Management
•Borrow Resource: The system shall allow librarians to issue resources to members.
•Return Resource: The system shall allow librarians to record the return of resources from members.
•Renew Resource: The system shall allow members to renew borrowed resources, subject to library policies.
•Hold/Reserve Resource: The system shall allow members to place holds on resources that are currently
checked out.
•Fine Management: The system shall calculate and track fines for overdue resources.
4.1.4 Reporting
•Generate Reports: The system shall allow librarians to generate reports on various aspects of library
operations, including:
• Resource Inventory Reports
• Circulation Reports
• Member Reports
• Overdue Reports
• System Activity Logs
4.2 User Interface Features
•Intuitive Navigation: The system shall provide a clear and consistent navigation menu to allow users to easily
access different sections of the system.
•Responsive Design: The system shall be designed to be responsive and adapt to different screen sizes and
devices, including desktops, laptops, tablets, and smartphones.
•Accessible Design: The system shall comply with accessibility guidelines (e.g., WCAG) to ensure usability
for users with disabilities.
•Search Functionality: The system shall provide a prominent search bar on all relevant pages.
•Forms: The system shall use user-friendly forms for data entry, such as member registration and resource
cataloging.
•Information Display: The system shall display information in a clear and organized manner.
4.3 System Administration Features
•User Role Management: The system shall allow system administrators to manage user roles and permissions.
•System Configuration: The system shall allow system administrators to configure system settings, such as
library policies, loan periods, and fine amounts.
•Backup and Recovery: The system shall provide mechanisms for backing up and restoring system data.
•Security Management: The system shall provide security features to protect sensitive data and prevent
unauthorized access.
[Link] Non Requirements
Performance Requirements
• The system should be responsive and provide quick search results.
• The system should be able to handle a large number of concurrent users.
• Report generation should be efficient.
Software System Attributes
• Reliability
• The system should be reliable and minimize data loss.
• The database should be backed up regularly.
• Availability
• The system should be available during library operating hours.
• Downtime for maintenance should be minimized.
• Security
• The system should protect member data and prevent unauthorized access.
• Librarian and administrator accounts should be password-protected.
• Maintainability
• The system should be designed to be easily modified and updated.
• The code should be well-documented.
Business Rules
• Define rules for borrowing limits, loan periods, fines, and renewals.
• These rules should be configurable by library administrators.
Other Requirements
• The system should support multiple languages.
[Link] A: Glossary
• Cataloging: The process of describing library resources.
• Circulation: The process of lending and returning library resources.
This SRS provides a detailed description of the requirements for the Library Management System.
It should serve as a guide for the design and development of the system.
EXCERCISE NO. 3

Entity-Relationship Diagram:
The diagram represents an Entity-Relationship Diagram (ERD) for a Library Management System. ERDs are
used to illustrate the relationships between different entities (tables) in a database. This diagram helps in
understanding how data is organized within the library system.
Entities and Attributes
•Staff:
• Attributes: Staff_id, name
•Authentication system:
• Attributes: Password, LoginId
•Publisher:
• Attributes: Publisher_id, name, YearOfPublication
•Readers:
• Attributes: User_ID, Firstname, name, lastName, Phone no, Address, Email
•Books:
• Attributes: ISBN, Title, Edition, Category, Price, AuthNo, Due date
•Reports:
• Attributes: User_id, Reg_no, Book_No, Issue/Return, return date, ReserveDate
Relationships
•Staff manages Reports
•Staff login to Authentication system
•Staff maintains Books
•Publisher publishes Books
•Readers reserve/return Books
Observations and Potential Issues
[Link] Names:
1. "Readers" might be better named "Library_Members" for clarity and consistency.
[Link] Entities/Relationships:
1. Borrowing/Loan Entity: A separate entity to track the borrowing of books (who borrowed which
book and when) seems to be missing. This is usually a central part of a library system. The current
diagram uses “Issue/Return” in “Reports” which is not ideal.
2. Author Entity: The diagram does not show how authors are related to books.
[Link] Placement:
1. Some attributes might be better placed in other entities. For example, "Due date" might be more
relevant to a "Borrowing" entity (if one existed) rather than directly in the "Books" entity.
2. “YearOfPublication” in Publisher is better placed in Book entity.
[Link] Clarity:
1. The relationship between "Staff" and "Readers" could be clearer. It seems like "Keeps track of" is
intended, but the cardinality (the number of instances of one entity related to another) is not explicitly
defined.
2. The relationship between “Authentication system” and “Staff” can be named as “Grants Access”
[Link] Entity:
1. The "Reports" entity seems to be capturing a mix of information. It might be better to have separate
entities or relationships to represent borrowing/returning transactions and general reports. Also,
User_id, Reg_no and Book_No are unclear.
Cardinality
•Cardinality (the numbers like 1, N, M) shows how many instances of one entity relate to another. For example,
"1 Staff manages N Reports" means one staff member can manage many reports.
•The cardinality seems to be used, but a more standard notation (like Crow's Foot) would improve readability.
EXERCISE NO. 4

[Link] 0 DFD:-

t 0.0

Books Request
Student Library
Information Demanded Display of
Library card Book info Books
System

Books

[Link] 1 DFD:-
[Link] 2 DFD:-

1.1
Book request

Student Get Book Book shelve

Book

Shelve number
and book info.

1.2 List of authors

Find book
position

List of titles

Books titles

1.3

Updated list of List of borrowed books

borrowed books

Display of book

Level 2 DFD
EXERCISE NO. 5

Use Case Diagrams for Library management system:-

The diagram illustrates the interactions between different actors (users) and the system (Library Management
System) through use cases (functions). It shows who can do what within the system.
Actors
•User: This is a general actor that represents anyone who interacts with the library system.
•Student: A specific type of user, likely with student-specific library privileges.
•Staff: Library staff members who manage the system.
•Libraries: This seems to represent the library system itself, or possibly an external system that interacts with the
library system.
•Library Database: This represents the database where the library's data is stored.
Use Cases
Use cases are actions or functions that actors can perform within the system.
•Authenticate: Users/Staff logs into the system.
•Requests new book: User requests the library to procure a new book.
•Reserve a book: User reserves a book.
•Renew a book: User renews the borrowed book.
•Pays fine: User pays fine for overdue books.
•Feedback: User provides feedback.
•Filling up feedback form: User fills up a feedback form.
•Register New user: Staff registers a new user.
•Fill up Registration form: User fills the registration form.
•Get Library card ID: Staff provides Library card ID to user.
•Add record: Libraries add record.
•Search and update database: Libraries search and update the database.
•Delete book record: Libraries delete book record.
•Update book record: Libraries update book record.
•Update the record ID: Libraries update the record ID.
•Prepare Library database: Libraries prepare the library database.
Interpretation
•The diagram shows that both students and staff can authenticate, reserve/renew books, pays fines, and provide
feedback.
•Staff is responsible for registering new users and providing them with library card IDs.
•The "Libraries" actor performs database management functions such as adding, searching, updating, and deleting
records.
•The "Library database" is involved in preparing and storing library data.
EXERCISE NO. 6

ACTIVITY DIAGRAM FOR LIBRARIAN:

This activity diagram illustrates the flow of activities involved in managing a Library Management System,
specifically from the Librarian's perspective. It shows the sequence of actions and decisions taken to perform
various tasks.
Actors and Components
•Librarian: The actor who initiates and performs various actions.
•Library Management System: The system that responds to the Librarian's actions and performs automated
tasks.
Activities
The diagram outlines the following activities:
[Link]: The beginning of the process.
[Link] Log-in Form: The system displays the log-in form to the Librarian.
[Link] Username & Password Inputs: The Librarian enters their username and password.
[Link] Input?: The system checks if the entered login credentials are valid.
1. No: If the input is invalid, the flow goes back to "Encode Username & Password Inputs" to allow the
Librarian to re-enter the credentials.
2. Yes: If the input is valid, the flow proceeds to the next activity.
[Link] Dashboard: The system displays the dashboard, providing an overview of the system's functionalities.
[Link] New Book Information: The Librarian adds information about a new book to the system.
[Link]-up New Data: The system saves the new book information into the database.
[Link] Book Information: The Librarian modifies existing book information.
[Link]-up Book Modifications: The system saves the changes made to the book information.
[Link] New User/Student: The Librarian adds a new user or student to the system.
[Link]-up New User/Student: The system saves the new user/student information.
[Link] User/Student: The Librarian modifies existing user/student information.
[Link]-up Modification of User/Student: The system saves the changes made to the user/student information.
[Link] for Activity Reports: The Librarian requests activity reports from the system.
[Link] and Display Reports: The system generates the requested reports and displays them to the Librarian.
[Link]: The end of the process.
Flow of Activities
The diagram shows the sequential flow of activities, starting with the Librarian logging in, followed by a decision
point to validate the login credentials. Upon successful login, the Librarian can perform various tasks such as
adding/modifying book and user/student information, and requesting activity reports. The system responds by
saving the data or generating the reports accordingly.
ACTIVITY DIAGRAM FOR USER:-
This activity diagram illustrates the process of a student borrowing a book from the Library Management
System. It describes the sequence of actions and decisions involved from the student's perspective.
Actors and Components
•Student: The actor who initiates the process of borrowing a book.
•Library Management System: The system that interacts with the student and manages the book borrowing
process.
Activities
The diagram outlines the following activities:
[Link]: The beginning of the process.
[Link] Log-in Form: The system displays the log-in form to the student.
[Link] Username & Password Inputs: The student enters their username and password.
[Link] Input?: The system checks if the entered login credentials are valid.
1. No: If the input is invalid, the flow goes back to "Encode Username & Password Inputs," and the
student is prompted to re-enter their credentials.
2. Yes: If the input is valid, the flow proceeds to the next activity.
[Link] Books: The system displays the list of available books to the student.
[Link] for Book: The student searches for a specific book.
[Link] for Borrowing: The student requests to borrow the selected book.
[Link] Available?: The system checks if the requested book is available for borrowing.
1. No: If the book is not available, the system displays the message "Sorry, it's not available."
2. Yes: If the book is available, the flow proceeds to the next activity.
[Link] Book: The system releases the book (i.e., updates its status as borrowed).
[Link] the Book: The student gets the book.
[Link]: The end of the process.
Flow of Activities
The diagram shows the step-by-step process of a student borrowing a book:
[Link] process starts with the student logging into the system.
[Link] system validates the student's login credentials.
[Link] successful login, the student can search for a book.
[Link] student requests to borrow a book.
[Link] system checks the book's availability.
[Link] the book is available, the system releases it, and the student gets the book.
[Link] process ends.
EXERCISE NO. 7

STATE CHART DIAGRAM:-

This state chart diagram illustrates the various states a book goes through in a Library Management System,
specifically focusing on the process of a student/faculty member borrowing and returning a book.
States
The diagram depicts the following states:
•Start: The initial state.
•Student/faculty login: The state where a student or faculty member logs into the system.
•Search book: The state where the user searches for a book.
•Found book: The state where the user has found the desired book.
•Request book: The state where the user requests the book.
•Receive book: The state where the user receives the book.
•Return back book: The state where the user returns the book.
•Return book and pay fine (if any): The state where the user returns the book and pays any applicable fines.
•Pay the fine: A sub-state within "Return book and pay fine (if any)," specifically for the action of paying the
fine.
•Profile update and sighnout: The state where the user updates their profile (if needed) and signs out of the
system.
•Stop: The final state.
Transitions
The arrows in the diagram represent transitions between states, triggered by certain events or actions:
•Start to Student/faculty login: The process begins with the user logging in.
•Student/faculty login to Search book: After logging in, the user can search for a book.
•Search book to Found book: The user finds the book they were looking for.
•Found book to Request book: The user requests the book.
•Request book to Receive book: The user receives the book from the librarian.
•Receive book to Return back book: The user returns the book.
•Return back book to Return book and pay fine (if any): The user initiates the return process.
•Return book and pay fine (if any) to Pay the fine: If a fine is due, the user pays it.
•Return book and pay fine (if any) to Profile update and signout: After returning the book (and paying any
fines), the user can update their profile and sign out.
•Profile update and signout to Stop: The user signs out, and the process ends.
Interpretation
This diagram illustrates the typical lifecycle of a book being borrowed and returned in a library system:
1.A student or faculty member logs in.
[Link] search for a book.
[Link] found, they request it.
[Link] receive the book.
[Link] return the book.
[Link] there are fines, they pay them.
[Link], they can update their profile and sign out.
EXERCISE NO. 8

Sequence diagram for Library Management System:-

This sequence diagram illustrates the interactions between different objects or entities in a Library Management
System during a transaction, likely the process of a member taking a book. It shows the sequence of messages
exchanged between these objects to complete the transaction.
Objects/Entities
•Librarian: Represents the librarian who initiates and manages the transaction.
•Book: Represents the book being taken.
•Member: Represents the library member involved in the transaction.
•Transaction Record: Represents the record of the transaction (e.g., borrowing details).
•Bill: Represents the bill generated for the transaction, possibly including fines.
Messages (Sequence of Actions)
The numbers on the arrows indicate the sequence of messages:
[Link] member: The Librarian sends a message to the Member to validate their membership.
[Link] issue detail: The Librarian sends a message to the Book to get the issue details.
[Link] member type: The Librarian sends a message to the Member to retrieve the member's type (e.g., student,
faculty).
4.<>: A Transaction Record object is created.
[Link] fine: The Librarian calculates any fines that may be applicable (e.g., overdue fines).
[Link] fine and member details: The Librarian adds the fine amount and member details to the Transaction
Record.
[Link] paid: The Member pays the fine (if any).
[Link] book status: The Librarian sends a message to the Book to update its status (e.g., marked as
"borrowed").
[Link] member record: The Librarian sends a message to the Member Record to update the member's record
(e.g., record the borrowing).
Interpretation
The diagram shows the following sequence of events:
[Link] Librarian starts by validating the member.
[Link] Librarian gets the issue details from the Book.
[Link] Librarian retrieves the member's type.
4.A Transaction Record is created.
[Link] Librarian calculates any fines.
[Link] fine and member details are added to the Transaction Record.
[Link] Member pays the fine.
[Link] Book's status is updated.
[Link] Member's record is updated.
EXERCISE NO. 9

Collaboration Diagram For Library Management System:-

This collaboration diagram illustrates the interactions between different objects or entities in a Library
Management System during a transaction, likely the process of a member taking a book. It shows how these
objects interact to complete the transaction.
Objects/Entities
•Librarian: Represents the librarian who initiates and manages the transaction.
•Book: Represents the book being taken.
•Member: Represents the library member involved in the transaction.
•Transaction Record: Represents the record of the transaction (e.g., borrowing details).
•Bill: Represents the bill generated for the transaction, possibly including fines.
Interactions (Messages)
The numbered arrows indicate the sequence of interactions:
[Link] member: The Librarian sends a message to the Member to validate their membership.
[Link] issue detail: The Librarian sends a message to the Book to get the issue details.
[Link] member type: The Librarian sends a message to the Member to retrieve the member's type (e.g., student,
faculty).
[Link] fine: The Librarian calculates any fines that may be applicable (e.g., overdue fines).
[Link] fine and member details: The Librarian adds the fine amount and member details to the Transaction
Record.
[Link] paid: The Member pays the fine (if any).
[Link] book status: The Librarian sends a message to the Book to update its status (e.g., marked as
"borrowed").
[Link] member record: The Librarian sends a message to the Member Record to update the member's record
(e.g., record the borrowing).
Interpretation
The diagram illustrates the sequence of events during a book transaction:
[Link] Librarian starts by validating the member's membership.
[Link] Librarian gets the issue details from the Book.
[Link] Librarian retrieves the member's type.
4.A Transaction Record object is created to store transaction details.
[Link] Librarian calculates any applicable fines.
[Link] fine amount and member details are added to the Transaction Record.
[Link] Member pays the fine, if any.
[Link] Book's status is updated to reflect the transaction (e.g., "borrowed").
[Link] Member's record is updated to log the transaction.
EXERCISE NO. 10

Class Diagram Of Library Management System:-

This class diagram represents the static structure of a Library Management System. It shows the
classes, their attributes, and the relationships between them.
Classes and Attributes
•Book
• Attributes: bookId, author, name, price, rackNo, status, edition, dateOfPurchase
• Operations: displayBookDetails(), updateStatus()
•Librarian
• Attributes: name, password
• Operations: searchBook(), verifyMember(), issueBook(), calculateFine(), createBill(),
returnBook()
•Transaction
• Attributes: transId, memberId, bookId, dateOfIssue, dueDate
• Operations: createTransaction(), deleteTransaction(), retrieveTransaction()
•MemberRecord
• Attributes: memberId, type, dateOfMembership, noBookIssued, maxBookLimit, name,
address, phoneNo
• Operations: retriveMember(), increaseBookIssued(), decreaseBookIssued(), payBill()
•Bill
• Attributes: billNo, date, memberId, amount
• Operations: billCreate(), billUpdate()
•Journals
• Inherits from: Book
•StudyBooks
• Inherits from: Book
•Magazines
• Inherits from: Book
•Student
• Inherits from: MemberRecord
•Faculty
• Inherits from: MemberRecord
Relationships
•Librarian issues Book: The Librarian class has an association with the Book class, indicating that
librarians can issue books.
•Librarian creates Transaction: The Librarian class has an association with the Transaction class,
showing that librarians create transaction records.
•Transaction refers MemberRecord: The Transaction class has an association with the
MemberRecord class, indicating that a transaction is related to a member's record.
•Transaction refers Book: The Transaction class has an association with the Book class, indicating
that a transaction is related to a book.
•MemberRecord pays Bill: The MemberRecord class has an association with the Bill class, showing
that members pay bills.
•Book has subclasses Journals, StudyBooks, Magazines: The diagram shows inheritance
relationships, indicating that Journals, StudyBooks, and Magazines are specialized types of Books.
•MemberRecord has subclasses Student, Faculty: The diagram shows inheritance relationships,
indicating that Student and Faculty are specialized types of MemberRecords.
Interpretation
•The diagram shows the essential classes for a Library Management System.
•The Book class contains information about books, and its subclasses (Journals, StudyBooks, and
Magazines) represent different types of books.
•The Librarian class manages book transactions, member records, and bills.
•The MemberRecord class stores information about library members, and its subclasses (Student and
Faculty) may have specific attributes or behaviors.
•The Transaction class records the details of each book transaction.
•The Bill class manages billing information.