Library Management System

Software Design Specification (SDS)

Software Design & Analysis

Submitted By
Ariza Iqbal — 24K-0854
Fatima Salman — 24K-1021
Table of Contents
Chapter 1: Introduction ........................................................................................................... 3
1.1 System Overview ................................................................................................................................................3
1.2 Problem Statement .............................................................................................................................................3
1.3 Scope .................................................................................................................................................................3
1.4 Objectives ...........................................................................................................................................................4
1.5 Users and Stakeholders......................................................................................................................................4
Direct Users...........................................................................................................................................................4
Indirect Stakeholders .............................................................................................................................................4
1.6 System Requirements Summary ........................................................................................................................5
Functional Requirements.......................................................................................................................................5
Non-Functional Requirements ...............................................................................................................................5
1.7 Software Process Model .....................................................................................................................................5
Model Description ..................................................................................................................................................5
Rationale for Adoption ...........................................................................................................................................5
Chapter 2: System Analysis and Modeling ............................................................................ 7
2.1 Use Case Diagram .............................................................................................................................................7
a. Main Actors and System Functions ..................................................................................................................7
b. Relationships ....................................................................................................................................................7
c. Use Case Description Table .............................................................................................................................8
2.2 Class Diagram ....................................................................................................................................................9
a. Classes, Attributes, Methods, and Relationships .............................................................................................9
b. BCE Model — Boundary, Control, and Entity Classes ................................................................................... 10
2.3 Activity Diagrams .............................................................................................................................................. 11
a. Major Workflows Modeled .............................................................................................................................. 11
b. Decisions, Concurrency, and Swimlanes ....................................................................................................... 11
2.3.1 Issue Book Workflow ................................................................................................................................. 11
2.3.2 Return Book Workflow ............................................................................................................................... 13
2.4 Sequence Diagrams ......................................................................................................................................... 15
a. Object Interaction for Key Use Cases............................................................................................................. 15
2.4.1 Issuing a Book ........................................................................................................................................... 15
2.4.2 Returning a Book ....................................................................................................................................... 17
2.5 Component Diagram ......................................................................................................................................... 17
2.6 Deployment Diagram: ........................................................................................................................................ 18
Architectural View: The 4+1 Model ........................................................................................20
1. Logical View........................................................................................................................................................ 20
2. Process View ...................................................................................................................................................... 20
3. Development View .............................................................................................................................................. 20
4. Physical View...................................................................................................................................................... 21
5. Use Case View (+1) ............................................................................................................................................ 21
References ..............................................................................................................................22
Chapter 1: Introduction
This chapter provides an overview of the Library Management System (LMS), establishing the
context, motivation, and scope of the project. It outlines the problem being addressed, the
objectives the system aims to achieve, the stakeholders involved, and the software process model
adopted for development.

1.1 System Overview

The Library Management System (LMS) is a software platform designed to automate and
streamline the operations of a library environment. It serves as a centralized system through
which librarians can manage the book inventory, process member requests, track issuance and
return transactions, and generate bills for overdue items.
Members — categorized as Students or Faculty — can use the system to search for books, submit
borrow requests, and view their borrowing history and billing status. The system differentiates
between two types of books: GeneralBooks, which are available for borrowing, and
ReferenceBooks, which are restricted to in-library use only.
The LMS is built on object-oriented design principles, including encapsulation, inheritance, and
abstraction, and is modeled using the Unified Modeling Language (UML).

1.2 Problem Statement

Traditional library management relies on manual processes — paper-based records, physical
registers, and face-to-face interactions — to handle book issuance, member registration,
transaction tracking, and fine collection. These methods are prone to errors, inefficiencies, and
delays, particularly in institutions with large inventories and high member volumes.
Specific challenges include:
• Difficulty tracking real-time book availability across large inventories.
• Manual calculation and collection of overdue fines, which is time-consuming and error-
prone.
• Lack of a structured audit trail for all borrowing and return transactions.
• Inability to differentiate between member types (Student vs. Faculty) and enforce
borrowing privileges automatically.
• No centralized system for managing both general circulation and reference book
collections.
The LMS addresses these challenges by providing a structured, automated platform that
manages all library operations digitally, enforces business rules programmatically, and maintains
a complete and accurate record of all system activity.

