1.

Furniture Stock Management System (FSMS)

A Furniture Stock Management System is a digital solution designed to streamline the

management of furniture inventory, including stock updates, order placement, and category
management. It helps businesses maintain accurate stock levels, process customer orders
efficiently, and organize furniture categories systematically.

2. Objective of Digitalization

Implementing an application for Furniture Stock Management aims to :

• Improve Efficiency: Automate stock updates, order processing, and payments.

• Enhance Accuracy: Reduce human errors in inventory tracking and order

management.

• Optimize Customer Experience: Provide a seamless way to browse and purchase

furniture.

• Centralize Management: Allow administrators to easily categorize and update

furniture stock.

3. UML Textual Descriptions for Selected Use Cases

a. Create Account [Customer]

Actors : Customer

Description : A customer registers an account to access the system and place orders.

Nominal Scenario :

1. Customer selects « Create Account. »

2. Customer enters personal details and credentials (username, email, password).

 3. System validates inputs.

4. System creates an account and confirms successful registration.

Alternative Scenario :

2a. Customer enters invalid details (e.g., weak password, existing email).

3a. System displays an error and prompts for corrections.

b. Place Order [Customer]

Actors : Customer

Description : A customer selects furniture and places an order.

Nominal Scenario :

1. Customer logs in and browses available furniture.

2. Customer selects desired furniture items.

3. Customer proceeds to checkout and enters payment details.

4. System processes payment and confirms order placement.

Alternative Scenarios :

2a. No furniture available → System notifies the customer.

3a. Payment details are incorrect → System prompts for correction.

3b. Payment is unsuccessful → System notifies the customer.

c. Update Furniture Stock [Employee]

Actors : Employee

Description : An employee updates the quantity and status of furniture in stock.

Nominal Scenario :

1. Employee logs in and accesses the stock management section.

2. Employee selects a furniture item to update.

3. Employee modifies the stock quantity or furniture status.

4. System saves the update and confirms success.

Alternative Scenarios :

2a. Selected item does not exist → System displays an error.

3a. Invalid quantity entered → System requests a valid input.

d. Manage Furniture Items [Admin]

Actors : Admin

Description : The administrator adds or removes furniture items from the system.

Nominal Scenario :

1. Admin logs in and accesses the furniture management section.

2. Admin selects « Add Furniture » or « Remove Furniture. »

3. Admin enters necessary details (name, category, price, stock, status).

4. System saves the update and confirms success.

Alternative Scenarios :

2a. Invalid data input → System prompts for correction.

3a. Removing a non-existent item → System notifies the admin.

e. Manage Categories [Admin]

Actors : Admin

Description : The administrator adds or removes furniture categories.

Nominal Scenario :

1. Admin logs in and accesses the category management section.

2. Admin selects « Add Category » or « Remove Category. »

3. Admin enters or selects the category name.

4. System saves changes and confirms success.

Alternative Scenarios :

2a. Adding a duplicate category → System notifies admin.

3a. Removing a non-existent category → System prevents deletion.

4. Class Diagram Analysis

Here’s a breakdown of each class, its role, and key member functions :

a. Staff (Abstract Class)

Use : Represents system users who manage stock and categories (Admin, Employee).

Formed : When an Admin or Employee account is created.

Key Member Functions :

• Login() – Authenticates staff.

• Logout() – Ends session.

Generalization :

• Admin : Manages furniture and categories.

• Employee : Updates stock and manages payments.

b. Admin (Inherits Staff)

Use : Manages furniture items and categories.

Key Member Functions :

• addemployee() – Adds a new employee.

• removeemployee() – Deletes an employee.

• addCategory() – Adds a category.

• removeCategory() – Removes a category.

c. Employee (Inherits Staff)

Use : Updates stock and handles payments.

Key Member Functions :

• addFurniture() – Adds a new furniture item.

• removeFurniture() – Deletes an item.

 • confirmPayment() – Approves payment.

• rejectPayment() – Declines payment.

• notifyCustomer() – Notify Customer.

d. Customer

Use : A system user who can browse furniture, place orders, and make payments. It is
formed when a user registers.

Key Member Functions :

• createAccount() – Registers a new customer.

• placeOrder() – Places a new order.

• makePayment() – Proceeds with a payment for an order.

e. Furniture

Use : Represents furniture items available in stock. It is formed when an Admin adds a
furniture item.

Key Member Functions :

• increaseStock() – Add Stocks.

• decreaseStock() – Changes stock quantity.

• increasefurniture() – Add Furniture.

• decreasefurniture() – Remove furniture item.

f. Order

Use : Stores details of customer purchases. It is formed when a customer places an order.

Key Member Functions :

• totalamount() – Computes the total order price.

• updateStock() – Changes order details.

g. Payment

Use : Manages payment processing. It is formed when a customer makes a payment.

Key Member Functions :

