TRIBHUVAN UNIVERSITY

Faculty of Management

National College of Computer Studies

Paknajol, Kathmandu

Object Oriented Analysis and Design

Lab Report on
Book Inventory Management System

Submitted By: Submitted To:

Pranish Shakya Mr. Nabaraj Bahadur Negi
Manish Maharjan
Pratham Rana Magar
Prajan Ghimire
BIM 7th Semester
Submission date: November/ 2024
 Table of Contents
1. Introduction......................................................................................................................................1
1.1 Aim..........................................................................................................................................1
1.2 Project description...................................................................................................................1
1.3 Purpose.....................................................................................................................................1
1.4 Problem Statement...................................................................................................................1
2. UML Diagrams................................................................................................................................2
2.1 Use case Diagram....................................................................................................................2
2.2 Class Diagram..........................................................................................................................3
2.3 Avtivity Diagram.....................................................................................................................6
2.4 Sequence Diagram...................................................................................................................7
2.5 Collaboration Diagram............................................................................................................8
2.6 State Diagram..........................................................................................................................9
2.7 Component Diagram..............................................................................................................10
2.8 Deployment Diagram.............................................................................................................11
3. Design Pattern................................................................................................................................12
3.1. Creational Design Pattern......................................................................................................12
a. Singleton Pattern....................................................................................................................12
b. Factory Pattern.......................................................................................................................13
3.2. Structural Design Pattern.......................................................................................................14
a. Adapter Pattern......................................................................................................................14
3.3. Behavioral Design Pattern.....................................................................................................15
a. Observer Pattern....................................................................................................................15
 List of Figures
Figure 1: Use Case Diagram..................................................................................................................3
Figure 2: Class Diagram........................................................................................................................5
Figure 3: Activity Diagram....................................................................................................................6
Figure 4: Sequence Diagram.................................................................................................................7
Figure 5: Collaboration Diagram...........................................................................................................8
Figure 6: State Diagram.........................................................................................................................9
Figure 7: Component Diagram............................................................................................................10
Figure 8: Deployment Diagram...........................................................................................................11
1. Introduction
1.1 Aim
The Book Inventory Management System (BIMS) project focuses on developing UML diagrams
such as use case, activity, sequence, collaboration, class, component, deployment, and state charts
to represent system workflows, interactions, and architecture. These diagrams will capture core
functionalities like book issuance, record maintenance, inventory management, and tracking the
status of books or transactions. This approach ensures a clear understanding of system processes
and supports effective development and communication among stakeholders.

1.2 Project description

The Book Inventory Management System (BIMS) is designed as a desktop application to help
admins manage book records efficiently. Admins can log in securely to handle details about
books, including adding new books, updating inventory, and ensuring correct information is
maintained. The system makes it easy to issue books, keep track of transactions, and update the
status of each book. By automating these tasks, BIMS saves time and reduces errors, helping the
admin manage records more effectively and improve overall operations.

1.3 Purpose
Handling tasks like book issuance, inventory updates, and record-keeping manually can lead to
inefficiencies and mistakes, especially as the number of books and transactions increases. To
solve these issues, the Book Inventory Management System (BIMS) has been created to automate
and simplify these processes. Using modern programming and database tools, BIMS ensures
accurate, efficient, and timely management of inventory and book records, improving overall
system performance and making operations easier for the admin.

1.4 Problem Statement

The Book Inventory Management System (BIMS) tackles common issues like poorly organized
book records, inefficient inventory management, and errors in manually updating book statuses.
Relying on manual processes often results in mistakes, delays, and difficulty tracking which
books are available or issued. By automating these tasks, BIMS ensures accurate record-keeping,
streamlined inventory updates, and error-free tracking of book transactions, greatly improving
administrative efficiency and overall system performance.

1
2. UML Diagrams
The following UML diagrams describe the process involved in the Book Inventory Management
system.
2.1 Use case Diagram
The use case diagram for the book inventory management system includes the following actors
and use cases:
Actors: Admin
Use cases: Login (UC1), Add Books (UC2), Add Books Part (UC3), Issue Books (UC4), Search
(UC5), Logout (UC6)
Code
@startuml
actor Admin
rectangle "Book Inventory Management System" {
Admin --> (Login)
Admin --> (Book)
Admin --> (Book part)
Admin --> (Issue book)
Admin --> (Search)
Admin --> (Logout)

(Book) --> (Add) : <<include>>

(Book) --> (Edit) : <<include>>
(Book) --> (Delete) : <<include>>
}
left to right direction
@endul