1.3 Scope
The LMS covers the following functional areas:
 • Book Management: Adding, removing, updating, and categorizing books into
GeneralBook and ReferenceBook types. Managing a separate BookBank for extended-
loan items.
• Member Management: Registering members as Student or Faculty, with differentiated
borrowing limits and loan durations.
• Transaction Management: Recording all book issuance and return events with a
complete audit trail.
• Billing and Fine Management: Automatically calculating overdue fines, generating Bill
records, and tracking payment status.
• Librarian Operations: Enabling the Librarian to oversee all system operations, approve
requests, process returns, and maintain inventory.
Out of scope: online/digital book lending, integration with external library networks, payment
gateway integration, and mobile application interface.

1.4 Objectives
• To manage book records efficiently, including addition, deletion, and categorization into
general and reference types.
• To allow student and faculty members to request, borrow, and return books per their
respective privileges.
• To automate transaction recording for all issuance and return operations, maintaining a
full history.
• To generate and manage billing for overdue fines and special charges, reducing manual
effort and errors.
• To differentiate between member types and enforce corresponding borrowing rules
automatically.
• To provide librarians with a centralized interface for managing all library operations.
• To demonstrate object-oriented design principles through a well-structured UML-
modeled system.

1.5 Users and Stakeholders

Direct Users
• Librarian: Primary system administrator. Manages inventory, processes borrow/return
requests, handles billing, and monitors all activity. Has full system access.
• Student (Member subtype): Can search and borrow GeneralBooks within student limits
(fewer books, shorter loan duration). Can view own transaction history and billing.
• Faculty (Member subtype): Elevated borrowing privileges — higher borrowing limit and
extended loan duration. May also access the BookBank for longer-term loans.

Indirect Stakeholders
• Library Administration: Interested in efficiency, accuracy, and reporting capabilities.
• IT / Development Team: Responsible for implementation, maintenance, and extension.
• Institution / University Management: Benefits from an automated, auditable library
system supporting academic operations.
1.6 System Requirements Summary
Functional Requirements
• The system shall allow the Librarian to add, update, and remove books from inventory.
• The system shall differentiate between GeneralBooks (borrowable) and ReferenceBooks
(in-library use only).
• The system shall register members as either Student or Faculty and enforce appropriate
borrowing rules.
• The system shall record a Transaction for every book issuance and return, capturing all
relevant dates and parties.
• The system shall calculate overdue fines automatically upon late return.
• The system shall generate a Bill record for any applicable fine and track its payment
status.
• The system shall maintain a BookBank for longer-term book loans.
• The system shall provide the Librarian with a view of all active transactions and overdue
items.

Non-Functional Requirements
• Usability: Intuitive interface for Librarians and Members, minimizing training
requirements.
• Reliability: Maintain data integrity across all transaction operations; prevent double-
issuance of books.
• Maintainability: OOP principles ensure new book types or member categories can be
added without modifying existing core logic.
• Performance: Process borrow and return transactions without perceptible delay under
normal conditions.
• Security: Member data and transaction records accessible only to authorized users.

1.7 Software Process Model

The Library Management System adopts the Iterative and Incremental Development model as its
SDLC process.

Model Description
The Iterative and Incremental model divides development into a series of short repeated cycles.
In each iteration, a subset of requirements is analyzed, designed, implemented, and tested,
producing a working partial version of the system. Functionality grows with each iteration until the
complete product is delivered.

Rationale for Adoption

• Manageable Complexity: Multiple interconnected subsystems (book management,
transactions, billing) can be designed and validated independently before integration.
• Early Feedback and Validation: Each iteration produces a working increment that can be
reviewed against requirements progressively rather than only at project end.
• Flexibility for Refinement: Fine-grained details (borrowing limits, fine formulas) can be
refined as design progresses, which the iterative model accommodates naturally.
 • Alignment with UML-Based Design: The 4+1 View Model aligns well with iterative
