NED UNIVERSITY OF ENGINEERING & TECHNOLOGY

Department of Software Engineering

SE-312 Software Construction and Development

Assignment
Summer Session 2026

Name M. Shahzeb Alam

Roll No. SE-23055

Course SCD

Course Code SE-312

Course Teacher Muhammad Faraz

Session Summer 2026

Department of Software Engineering

NED University of Engineering & Technology, Karachi
 Library Management System – SCD Report

Design and Development of a Library Management System Using

Software Construction and Design Principles
Software Construction and Design

Table of Contents
1. Introduction ................................................................................................................................................ 2
2. Task 1 – Requirements Analysis ............................................................................................................... 2
3. Task 2 – Software Architecture ................................................................................................................. 3
Layered Architecture ................................................................................................................................. 3
Architecture Explanation........................................................................................................................... 4
4. Task 3 – Object-Oriented Design Principles and Design Pattern .......................................................... 4
Design Principles ........................................................................................................................................ 4
Recommended Design Pattern: Repository.............................................................................................. 5
5. Task 4 – Coding Standards, Software Quality Metrics, and Testing Strategy ..................................... 6
Coding Standards ....................................................................................................................................... 6
Software Quality Metrics ........................................................................................................................... 6
Testing Strategy .......................................................................................................................................... 6
6. Task 5 – Version Control, CI/CD, and DevOps ....................................................................................... 7
Version Control and Git Workflow .......................................................................................................... 7
CI/CD ........................................................................................................................................................... 7
DevOps Practices ........................................................................................................................................ 7
7. Conclusion ................................................................................................................................................... 8
8. References ................................................................................................................................................... 8

1
 Library Management System – SCD Report

1. Introduction
University libraries handle a steady stream of routine but critical work: cataloguing Books, registering Student
and Faculty Members, issuing and returning Loans, managing a Reservation Queue, and tracking overdue
Fines. When this is done manually, small problems compound quickly — misplaced index cards, delayed fine
calculations, no easy way to check if a Book is available before a Member walks to the shelf, and no reliable
audit trail when a record goes missing. A computerized Library Management System (LMS) removes most
of this friction by centralizing Book, Member, and Loan data and automating the repetitive parts of
circulation.
This report proposes an LMS for a university library, designed by applying Software Construction and Design
principles rather than simply describing an off-the-shelf product. Existing library systems and relevant
software engineering literature were consulted during the design process, but the architecture, design pattern
choices, and workflow decisions presented here are my own. The objective is to produce a system that is
maintainable, testable, and realistic to build and deploy incrementally by a small student team.
The report covers, in order: functional and non-functional requirements, the proposed software architecture,
the object-oriented design principles and pattern used, coding standards and a testing strategy, and the version
control, CI/CD, and DevOps workflow that would support the project.

2. Task 1 – Requirements Analysis

The starting point for this design is a University Library that needs to manage Books, Members, and the day-
to-day process of lending and returning items. Before settling on a design, it was useful to look at how an
existing PHP-based library system handles this same set of problems, since it gives a realistic picture of what
a working system actually needs to support [1]. Based on this and on the assignment's problem statement, the
following functional and non-functional requirements were drawn up.
Functional Requirements
● Catalog Management: A Librarian can add, update, or remove Book records in the Book Catalog,
including title, author, ISBN, category, number of copies, and availability status.
● Member Management: A Librarian can register, update, and deactivate Member accounts,
recording whether a Member is a Student Member, Faculty Member, or guest, and their membership
expiry date.
● Circulation (Loan): A Librarian can issue a Book to a Member, creating a Loan record with an issue
date and due date, and can process a returned Book, closing the Loan and triggering Fine Management
automatically if the item is late.
● Reservation: A Member can place a Book on the Reservation Queue when it is currently on loan,
and is notified once a copy becomes available.
● Fine Management: The system calculates a fine automatically when a Loan is returned after its due
date and tracks whether it has been paid.
● Search and Browsing: A Member or Librarian can search the Book Catalog by title, author, ISBN,
or category.
● Authentication: Librarians and admin users must log in before accessing management functions
through a dedicated admin login screen, consistent with how most existing LMS implementations
handle access control.
● Reporting: The system produces basic management reports, such as most-borrowed Books, currently
overdue Loans, and remaining stock levels.
Non-Functional Requirements
● Usability: the Librarian's dashboard and the Member-facing Catalog search need to stay simple, since
a confusing layout is one of the quickest ways to put users off a library system.
2
 Library Management System – SCD Report