2
 Figure 1: Use Case Diagram

2.2 Class Diagram

This diagram is used in this system as it represents the static structure of the system, showing
classes, their attributes, methods, and relationships.
UML Code:
@startuml

class Admin {
+ login()
+ addBook(name: String, status: String)
+ editBook(bookID: int, name: String, status: String)
+ deleteBook(bookID: int)
+ addBookPart(bookID: int, partName: String, status: String)
+ issueBook(studentID: int, bookID: int, partID: int)
+ searchStudent(studentID: int)
}
class Book {
- bookID: int

3
 - name: String
- status: String
+ createBook(name: String, status: String)
+ updateBook(bookID: int, name: String, status: String)
+ deleteBook(bookID: int)
}
class BookPart {
- partID: int
- bookID: int
- partName: String
- status: String
+ createBookPart(bookID: int, partName: String, status: String)
+ updateBookPart(partID: int, partName: String, status: String)
+ deleteBookPart(partID: int)
}

class Student {
- studentID: int
- name: String
+ getStudentDetails(studentID: int)
}
class IssueBook {
- issueID: int
- studentID: int
- bookID: int
- partID: int
- issueDate: Date
+ issueBook(studentID: int, bookID: int, partID: int)
}
class Search {
+ searchByStudentID(studentID: int)
}
Admin --> Book : manages >
Admin --> BookPart : manages >

4
Admin --> Student : interacts >
Admin --> IssueBook : issues >
Admin --> Search : searches >
Book --> BookPart :have >
Student -->Book :selects >
Student -->BookPart :selects >

@enduml

Figure 2: Class Diagram

5
2.3 Avtivity Diagram
This diagram represents the workflow or the sequence of activities and actions in the system,
showing the flow from one activity to another.
UML Code:

@startuml
start
:Login;
if (Authenticate?) then (valid)
if (Validate?) then (valid)
fork
:Book;
fork again
:Book part;
fork again
:Issue book;
fork again
:Search;
end fork
else (invalid)
:Go back to Login;
endif
else (invalid)
:Go back to Login;
endif
:Logout;
stop
@enduml

Figure 3: Activity Diagram

6
2.4 Sequence Diagram
It illustrates how objects interact in a particular sequence of events, focusing on the order of
messages exchanged.
UML Code:

@startuml
actor Admin

participant Login
participant Book
participant Student
participant Database
Admin -> Login : Login Credential
Login -> Database : Validate user
Database --> Login : Valid user
Login --> Admin : Display Admin Dashboard

Admin -> Book : Add/Edit/Delete/Status details

Book -> Database : Book details
Book --> Admin : Display Active Books
Database --> Book : Book Inactive
Book --> Admin : Display Inactive Books
Admin -> Student : Students details
Student -> Database : Request details
Database --> Student: Retrieve details
Student --> Admin : Display students details

@enduml

Figure 4: Sequence Diagram

7
2.5 Collaboration Diagram
This diagram is use to visualizes interactions between objects or components in a system,
highlighting how they collaborate to achieve a specific behavior or function.
UML Code:

@startuml
object Admin

object BookManagementService
object PartManagementService
object BookIssueService
object StudentSearchService
object BookDatabase
object PartDatabase
object StudentDatabase
Admin --> BookManagementService : Add/Edit/Delete Books
BookManagementService --> BookDatabase : Update Book Records
Admin --> PartManagementService : Manage Book Parts
PartManagementService --> PartDatabase : Update Part Records
Admin --> BookIssueService : Issue Books or Parts
BookIssueService --> BookDatabase : Check Book Availability
BookIssueService --> PartDatabase : Check Part Availability
Admin --> StudentSearchService : Search for Students
StudentSearchService --> StudentDatabase : Retrieve Student Information

@enduml

Figure 5: Collaboration Diagram

8
2.6 State Diagram
This diagram depicts the states of an object and the transitions between those states based on
events and show the various states an order can be in.
UML Code:
@startuml
[*] --> AddBooks : Start Process
AddBooks --> AddBookParts : Add New Books
AddBookParts --> IssueBooks : Add Books Parts if Available
IssueBooks --> Search : Issue Books for Students
Search --> EndProcess : Search Students ID
[*] --> EndProcess : End Process
@enduml

Figure 6: State Diagram