development, as each architectural view can be elaborated progressively across
iterations.
Planned iterations:
• Iteration 1: Requirements analysis, use case identification, Use Case and Class Diagram
development.
• Iteration 2: Activity diagrams for core workflows, sequence diagram development,
detailed class modeling.
• Iteration 3: Component and deployment modeling, 4+1 architectural view elaboration,
and full SDS documentation.
Chapter 2: System Analysis and Modeling
This chapter presents the UML diagrams that model the behavior and structure of the Library
Management System. Each diagram captures a different perspective — from high-level actor
interactions to detailed object-level communication — providing a comprehensive design
blueprint.

2.1 Use Case Diagram

a. Main Actors and System Functions
The LMS has two primary actors:
• Member (Student / Faculty): Interacts with the system to borrow books, return books,
and view transaction and billing history. Faculty members have extended borrowing
privileges compared to Students.
• Librarian: Manages the complete library lifecycle — registering members, managing
book inventory, approving and processing borrow/return requests, and overseeing
billing.
Core system functions (use cases) include: Borrow Book, Return Book, Manage Inventory,
Generate Bill, View Transactions, and Register Member.

b. Relationships
• <<include>>: Borrow Book includes Check Availability and Verify Member — these sub-
flows are mandatory and always executed as part of the borrow process.
• <<include>>: Return Book includes Calculate Fine — fine calculation is always triggered
on return to check for overdue status.
• <<extend>>: Generate Bill extends Return Book — a Bill is only created when an
overdue fine is applicable, making this an optional extension of the return flow.
 Figure 2.1 – Use Case Diagram

c. Use Case Description Table

Use Case Actor(s) Description Relationships

Member requests a book; Librarian verifies <<include>> Check

Member,
Borrow Book eligibility and availability, then issues the Availability <<include>>
Librarian
book and records a Transaction. Verify Member

Member returns a borrowed book;

<<include>> Calculate
Member, Librarian logs the return; system calculates
Return Book Fine <<include>>
Librarian any overdue fine and generates a Bill if
Generate Bill
applicable.

Manage Librarian adds, updates, or removes book

Librarian —
Inventory records from the system, including
 categorization as GeneralBook or
ReferenceBook.

System automatically creates a Bill record

Librarian,
Generate Bill when an overdue fine is calculated upon <<extend>> Return Book
System
book return.

Users view the history of borrow and return

View Member,
transactions. Members see only their own; —
Transactions Librarian
Librarians see all.

Librarian registers a new Member in the

Register
Librarian system, assigning them a type (Student or —
Member
Faculty) and setting borrowing privileges.

2.2 Class Diagram

a. Classes, Attributes, Methods, and Relationships
The class diagram models the static structure of the LMS. Key classes and their characteristics
are:
• Book (abstract): Attributes — bookID, title, author, category, isAvailable. Methods —
getDetails(), updateStatus(). Subclasses: GeneralBook (adds loanDuration,
borrowingLimit) and ReferenceBook (restricted to in-library use, no borrow methods).
• Member (abstract): Attributes — memberID, name, contactInfo. Methods —
requestBook(), viewHistory(). Subclasses: Student (standard limits) and Faculty
(extended limits, BookBank access).
• Librarian: Attributes — librarianID, name. Methods — addBook(), removeBook(),
issueBook(), processReturn(), manageBilling().
• Transaction: Attributes — transactionID, issueDate, dueDate, returnDate. Methods —
recordIssue(), recordReturn(), getStatus(). Associated with one Member and one Book.
• Bill: Attributes — billID, fineAmount, isPaid. Methods — calculateFine(), markPaid().
Composed within a Transaction.
• BookBank: Attributes — bankID, bookList. Methods — addBook(), removeBook(),
getAvailableBooks(). Aggregates multiple Book instances.
Relationships present in the diagram:

Relationship Between Description

Book → GeneralBook, Subclasses specialize the abstract base

Inheritance ReferenceBook Member → Student, class, inheriting shared attributes and
Faculty methods.

Librarian ↔ Book Member ↔ Librarian manages Books; Members are

Association
Transaction linked to their Transactions.
 A Bill is created as part of a Transaction and
Composition Transaction → Bill
cannot exist independently.

BookBank holds a collection of Books but

Aggregation BookBank → Book
does not exclusively own them.

b. BCE Model — Boundary, Control, and Entity Classes