● Security: Librarian credentials must be authenticated on every request, and passwords should never
be stored as plain text — a salted hash such as bcrypt is a reasonable minimum.
● Performance: Catalog searches and Loan transactions should return a result within a few seconds,
even with several library terminals in use at once.
● Reliability and Availability: circulation functions need to stay available throughout library opening
hours and should fail gracefully if the database or network has a problem.
● Maintainability: the system should be structured so new item types, such as e-books or DVDs, or a
future payment-based Fine Management feature, can be added without a major rewrite.
● Data Integrity: Book, Member, and Loan records must stay consistent — a Book marked as available
should never have an open Loan against it at the same time.
These requirements set the scope for the architecture and design decisions that follow.

3. Task 2 – Software Architecture

Layered Architecture

Figure 1. Proposed Layered Architecture of the University Library Management System (Source adapted from [1])

For this system, a standard three-tier architecture was chosen, made up of a Presentation Layer, a Business
(Application) Layer, and a Data Layer [1]. Splitting the system this way keeps each layer independent, so one
part can be changed or tested without touching the others, and each layer maps naturally onto the Book,
Member, Loan, Reservation, and Fine entities the LMS is built around.

3
 Library Management System – SCD Report

Presentation Layer. This is the layer a Librarian or Member actually sees — the Book Catalog search page,
the issue-Book form, the Reservation Queue, and the admin login screen. Its only job is to collect input, such
as a search term, a Member ID, or a Book ISBN, and pass it on to the Business Layer. No circulation or Fine
Management logic sits here.
Business (Application) Layer. This is where the actual rules of the LMS live: a LoanService that issues and
returns Books, a FineCalculator that applies the library's late-fee policy, a ReservationService that manages
the Reservation Queue, and a CatalogService that handles search. When a Librarian submits an issue-Book
request, this layer checks the Member's current Loan count and the Book's availability before anything is
written to the database.
Data Layer. This layer only stores and retrieves Book, Member, Loan, Reservation, and Fine records, talking
to the underlying database through insert, update, and delete operations. Keeping persistence here means the
Business Layer never has to write SQL directly.

Architecture Explanation
The Entity-Relationship model this system builds on treats Book, Publisher, Member, and Loan as the core
entities, connected through “published by” and “borrowed by” relationships [1]. Wrapping this schema in a
proper Data Layer means a new feature such as the Reservation Queue or Fine Management can be added by
extending the Data and Business layers, without touching the Presentation Layer that is already in place.
If the University Library needed to scale up, the same three-tier idea can be extended into an N-tier setup,
where the Business Layer is spread across several application servers to share the load, following the typical
web browser/web server/application server/data server pattern. A cloud-based digital library platform used as
a reference point for the DevOps side of this project shows a further step in that direction, where services
such as ingestion, identifier minting, and fixity checking each run independently instead of sitting inside one
large application layer [2]. For a single-campus university LMS, however, the simpler three-tier structure is
enough, and it is the structure the rest of this report is built around.

4. Task 3 – Object-Oriented Design Principles and Design Pattern

