Q1.

Prepare an SRS Document in Line with the IEEE

Recommended Standards.

Ans :
The Software Requirements Specification (SRS) document outlines the
functional and non-functional requirements of the system. The IEEE 830-
1998 standard provides a recommended structure for an SRS document.
Below is a detailed SRS for the Library Management System.SRS
Document for Library Management System

1. Introduction
1.1 Purpose

The purpose of this SRS is to define the requirements for a Library

Management System (LMS) that automates book borrowing, returning,
and management processes for a university library.

1.2 Scope

The LMS will allow students to search, borrow, and return books, and
librarians to manage book inventory and user accounts. It will include a
user-friendly interface, secure login, and email notifications for overdue
books.

1.3 Definitions, Acronyms, and Abbreviations

● LMS: Library Management System

● UML: Unified Modeling Language
● GUI: Graphical User Interface

1.4 References

● IEEE 830-1998 Standard for SRS

● Library management policies of the university

1.5 Overview
The document describes the functional requirements (e.g., borrowing
books), non-functional requirements (e.g., performance), and design
constraints.

2. Overall Description

2.1 Product Perspective

The LMS is a standalone web-based application with a database

backend to store book and user information. It interfaces with an email
system for notifications.

2.2 Product Functions

● User authentication (login/logout)

● Book search by title, author, or ISBN
● Borrow and return books
● Librarian functions: add/remove books, manage users
● Email notifications for overdue books

2.3 User Characteristics

● Students: End-users with basic computer skills, needing to

borrow/return books.
● Librarians: Administrative users with moderate computer skills,
managing the system.

2.4 Constraints

The system must be accessible via a web browser.

Response time for searches should be under 2 seconds.
The system must comply with university data privacy policies.

3. Specific Requirements

3.1 Functional Requirements

 ● FR1: The system shall allow users to log in with a username and
password.
● FR2: Students shall be able to search for books by title, author, or
ISBN.
● FR3: Students shall be able to borrow up to 5 books for 14 days.
● FR4: Librarians shall be able to add/remove books from the
inventory.
● FR5: The system shall send email notifications for overdue books.

3.2 Non-Functional Requirements

● NFR1: The system shall support up to 1,000 concurrent users.

● NFR2: The system shall have 99.9% uptime.
● NFR3: The system shall use encryption for user passwords.

4. Design Constraints

● The system must use Java for backend development.

● The database must be MySQL.

5. Appendices

● Glossary of terms
● Sample user interface mockups (not included here)
Q2. Draw the Use Case Diagram and Specify the Role of
Each Actor. Also state the precondition,post condition and
function of each use case.

Ans :
Use Case Diagram for an Online Shopping System along with a brief
explanation of each actor's role.

Actors and Their Roles:

1. Customer (Primary Actor)

● Role: Uses the system to browse, search, and purchase products.

● Use Cases:

1. Register/Login
2. Browse Products
3. Search Product
4. Add to Cart
5. Place Order
6. Make Payment
7. Track Order
8. Give Feedback

2. Admin

● Role: Manages the entire system including users, products, and

orders.

● Use Cases:

1. Manage Users
2. Manage Products
3. View Orders
4. Update Order Status
5. Generate Reports
3. Delivery Staff

● Role: Handles product delivery and updates order status.

● Use Cases:

1. View Assigned Orders

2. Update Delivery Status

4. Payment Gateway (External System)

● Role: Processes payment transactions.

● Use Cases:

1. Process Payment
Q3. Draw the Activity Diagram

Ans :
Activity Diagram Description

An activity diagram illustrates the workflow of a process. Let’s describe

the Borrow Book process:

1. Start: Student logs in.

2. Action: Student searches for a book.
3. Decision: Is the book available?
If Yes:
● Action: Student requests to borrow.
● Action: System updates book status and user record.
● Action: System sets due date.

If No:
● Action: Notify student of unavailability.

4. End: Process completes.

Q4. Identify the Classes, Classify as Weak and Strong, and
Draw the Class Diagram

Ans :
Class Diagram Description
Classes represent the entities in the system. For the LMS:

Classes:

● User (abstract, strong): Attributes (userID, username, password,

email); Methods (login(), logout()).

● Student (inherits User, strong): Attributes (borrowedBooks);

Methods (borrowBook(), returnBook()).

● Librarian (inherits User, strong): Methods (addBook(),

removeBook(), manageUsers()).

● Book (strong): Attributes (bookID, title, author, ISBN, status);

Methods (updateStatus()).

● BorrowTransaction (weak, depends on Student and Book):

Attributes (transactionID, borrowDate, dueDate).

● Notification (weak, depends on BorrowTransaction): Attributes

(message, recipient); Methods (send()).

Strong vs. Weak Classes:

● Strong classes (User, Student, Librarian, Book) can exist

independently.

● Weak classes (BorrowTransaction, Notification) depend on other

classes for their existence.
Class Diagram:
Q5. Draw the Sequence Diagram for Any Two Scenarios.

Ans :
Sequence Diagram Description

A sequence diagram shows the interaction between objects over time.