The diagram applies the Boundary-Control-Entity (BCE) architectural pattern to organize classes
by responsibility:

Class
Classes Role
Type

Handle user input/output; the

Boundary MemberInterface, LibrarianInterface interface between actors and the
system.

Coordinate business logic; mediate

BookManager, TransactionManager,
Control between boundary and entity
BillingManager
classes.

Book, GeneralBook, ReferenceBook, Member, Represent persistent domain data;

Entity Student, Faculty, Librarian, Transaction, Bill, encapsulate attributes and access
BookBank methods.
 Figure 2.2 – Class Diagram

2.3 Activity Diagrams

a. Major Workflows Modeled
Two primary workflows are modeled: the Book Issuance workflow and the Book Return workflow.
These cover the core transactional operations of the LMS and represent the most frequent and
consequential interactions in the system.

b. Decisions, Concurrency, and Swimlanes

Both diagrams use three swimlanes — Member, Librarian, and System — to clearly assign
responsibility for each action. Decision nodes handle conditional logic (e.g., "Is book available?",
"Is member eligible?", "Is book overdue?"). Concurrency is shown in the Return workflow, where
fine computation and inventory status update can proceed in parallel once the return event is
logged.

2.3.1 Issue Book Workflow

The Member submits a borrow request. The Librarian checks the member's eligibility and the
book's availability. If both conditions are met, the System creates a Transaction record, updates
the book status to "Issued," and notifies the Member. If either check fails, the request is rejected
with an appropriate reason.
 Figure 2.3.1 – Activity Diagram: Issue Book

2.3.2 Return Book Workflow

The Member submits the book for return. The Librarian logs the return and the System retrieves
the associated Transaction. A decision node checks whether the book is overdue — if yes, fine
calculation and Bill generation are triggered; if no, the flow proceeds directly. The book status is
then updated to "Available" and the Transaction is closed.
 Figure 2.3.2 – Activity Diagram: Return Book

2.4 Sequence Diagrams

a. Object Interaction for Key Use Cases
The sequence diagrams illustrate how objects interact in a time-ordered manner for the two most
critical use cases. Lifelines represent the Member, Librarian, TransactionManager, and Bill
objects. Messages (method calls and returns) are shown chronologically to depict the exact flow
of control between system components.

2.4.1 Issuing a Book

Member requests a book → Librarian calls checkAvailability() on BookManager → BookManager
returns status → Librarian calls issueBook() on TransactionManager → TransactionManager
creates a Transaction, updates Book status → confirmation returned to Librarian and Member.
 Figure 2.4.1 – Sequence Diagram: Issue Book

2.4.2 Returning a Book

Member submits return → Librarian calls processReturn() on TransactionManager →
TransactionManager retrieves Transaction, calls calculateFine() on BillingManager → if overdue,
BillingManager creates Bill → Book status updated to "Available" → Transaction closed →
confirmation returned.

Figure 2.4.2 – Sequence Diagram: Return Book

2.5 Component Diagram

The Component Diagram shows the high-level software components of the LMS and their
interdependencies. Major components include the Member Interface, Librarian Interface, Book
Management Module, Transaction Module, Billing Module, and the Database layer. Components
communicate through defined interfaces, supporting modularity and separation of concerns.
 Figure 2.5 – Component Diagram

2.6 Deployment Diagram:

The Deployment Diagram (Figure 2.6) illustrates the physical architecture of the Library
Management System, showing how software artifacts are mapped to hardware nodes. The
system follows a distributed client-server topology:

• Librarian & Member Nodes: These represent the physical workstations or devices used
by the primary actors. They host the User Interface components, which act as clients to
initiate requests for book searches, issuance, or returns.
• Application Server Node: This central node serves as the primary execution
environment. It hosts the core logic modules identified in the component diagram, such
as the Transaction Manager and Billing Engine. It manages the communication between
the client interfaces and the data persistence layer.
• Database Server Node: A dedicated backend node that hosts the LMS Database. It is
responsible for storing and retrieving persistent data, including book metadata, member
profiles, and historical transaction logs.
• Communication Links: The nodes are interconnected via secure protocols (typically
TCP/IP), ensuring that data is transmitted reliably between the front-end interfaces and
the centralized servers.
Figure 2.6 – Deployment Diagram
Architectural View: The 4+1 Model
The 4+1 Architectural View Model organizes the LMS design into five concurrent views — Logical,
Process, Development, Physical, and the central Use Case view — each addressing the concerns
of a different set of stakeholders. Originally proposed by Philippe Kruchten (1995), this model
ensures the architecture is comprehensive, consistent, and traceable to real user requirements.