Design Principles
The following object-oriented design principles guide how responsibilities are divided across classes in the
proposed system [4].
Single Responsibility Principle (SRP). A class should only have one reason to change [3]. Applied to this
LMS, the Book class should hold only book data and behaviour, such as title, author, and availability, while
Fine calculation and Member notification are handled by separate classes (FineCalculator,
NotificationService). Keeping these apart means a change to the fine policy will not risk breaking unrelated
Book Catalog code.
Open/Closed Principle (OCP). Classes should be open for extension but closed for modification. In practice,
this means adding a new loanable item type, such as a DVD or e-book alongside Book, or a new fine policy
for a new Member category, should be done by adding a class rather than editing an existing one. This is the
idea the Repository and Factory patterns below put into practice.
Dependency Inversion Principle (DIP). High-level modules should depend on abstractions rather than on
concrete, low-level implementations. A LoanService in this system depends on a BookRepository interface
rather than on a specific database driver, so the way data is stored can change later without touching
circulation logic.
These three principles were chosen because they build directly toward the pattern recommended below: SRP
keeps Loan, Fine, and Catalog responsibilities in separate services, OCP allows new item types and fine rules
to be added safely, and DIP is essentially the reason the Repository pattern is useful in the first place. Other

4
 Library Management System – SCD Report

SOLID principles, such as the Liskov Substitution Principle, would matter more once the Book Catalog
supports multiple loanable item subtypes [5], but SRP, OCP, and DIP are the ones most directly relevant to
the design decisions in this report.

Recommended Design Pattern: Repository

Drawing on the standard catalogue of reusable object-oriented design patterns [7], the Repository pattern was
selected as the main design pattern for this LMS. It sits between the Business Layer and the Data Layer,
offering a simple, collection-like interface — findByIsbn(), findAvailable(), save() — over Book, Member,
or Loan records, rather than letting other parts of the system talk to the database directly [6]. A single
BookRepository interface is defined, with a concrete implementation, such as MySqlBookRepository, behind
it; the LoanService and CatalogService only ever depend on the interface, never on the database class itself.
This pattern fits well with the layered architecture from Task 2, since it is really the mechanism that makes
the Dependency Inversion Principle above work in practice. It also keeps the Data Layer fully isolated, so
switching to a different database technology later would not require any change to Loan, Reservation, or Fine
logic. As a side benefit, the Business Layer becomes much easier to test, since a fake, in-memory repository
can stand in for a real database connection during testing.
A Factory pattern was also considered as a complementary option for handling new item subtypes, since a
similar design has already been used successfully in a library system context, where a BookFactory was used
to produce Book, Magazine, Journal, and Textbook subtypes from one common base class [8]. Repository
and Factory are not really alternatives to each other here — a LibraryItemFactory could easily sit behind a
BookRepository's save() method — so both could be introduced together if the Book Catalog later needs to
support more than one item type.

Figure 2. Repository Pattern for Data Access (Original Diagram)

5
 Library Management System – SCD Report

5. Task 4 – Coding Standards, Software Quality Metrics, and Testing Strategy

Coding Standards
Since this LMS is planned as a PHP-based application, the PSR-12 style standard was adopted as the coding
convention, which specifies StudlyCaps for class names (BookRepository) and camelCase for methods
(calculateOverdueFine()) [11]. On top of naming, comments in the codebase should explain the reasoning
behind a piece of logic rather than just restating what the code already shows, in line with widely used clean-
code practice [10] — a comment on calculateFine() should explain the grace-period and cap assumptions
behind the number, not repeat the arithmetic itself.
Exception handling follows the same principle: specific, named exceptions such as
BookUnavailableException are used when a Member tries to check out an already-loaned Book, instead of
returning null or a generic error string, so the calling code can respond meaningfully. Because this system
includes an admin login for Librarians, secure coding practice matters from the start — input to the Catalog
search and ISBN fields must be validated, queries must use parameterised statements instead of string
concatenation to avoid SQL injection, and passwords must be stored using a modern salted hash such as
bcrypt, in line with standard secure coding guidance [12].

Software Quality Metrics