9
2.7 Component Diagram
This diagram shows how components are wired together to form larger components or systems
like the user interface, database, and business logic.

UML Code:

@startuml

package "Book Inventory Management System" {

[Admin Interface] --> [Inventory Service] : Add/Update/Search Books
[Inventory Service] --> [Database] : Store/Update Book Data
[Inventory Service] <-- [Database] : Retrieve Book Information
[Admin Interface] --> [Availability Service] : Check Book Stock
[Availability Service] --> [Database] : Fetch Book Stock Data
[Admin Interface] --> [Reporting Module] : Generate Inventory Reports
[Reporting Module] --> [Database] : Access Inventory Details
[Admin Interface] <-- [Reporting Module] : View Report Insights
[Inventory Service] <-- [Admin Interface] : Search/Update Requests
}

@enduml

Figure 7: Component Diagram

10
2.8 Deployment Diagram
In this diagram, it illustrates how the room booking system is deployed across different servers,
including the web server, application server, and database server.
UML Code:

@startuml
actor Admin
node System {
[Book Management Service]
[Book Issue Service]
[Student Search Service]
[Part Management Service]
}
node Database {
[Book Database]
[Part Database]
[Student Database]
}
Admin --> [Book Management Service] : Add Book
Admin --> [Book Management Service] : Edit Book
Admin --> [Book Management Service] : Delete Book
[Book Management Service] --> [Book Database] : Add/Update/Delete Book Records
[Book Management Service] --> [Part Management Service] : Manage Book Parts
[Part Management Service] --> [Part Database] : Add/Update/Delete Book Parts
Admin --> [Book Issue Service] : Issue Book Part
[Book Issue Service] --> [Book Database] : Verify Book Availability
[Book Issue Service] --> [Part Database] : Verify Part Availability
Admin --> [Student Search Service] : Search for Student
[Student Search Service] --> [Student Database] : Query Student Information
[Student Database] --> [Student Search Service] : Return Student Details
[Book Management Service] --> Admin : Confirm
[Book Issue Service] --> Admin : Confirm
[Student Search Service] --> Admin : Display Search Results
@enduml

Figure 8: Deployment Diagram

11
3. Design Pattern
3.1. Creational Design Pattern
a. Singleton Pattern
@startuml
class BookFactory {
- instance: BookFactory
- BookFactory()
+ getInstance(): BookFactory
+ createBook(name: String, status: String): Book
}
class Book {
- bookID: int
- name: String
- status: String
+ Book(name: String, status: String)
+ getDetails(): String
}
BookFactory --> Book : creates >
' Singleton representation
note right of BookFactory
"Singleton Pattern ensures only
one instance of BookFactory class"
end note
@enduml

12
b. Factory Pattern
Source Code:
@startuml
class BookFactory {
+ createBook(name: String, status: String): Book
}
interface Book {
+ getDetails(): String
}
class PhysicalBook implements Book {
bookID: int
name: String
status: String
+ getDetails(): String
}
BookFactory --> Book : creates >
BookFactory --> PhysicalBook

@enduml

13
3.2. Structural Design Pattern
a. Adapter Pattern
Source Code:
@startuml
interface Book {
+ getDetails(): String
}
class BookDatabase {
bookID: int
name: String
status: String
+ getBookDetails(): String
}
class BookAdapter implements Book {
bookDatabase: BookDatabase+ BookAdapter(bookDatabase: BookDatabase)+ getDetails():
String
}
class BookInventory {
books: List<Book>+ addBook(book: Book)+ displayBooks()
}
BookAdapter --> BookDatabase : adapts >
BookInventory --> Book : stores >
@enduml

14
3.3. Behavioral Design Pattern
In the system, these patterns can help manage complex workflows, interactions between different
components, and enhance flexibility and scalability. It focusses on the interaction between
objects, managing algorithms, and controlling how responsibilities are distributed.
a. Observer Pattern
Source Code:
@startuml
interface BookObserver {
+ update(bookStatus: String)
}
class BookNotifier {
observers: List<BookObserver>
bookStatus: String
+ addObserver(observer: BookObserver)+ removeObserver(observer: BookObserver)+
notifyObservers()+ setBookStatus(status: String)
}
class Student {
name: String+ Student(name: String)+ update(bookStatus: String)
}
BookObserver <|-- Student
BookNotifier --> Student
BookNotifier --> BookObserver
@enduml

15