1. Logical View
The Logical View addresses functional requirements by describing the system's object model and
key domain abstractions.
• Book (abstract) → GeneralBook (borrowable), ReferenceBook (in-library only).
Attributes: bookID, title, author, category, isAvailable.
• Member (abstract) → Student (standard limits), Faculty (extended limits + BookBank
access). Attributes: memberID, name, contactInfo.
• Librarian: Full system access; manages inventory, transactions, and billing.
• Transaction: Links Member and Book; records issueDate, dueDate, returnDate. Full
audit trail.
• Bill: Composed within Transaction; stores fineAmount and isPaid status.
• BookBank: Aggregates Books for longer-term lending.
Relationships: Inheritance (Book, Member hierarchies); Association (Librarian–Book, Member–
Transaction); Composition (Transaction–Bill); Aggregation (BookBank–Book). Represented by
the Class Diagram (Figure 2.2).

2. Process View
The Process View addresses runtime behavior, concurrency, and control flow.
• Issuance Process: Sequential — eligibility check → availability check → Transaction
creation → Book status update → confirmation.
• Return Process: Parallel-capable — return logged → fine calculation and inventory
update can proceed concurrently → Bill created if overdue → Transaction closed.
• Concurrency concern: Simultaneous borrow requests require transactional integrity to
prevent double-issuance of the same book copy.
Represented by Activity Diagrams (Figures 2.3.1 & 2.3.2) and Sequence Diagrams (Figures 2.4.1
& 2.4.2).

3. Development View
The Development View describes the static module organization of the software.
• UI Layer: MemberInterface, LibrarianInterface — boundary classes handling user
interaction only.
• Business Logic Layer: BookManager, TransactionManager, BillingManager — enforce
all business rules.
• Entity Layer: Book, Member, Transaction, Bill, BookBank — persistent domain objects.
• Database Module: Single point of data access for all persistence operations.
Design principles: Encapsulation (each module hides internals behind a defined interface);
Abstraction (abstract base classes enable extension without modifying existing code); Separation
of Concerns (UI, logic, and data cleanly separated). Represented by the Component Diagram
(Figure 2.5).

4. Physical View
The Physical View maps software components onto hardware infrastructure.
• Client Workstations: Librarian workstation (full access, Librarian Interface); Member
terminals (Member Interface, limited access).
• Application Server: Hosts BookManager, TransactionManager, BillingManager.
Processes all requests; mediates between clients and database.
• Database Server: Stores all persistent records. Accessed only by Application Server —
raw data never exposed to clients.
Three-tier architecture (Presentation – Logic – Data) enables independent scaling of each layer
and clean separation of infrastructure concerns.

5. Use Case View (+1)

The Use Case View is the central unifying perspective that validates all other views. Every
architectural component must be traceable to a user goal.
• Borrow Book → drives Transaction creation (Logical), issuance workflow (Process),
TransactionManager (Development), client-server path (Physical).
• Return Book → drives BillingManager fine logic, return activity workflow, conditional Bill
creation.
• Manage Inventory → drives BookManager CRUD operations on Book entities.
• Generate Bill → drives BillingManager and Bill entity collaboration.
• View Transaction History → drives read-access path across all four views.
Represented by the Use Case Diagram (Figure 2.1), confirming all architectural components
serve identified user goals.
References
• Kruchten, P. (1995). The 4+1 View Model of Architecture. IEEE Software, 12(6), 42–50.
• Booch, G., Rumbaugh, J., & Jacobson, I. (2005). The Unified Modeling Language User
Guide (2nd ed.). Addison-Wesley.
• Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling
Language (3rd ed.). Addison-Wesley.
• Sommerville, I. (2016). Software Engineering (10th ed.). Pearson Education.