The quality metrics tracked for this project reflect quality attributes such as maintainability defined in the
ISO/IEC 25010 quality model [9]. Cyclomatic Complexity was chosen as one of these metrics. It counts the
number of independent paths through a method's logic and gives a rough sense of how much of that logic is
likely to be untested [13]. A calculateFine() method with nested conditions for Member type, loan-duration
tiers, and grace periods is a good candidate to watch here, since McCabe's own guidance treats 10 as a
reasonable ceiling for a single method, and going past it is a fair signal to refactor toward the Strategy pattern
[13].
The Maintainability Index is a useful second metric, combining code volume, complexity, and length into
one score that flags modules likely to become expensive to maintain over time [14]. Coupling and cohesion
give a more targeted, class-level picture: a LoanService that references concrete database, email, and SMS
classes directly would show high coupling, which is a specific, fixable problem that the Repository pattern
from Task 3 is well suited to solve [20].

Testing Strategy
The testing strategy for this LMS follows the usual progression of unit, integration, system, and acceptance
testing, with acceptance testing ideally involving someone outside the development team rather than just the
developer checking their own work [1]. Two further practices are planned on top of this baseline. First,
automated regression testing as part of the CI pipeline, similar to the Cypress-based end-to-end approach used
on the digital library platform referenced for the DevOps side of this project, where every pull request
automatically triggers a test run and reports pass status and execution time [2]. For this LMS, that would
mean automated unit tests for Fine calculation and a small set of end-to-end tests covering the issue-Book
and return-Book flows. Second, a test-driven approach specifically for the Fine calculation logic — writing
tests for boundary cases such as a Book returned exactly on the due date, one day late, and at the fine cap,
before the calculateFine() method itself is written, since this tends to surface edge cases that the original
specification does not spell out [15].

6
 Library Management System – SCD Report

6. Task 5 – Version Control, CI/CD, and DevOps

Version Control and Git Workflow
Git is used for version control throughout the project, but the actual workflow — how branches are created,
named, and merged — matters more day to day than Git itself. For a small, single-team university project like
this LMS, with no need to maintain several production releases at once, a simple GitHub Flow works better
than a full Git Flow setup: one long-lived main branch, short-lived feature branches for each task (issue-book,
fine-calculation, reservation-queue), and a pull request before anything is merged [17]. This also matches
what larger studies of software teams have found — frequent, small merges into a shared branch tend to be
associated with better-performing teams than long-lived, separate branches [18].

CI/CD

Figure 3. Proposed CI/CD Pipeline (Source adapted from [2])

The CI/CD pipeline for this project is modelled on a working setup used on a real digital library platform, a
useful reference point since it covers the same PHP/web-application context this LMS sits in [2]. In that setup,
a pull request to GitHub triggers an automated pipeline that builds and tests the code, stores a build artifact
once the tests pass, and then deploys automatically to a testing environment before a reviewer signs off on
the change, following established code review practice [16]. Applied to this LMS, a change to LoanService
or FineCalculator would not be allowed to merge into main until its unit tests, an automated build, and an
end-to-end check of the issue-and-return flow all pass — the same kind of discipline that setup already runs.

DevOps Practices
Two further DevOps ideas are worth carrying into this project beyond the pipeline itself. Infrastructure as
Code — keeping deployment configuration in version-controlled files rather than setting servers up by hand
— would let a fresh testing environment be spun up for each pull request instead of everyone sharing one
environment and getting in each other's way [2]. DevOps is also more of a habit than a set of tools: on the
reference platform, the operations side of the work is folded directly into sprint planning and review rather
than treated as a separate step after development finishes. For a student project, the equivalent is simply
treating “builds and deploys cleanly” as part of what counts as a finished feature, rather than something to
sort out later.
Releases of this LMS would also follow Semantic Versioning, using a [Link] numbering
scheme — adding a Reservation feature after the initial submission would count as a MINOR release, while

7
 Library Management System – SCD Report

a fix to a Fine-calculation bug would be a PATCH release. This gives anyone using the system a quick sense
of how risky an update is without reading a full changelog [19].