• validPayment() – Confirm and validate payment transactions.

• rejectPayment() – Reject payment.

h. Category

Use : Categorizes furniture for easy management. It formed when an Admin adds a category.

Key Member Functions :

• addCategory() – Creates a new category.

 • removeCategory() – Deletes a category.

i. Notification

Use : Sends updates to customers and employees about orders and stock changes.

Formed : When an event (order confirmation, stock update, etc.) occurs.

Key Member Functions :

• notify() – Sends a notification.

j. Optional Class : Refund (If Required)

Use : Handles refund requests if payments are reversed. It was formed when a payment is
rejected.

Key Member Functions :

• validRefund() – Valid refund request.

• rejectRefund() – Reject refund request.

5. General Use Cases

In this system, we have as actors Vistor, Customer, Employee, Admin. Here are
some use cases that can be executed.

Visitor
i. Browse App: Here the visitor can view the app

Customer
i. Create Account: The visitor can initiate the account creation process by clicking on
the ''Create Account" button.

ii. Place Order: The customer can place an order on the furnitures.

Employee
i. Manage Payments: The employee can confirm and reject payment.

ii. Update Furniture Stocks: The employee can increase and decrease stock levels.
 iii. Notify the Admin: Notification can be send to the Admin once there's any movement
in the stock.

Admin
i. Manage Stock Items: Add and remove items in the stocks .
ii. Manage Payment: Validate and reject Payment made by the customer.

iii. Manage Category: The admin can add and remove categories.

6. Activity Diagram

[Link] Account:
 An activity diagram for the "Create Account" use case visually represents the sequential
steps and interactions between the user and the system during the account creation process.

1. The process initiates when the user clicks "Create Account".

2. The system displays the account creation form.

3. The user fills in the required information and submits the form.

4. The system validates the provided credentials.

5. If validation fails, an error message is shown, and the flow returns to form submission. If
validation succeeds, the process continues.

6. The system saves the user's data in the database.

7. A notification (e.g., email confirmation) is sent to the user.

8. The system displays the user dashboard.

9. The account creation process concludes.

b. Place Order:
 An activity diagram for the "Place Order" use case illustrates the sequence of actions
between a customer and the system during the ordering process.

1. The process begins when the customer clicks "Place Order".

2. The system displays order options.

3. The customer selects desired items and confirms the order.

4. The system checks the availability of the selected items in stock.

5. If items are out of stock, an error message is displayed, and the process returns to step 2.
If items are in stock, the process continues.
6. The system saves the order details in the database.

7. The system presents payment options to the customer.

8. The customer selects a payment method and initiates the payment.

9. The system verifies the payment details.

10. If payment verification fails, the system returns to step 7. If verification succeeds, the
payment is processed via the appropriate API.

11. The system sends a confirmation notification to the customer.

12. The order placement process concludes successfully.

7. Deployment Diagram

The deployment diagram for the Furniture Stock Management System (FSMS) outlines the
system’s architecture and interactions :

• Client/User Node : Represents the user’s device running a web browser, facilitating
interaction with the FSMS interface.
 • Web Server Node : Hosts the Apache Web Server and the Tomcat Application Server
components. The Apache server handles http/HTTPS requests, forwarding dynamic
content requests to Tomcat, which manages the FSMS application logic.

• API Node : Contains the Payment API component, responsible for processing
payment transactions.

• App Server Node : Houses the Manage Stock Logic Module, overseeing inventory
operations and ensuring stock levels are current.

• Database Node : Utilizes the MySQL component to store and manage all persistent
data, including user information, orders, and inventory details.

a. Communication Pathways :

• Client/User Node ↔ Web Server Node : Communication occurs over http/HTTPS

protocols, enabling secure data exchange between the user’s browser and the web
server.

• Web Server Node ↔ API Node : Interacts via http/HTTPS protocols, allowing the
application to send payment requests and receive responses from the Payment API.

• API Node ↔ App Server Node : Communicates through http/HTTPS protocols,

facilitating the relay of payment confirmations and updates to the stock management
module.

• App Server Node ↔ Database Node : Connects using TCP/IP protocols, ensuring
reliable data transmission between the application logic and the MySQL database for
data retrieval and storage.

The Package Diagram for the Furniture Stock Management System (FSMS) illustrates the
system’s modular structure and the relationships between its components :
 • User Package : Encompasses the Customer Package and the Staff Package, with the
latter further divided into Employee and Admin Packages. This hierarchy organizes
user roles and permissions.

• Stock Package : Contains the Category Package and the Furniture Package, managing
product classifications and inventory details.

• Functionalities Package : Includes the Order, Payment, Notification, and Refund

Packages, each handling specific business operations.

8. Package Diagram

Inter-Package Relationships :

The Employee Package accesses the Customer Package, allowing staff to manage customer
information.
The Order Package accesses the Payment Package to process transactions.

The Notification Package accesses the Order Package to send order-related updates.

