LOW LEVEL

i DESIGN (LLD)

Low Level Design

Student Teacher Appointment Booking

Written By Shivam Singh

Document Version 0.3
Last Revised Date 29 – June-2024
ii LOW LEVEL
DESIGN (LLD)
Document Control
Change Record:
Versio Date Author Comments
n
0.1 26 – June Shivam Introduction & Architecture defined
- Singh
2024
0.2 27 – June Shivam Architecture & Architecture Description appended and updated
- Singh
2024
0.3 28 –June - Shivam Unit Test Cases defined and appended
2024 Singh

Reviews:
Versio Date Reviewer Comments
n
0.2 29 – June Karan Document Content , Version Control and Unit Test Cases to
- Singh be added
2024 Karki

Approval Status:
Version Review Reviewed By Approved By Comments
Date
 LOW LEVEL
iii DESIGN (LLD)

Contents
1. Introduction 1
1.1. What is Low-Level design document? 1
1.2. Scope 1
2. Architecture 2
3. Architecture Description 6
3.1. Admin 6
3.2. Login 6
3.3. Add Teacher Error! Bookmark not defined.
3.4. Manage Teacher 6
3.5. Approve Registration Error! Bookmark not defined.
3.6. Teacher Error! Bookmark not defined.
3.7. Teacher Login Error! Bookmark not defined.
3.10. Schedule Appointment Error! Bookmark not defined.
3.11. View All Appointments Error! Bookmark not defined.
3.12. View Messages Error! Bookmark not defined.
3.13. Student Error! Bookmark not defined.
3.14. Search Teacher Error! Bookmark not defined.
3.15. Book Appointment Error! Bookmark not defined.
3.16. Send Messages Error! Bookmark not defined.
3.17. Login/Resgistration Error! Bookmark not defined.
4. Unit Test Cases 6
 LOW LEVEL
1
DESIGN (LLD)

1. Introduction

1.1. What is Low-Level design document?

The goal of LLD or a low-level design document (LLDD) is to give the internal logical design of
the actual program code for Food Recommendation System. LLD describes the class diagrams with
the methods and relations between classes and program specs. It describes the modules so that the
programmer can directly code the program from the document.

1.2. Scope
Low-level design (LLD) is a component-level design process that follows a step-by-
step refinement process. This process can be used for designing data structures, required software
architecture, source code and ultimately, performance algorithms. Overall, the data organization
may be defined during requirement analysis and then refined during data design work
2 LOW LEVEL
DESIGN (LLD)

2. Architecture

LOGIN

Manage Approve
ADMIN Add Teacher
Teacher Registration

Teacher Schedule View

TEACHER Login Appointment Appointment

View
Message

Search Book Send

STUDENT Teacher Appointment Message

Registration/
Login
3 LOW LEVEL
DESIGN (LLD)
3. Architecture Description

1 Admin

The Admin module is an essential part of the Student-Teacher Appointment Booking

System, responsible for overseeing the overall management, configuration, and monitoring
of the system. Admins have the authority to manage user accounts, schedule
configurations, system settings, and generate reports. The architecture for the Admin
module involves various components and functionalities that ensure smooth and efficient
operations.

1.1 Login

 Authentication Service: The admin login functionality is managed by an authentication service

that verifies credentials using OAuth2 or JWT.
 Role-Based Access Control (RBAC): Ensures that only users with the admin role can access
the admin functionalities.

1.2 Add Teacher

 User Management Service: Admins can add new teachers by providing necessary details such
as name, email, subjects taught, and availability.
 Database Interaction: The new teacher's information is stored in the user table of the database
with the role set as "teacher".

1.3 Manage Teacher

 User Management Interface: Admins can view, update, or delete teacher profiles.
 CRUD Operations: Implemented via RESTful APIs for creating, reading, updating, and
deleting teacher information.
 Search and Filter: Allows admins to search and filter teacher profiles based on various criteria.

1.4 Approve Registration

 Registration Workflow: New teacher registrations or updates are subject to admin approval.
 Notification Service: Sends email/SMS notifications to teachers upon approval or rejection.
 Approval Interface: Admin interface to review and approve/reject pending registrations.

2. Teacher Module

2.1 Teacher Login

 Authentication Service: Similar to admin login, using OAuth2 or JWT.

 Session Management: Maintains active sessions and ensures secure access.

2.2 Schedule Appointment

3 LOW LEVEL
DESIGN (LLD)
 Appointment Management Interface: Teachers can set their availability and define
time slots for appointments.
 Database Interaction: Updates the availability in the schedule table in the database.

2.3 View Appointment

 Calendar Integration: Provides a calendar view of all booked appointments.

 Appointment Service: Fetches and displays appointments from the database.

2.4 View Message

 Messaging Service: Teachers can view messages from students.

 Notification Center: Displays unread messages and notifications.

3. Student Module

3.1 Registration/Login

 Registration Service: Allows new students to register by providing necessary details.

 Authentication Service: Manages student login with OAuth2 or JWT.
 Email Verification: Sends verification email upon registration.