7. Conclusion
This report has presented a proposed Library Management System for a university library, built around Books,
Student and Faculty Members, Loans, the Reservation Queue, and Fine Management. The three-tier layered
architecture and the Repository pattern keep circulation logic separate from data storage, so the system can
be extended — for example to support new item types or a payment-based fine settlement feature — without
reworking existing code. The SRP, OCP, and DIP principles behind this design keep responsibilities cleanly
separated and keep the codebase testable as it grows. The chosen coding standards and quality metrics
(Cyclomatic Complexity, Maintainability Index, coupling/cohesion) give a practical way to keep the system
maintainable, and the GitHub Flow branching model together with the proposed CI/CD pipeline provides a
realistic, lightweight process for building and testing the system incrementally. Future enhancements could
include support for additional loanable item types via a Factory pattern, a payment gateway for Fine
settlement, and expanding the CI pipeline's automated test coverage as the system grows.

8. References
[1] A. Samuel, A. Godfred, and X. He, “Design and implementation of library management system,” Int. J. Comput. Appl.,
vol. 182, no. 13, pp. 18–25, Sep. 2018.
[2] Y. Chen, “DevOps practices in digital library development,” in Proc. ACM/IEEE Joint Conf. Digital Libraries (JCDL
'22), Cologne, Germany, 2022, pp. 1–4.
[3] R. C. Martin, Agile Software Development, Principles, Patterns, and Practices. Upper Saddle River, NJ: Prentice Hall,
2002.
[4] B. Meyer, Object-Oriented Software Construction. Englewood Cliffs, NJ: Prentice Hall, 1988.
[5] B. H. Liskov and J. M. Wing, “A behavioral notion of subtyping,” ACM Trans. Program. Lang. Syst., vol. 16, no. 6, pp.
1811–1841, 1994.
[6] M. Fowler, Patterns of Enterprise Application Architecture. Boston, MA: Addison-Wesley, 2002.
[7] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software.
Boston, MA: Addison-Wesley, 1994.
[8] P. Jain, S. Shaw, and M. Gupta, “Improving design of library management system using design patterns,” Int. J. Adv.
Res. Comput. Sci., vol. 8, no. 3, pp. 723–727, 2017.
[9] ISO/IEC 25010:2011, Systems and Software Engineering — Systems and Software Quality Requirements and Evaluation
(SQuaRE) — System and Software Quality Models. ISO/IEC, 2011.
[10] R. C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship. Upper Saddle River, NJ: Prentice Hall, 2008.
[11] PHP Framework Interop Group, “PSR-12: Extended coding style.” [Online]. Available: [Link]
[Link]/psr/psr-12/
[12] OWASP Foundation, “OWASP top 10.” [Online]. Available: [Link]
[13] T. J. McCabe, “A complexity measure,” IEEE Trans. Softw. Eng., vol. SE-2, no. 4, pp. 308–320, 1976.
[14] D. Coleman, D. Ash, B. Lowther, and P. Oman, “Using metrics to evaluate software system maintainability,” IEEE
Computer, vol. 27, no. 8, pp. 44–49, 1994.
[15] K. Beck, Test-Driven Development: By Example. Boston, MA: Addison-Wesley, 2002.
[16] A. Bacchelli and C. Bird, “Expectations, outcomes, and challenges of modern code review,” in Proc. 35th Int. Conf.
Software Engineering (ICSE), 2013, pp. 712–721.
[17] V. Driessen, “A successful Git branching model.” [Online]. Available: [Link]
branching-model/
[18] N. Forsgren, J. Humble, and G. Kim, Accelerate: The Science of Lean Software and DevOps. Portland, OR: IT
Revolution Press, 2018.
[19] T. Preston-Werner, “Semantic versioning 2.0.0.” [Online]. Available: [Link]
[20] S. R. Chidamber and C. F. Kemerer, “A metrics suite for object-oriented design,” IEEE Trans. Softw. Eng., vol. 20, no.
6, pp. 476–493, 1994.