Let’s describe two scenarios: Borrow Book and Return Book.

Scenario 1: Borrow Book

● Actors/Objects: Student, System, Book, BorrowTransaction.

● Flow:

1. Student → System: requestBorrow(bookID).

2. System → Book: checkAvailability().
3. Book → System: isAvailable = true.
4. System → BorrowTransaction: createTransaction(studentID,
bookID).System → Student: confirmBorrow().

Scenario 2: Return Book

● Actors/Objects: Student, System, Book, BorrowTransaction.

● Flow:

1. Student → System: requestReturn(bookID).

2. System → BorrowTransaction: findTransaction(bookID).
3. System → Book: updateStatus(available).
4. System → Student: confirmReturn().
Q6. Draw the Collaboration Diagram

Ans :
Collaboration Diagram Description

A collaboration diagram shows object interactions with a focus on links.

For the Borrow Book scenario:

Objects: Student, System, Book, BorrowTransaction.

Links and Messages:

1: Student → System: requestBorrow().

2: System → Book: checkAvailability().
3: System → BorrowTransaction: createTransaction().
Q7. Draw the State Chart Diagram

Ans :
State Chart Diagram Description

A state chart diagram shows the states of an object. For a Book object:

States: Available, Borrowed, Overdue, Removed.

Transitions:

1.Available → Borrowed: borrowBook().

2.Borrowed → Overdue: dueDate passes.
3.Borrowed → Available: returnBook().
4.Any state → Removed: removeBook().
Q8. Draw the Component Diagram

Ans :
Component Diagram Description

A component diagram shows the physical structure of the system. For

the LMS:

Components:

● User Interface: Web-based GUI.

● Application Logic: Java-based backend.
● Database: MySQL for storing data.
● Email Service: For notifications.

Interfaces:

● User Interface ↔ Application Logic: HTTP requests.

● Application Logic ↔ Database: JDBC connection.
● Application Logic ↔ Email Service: SMTP.
Q9. Perform Forward Engineering in Java (Model to Code
Conversion)

Ans :
Forward Engineering in Java means converting a model (like UML class
diagrams) into actual Java code. Let’s perform forward engineering
based on a simple example:

Model Description (for a Library Management System):

● Class: Book

● Attributes: title, author, isbn, available

● Methods: borrowBook(), returnBook()

Java Code (Forward Engineered):

public class Book {

private String title;
private String author;
private String isbn;
private boolean available;

public Book(String title, String author, String isbn) {

this.title = title;
this.author = author;
this.isbn = isbn;
this.available = true; // initially available
}

public boolean isAvailable() {

return available;
}

public void borrowBook() {

if (available) {
 available = false;
System.out.println("Book borrowed successfully.");
} else {
System.out.println("Book is currently not available.");
}
}

public void returnBook() {

available = true;
System.out.println("Book returned successfully.");
}

// Getters and setters

public String getTitle() {
return title;
}

public String getAuthor() {

return author;
}

public String getIsbn() {

return isbn;
}
}
Q10. Perform Reverse Engineering in Java (Code to Model
Conversion)

Ans :
What is Reverse Engineering in Java?

Reverse engineering in Java means converting existing Java code into a

model — typically a UML (Unified Modeling Language) diagram like a
Class Diagram.

Steps to Perform Reverse Engineering in Java

1. Read and Analyze the Code

Identify the:

● Class name
● Attributes (with their types and access modifiers)
● Methods (with their parameters, return types, and access
modifiers)
● Relationships (if multiple classes)

2. Create the Class Diagram Model

● Use + for public, - for private, # for protected

● List attributes with their type
● List methods with parameters and return types
● Show relationships like inheritance, association if needed

Example Java Code (Input)

public class Student {

private String name;
private int rollNumber;
private double marks;
 public Student(String name, int rollNumber, double marks) {
this.name = name;
this.rollNumber = rollNumber;
this.marks = marks;
}

public String getName() { ... }

public int getRollNumber() { ... }
public double getMarks() { ... }
public void setMarks(double marks) { ... }
}

UML Class Diagram (Output Model)

+-----------------------------+
| Student |
+-----------------------------+
| - name: String |
| - rollNumber: int |
| - marks: double |
+-----------------------------+
| + Student(name, rollNumber, marks) |
| + getName(): String |
| + getRollNumber(): int |
| + getMarks(): double |
| + setMarks(marks: double): void |
+-----------------------------+

Reverse Engineering Process

● Read code
● Identify class, attributes, methods
● Convert to UML format using standard notation
Q11. Draw the Deployment Diagram.

Ans :
Deployment Diagram Description

A deployment diagram shows the physical deployment of the system.

For the LMS(Library Management system):

Nodes:

● Client Device: Runs the web browser.

● Application Server: Hosts the Java application (e.g., Apache
Tomcat).
● Database Server: Hosts the MySQL database.
● Email Server: Sends notifications.

Connections:

● Client Device ↔ Application Server: HTTP/HTTPS.

● Application Server ↔ Database Server: JDBC.
● Application Server ↔ Email Server: SMTP.
● Application Server ↔ Email Server: SMTP.