3.2 Search Teacher

 Search Interface: Students can search for teachers based on subjects, availability, and other
criteria.
 Search Service: Interacts with the database to fetch and display relevant teacher profiles.

3.3 Book Appointment

 Booking Interface: Students can view available time slots and book appointments.
 Appointment Service: Manages booking requests, updates the schedule, and sends
confirmation notifications.
 Conflict Management: Ensures no double booking of the same time slot.

3.4 Send Message

 Messaging Interface: Students can send messages to teachers regarding appointments or other
queries.
 Messaging Service: Handles sending, receiving, and storing messages.
3 LOW LEVEL
DESIGN (LLD)

4. Unit Test Cases

Unit testing ensures that individual components of the system function correctly. Below are detailed
unit test cases for various components of the Student-Teacher Appointment Booking System.

1. Admin Module

1.1 Login

 Test Case 1: Successful Login

o Input: Valid admin credentials (username and password).
o Expected Output: Successful login, session created, and access to admin dashboard.

 Test Case 2: Failed Login

o Input: Invalid admin credentials (incorrect username or password).
o Expected Output: Login failure message and no session created.

1.2 Add Teacher

 Test Case 1: Add Teacher Successfully

o Input: Valid teacher details (name, email, subjects, availability).
o Expected Output: Teacher added to the database and confirmation message displayed.

 Test Case 2: Add Teacher with Missing Information

o Input: Incomplete teacher details (missing email).
o Expected Output: Error message indicating missing fields.

1.3 Manage Teacher

 Test Case 1: Update Teacher Details

o Input: Existing teacher ID and updated details.
o Expected Output: Teacher details updated in the database and confirmation message
displayed.

 Test Case 2: Delete Teacher

o Input: Existing teacher ID.
o Expected Output: Teacher record deleted from the database and confirmation message
displayed.

1.4 Approve Registration

 Test Case 1: Approve Pending Registration

o Input: Pending registration ID.
o Expected Output: Registration approved and notification sent to the teacher.
3 LOW LEVEL
DESIGN (LLD)
 Test Case 2: Reject Pending Registration
o Input: Pending registration ID.
o Expected Output: Registration rejected and notification sent to the teacher.

2. Teacher Module

2.1 Teacher Login

 Test Case 1: Successful Login

o Input: Valid teacher credentials (username and password).
o Expected Output: Successful login, session created, and access to teacher portal.

 Test Case 2: Failed Login

o Input: Invalid teacher credentials.
o Expected Output: Login failure message and no session created.

2.2 Schedule Appointment

 Test Case 1: Set Availability Successfully

o Input: Valid time slots and availability details.
o Expected Output: Availability set and confirmation message displayed.

 Test Case 2: Set Availability with Overlapping Slots

o Input: Overlapping time slots.
o Expected Output: Error message indicating conflict in availability.

2.3 View Appointment

 Test Case 1: View Scheduled Appointments

o Input: Teacher ID.
o Expected Output: List of scheduled appointments displayed.

2.4 View Message

 Test Case 1: View Received Messages

o Input: Teacher ID.
o Expected Output: List of received messages displayed.

3. Student Module

3.1 Registration/Login

 Test Case 1: Successful Registration

o Input: Valid student details (name, email, password).
o Expected Output: Student account created and verification email sent.

 Test Case 2: Failed Registration

3 LOW LEVEL
DESIGN (LLD)
o Input: Incomplete student details.
o Expected Output: Error message indicating missing fields.

 Test Case 3: Successful Login

o Input: Valid student credentials.
o Expected Output: Successful login, session created, and access to student portal.

 Test Case 4: Failed Login

o Input: Invalid student credentials.
o Expected Output: Login failure message and no session created.

3.2 Search Teacher

 Test Case 1: Search by Subject

o Input: Subject name.
o Expected Output: List of teachers who teach the specified subject.

 Test Case 2: Search by Availability

o Input: Date and time.
o Expected Output: List of teachers available at the specified time.

3.3 Book Appointment

 Test Case 1: Book Available Slot

o Input: Valid teacher ID and time slot.
o Expected Output: Appointment booked and confirmation message displayed.

 Test Case 2: Book Unavailable Slot

o Input: Teacher ID and time slot already booked.
o Expected Output: Error message indicating slot is unavailable.

3.4 Send Message

 Test Case 1: Send Message to Teacher

o Input: Valid teacher ID and message content.
o Expected Output: Message sent and confirmation displayed.

Common Test Cases for all Modules

 Test Case: Unauthorized Access

o Input: Attempt to access restricted page without proper authentication.
o Expected Output: Redirect to login page or access denied message.

 Test Case: Session Timeout

o Input: Session expiration.
o Expected Output: User redirected to login page with session timeout message.
3 LOW LEVEL
DESIGN (LLD)
Testing Frameworks and Tools

 JUnit: For unit testing in Java.

 Mockito: For mocking dependencies.
 Selenium: For automated UI testing.
 Postman: For API testing.
 AssertJ: For fluent assertions.

These unit test cases ensure that each component of the Student-Teacher Appointment Booking System
functions correctly and meets the expected requirements.