The Refund Package accesses the Notification Package to inform customers about refunds.

The Refund Package imports both the Order and Payment Packages to handle refund
processes effectively.

The User Package accesses the Functionalities Package, enabling users to utilize system
features.

The Stock Package imports the User Package and accesses the Functionalities Package to
manage inventory in relation to user actions.

Within the Stock Package, the Category Package accesses the Furniture Package to organize
products appropriately.

9. Component Diagram

The component diagram for the Furniture Stock Management System (FSMS) delineates the
system’s architecture and the interactions among its primary components :
 • Web Browser Component : Serves as the client interface, enabling users to interact
with the FSMS.

• Web Server Component : Manages incoming http/HTTPS requests from the Web
Browser, utilizing reception and transmission sockets for communication.

• Tomcat Application Server (FSMS) : Hosts the core application logic of FSMS,
processing business operations and interfacing with other system components.

• Payment API Component : Handles payment processing, ensuring secure and efficient
financial transactions within the system.

• DBMS Component : Represents the database management system, responsible for

storing and retrieving all persistent data related to the application.

Interconnections :

• Web Browser ↔ Web Server : The Web Browser connects to the Web Server via
reception and transmission sockets, facilitating bidirectional communication.

• Web Server ↔ Tomcat Application Server : The Web Server communicates with the
Tomcat Application Server through a connection socket, forwarding client requests
for processing.

• Tomcat Application Server ↔ Payment API : Interaction occurs via a payment socket,
enabling the application server to process payment-related requests through the
Payment API.
 • Payment API ↔ DBMS : The Payment API interfaces with the DBMS using a MySQL
socket, allowing for secure storage and retrieval of payment data.

10. Sequence Diagram

a. Authentication Diagram:

• Customer initiates the sequence by sending a synchronous message "Request Form"

to the FSMS.

• FSMS display the Form.

 • The Customer now fill with his informations & Submit the Form.

• FSMS activates and sends a synchronous “Check Form”.

• An alt (alternative) fragment handles the validity of the form:

• If invalid, FSMS will send an error message.

• If valid, the system proceeds to send an authentication query to the DBMS.

• the DBMS will execute and send the result of the query.

• An alt (alternative) fragment handles the validity of the credentials:

• If invalid, FSMS will send a login failed message.

• If valid, the system proceeds to display the user dashboard.

b. Create Account:
 • Customer initiates the sequence by sending a synchronous message "Request
registration Form" to the FSMS.

• FSMS display the Form.

• The Customer now fill with his informations & Submit the Form.

• FSMS activates and sends a synchronous “Check Form”.

• An alt (alternative) fragment handles the validity of the form:

• If invalid, FSMS will send an error message.

• If valid, the system proceeds to send the Data to the DBMS.

• the DBMS will save the data and send Data saved status to the FSMS.

• The FSMS will send Notification to the customer.

c. Place Order:
• Customer initiates the sequence by sending a synchronous message (“Request Order
Options”) to the FSMS.

• FSMS activates and sends a synchronous “Check Stock” message to the DBMS.

• An alt (alternative) fragment handles the stock availability outcome :

• If invalid, an “Insufficient Stock” flow is triggered.

• If valid, the system proceeds to display Payment Options.

• FSMS sends a synchronous “Check Payment” request to the Payment API, which
activates and processes the payment.

• On successful payment, FSMS sends “Send Order Data” to the DBMS (again a
synchronous call) followed by “Save Data.”

• Another alt fragment handles invalid payment (leading to an error message) or valid
payment (leading to completion and notification).
 • Finally, FSMS sends an asynchronous “Send Notification” message to the Customer to
indicate the order process completion.

• Activations (vertical bars) appear on each participant to show when they are actively
processing a message.

11. Communication Diagram

Here's the diagramatic way on how communication will take place in the "Create Account",
"Authentication", "Place Order" use cases;

Create Account Communication Diagram

Authentication Communication Diagram
 Place Order Communication Diagram

12. State Machine Diagram

i. Account

• At the begining the account is in the New State.

• After the customer registration, the account is going to the Pending approval State.

• The system check the customer information and if it is valid, the account go to the
Active State if not, the account goes to the Rejected state.

• From the Active State, the customer can request to logout, and this will move the
account state to the Suspended state.

• The customer can also request for reactivation to comeback to the Active State.

ii. Order:
• It start when the customer place an order, for that order to move to the New state.

• After the payment initiated, the system verifies the payment. If valid, the order will
be in the Confirmed state, and if not, it will rather move to the cancelled state.

• The system verifies the stock. If valid, the order will be in the Processing state, and if
not, it will rather move to the Hold state.

• From the Processing state, the system after confirming the order, will make the
object order will transit to the Shipped state.

• From the Processing state, if the customer request Return it will go to the Returned
State and if the order deliver, it will transit to the Delivered State.