├── Assignment 14 ├── VOTING_RESULTS.md ├── LICENSE ├── README.md ├── REFLECTION.md ├── ROADMAP.md └── CONTRIBUTING.md ├── Assignment 12 ├── docs │ ├── SwaggerScreenshot.md │ └── openapi.yaml ├── api │ ├── tests │ │ ├── AppointmentApiTests.java │ │ ├── PatientApiTests.java │ │ └── DoctorApiTests.java │ ├── DoctorController.java │ ├── AppointmentController.java │ └── PatientController.java ├── services │ ├── DoctorService.java │ ├── PatientService.java │ ├── tests │ │ ├── AppointmentServiceTest.java │ │ ├── DoctorServiceTest.java │ │ └── PatientServiceTest.java │ └── AppointmentService.java ├── CHANGELOG.md └── README.md ├── Documentation ├── StakeholderAnalysisTable.md ├── Reflection.md ├── Use Case Diagram.md ├── Architecture.md ├── SystemRequirementsDocument.md ├── Specification.md ├── Agile Planning.md └── UseCase Specification.md ├── Assignment 11 ├── repositories │ ├── AppointmentRepository.java │ └── Repository.java ├── UpdatedClassDiagram.md ├── factories │ └── RepositoryFactory.java ├── inmemory │ ├── InMemoryAppointmentRepository.java │ └── tests │ │ └── InMemoryAppointmentRepositoryTest.java ├── database │ └── DatabaseAppointmentRepository.java └── README.md ├── Assignment 10 ├── test │ ├── PrototypeTest.java │ ├── PatientProfileTest.java │ ├── AbstractFactoryTest.java │ ├── coverage report.md │ ├── UserFactoryTest.java │ ├── AppointmentProcessorTest.java │ └── NotificationServiceTest.java ├── src │ ├── Notification.java │ ├── User.java │ ├── Admin.java │ ├── Doctor.java │ ├── Patient.java │ ├── Appointment.java │ └── README.md ├── creational_patterns │ ├── NotificationService.java │ ├── AbstractFactory.java │ ├── AppointmentProcessor.java │ ├── PatientProfile.java │ ├── UserFactory.java │ ├── Prototype.java │ └── README.md └── CHANGELOG.md ├── .github └── workflows │ └── ci.yml ├── Assignment 7 ├── template_analysis.md ├── reflection.md └── kanban_explanation.md ├── Protection.md ├── Assignment 8 ├── Reflection.md ├── State transition.md └── Activity Diagram.md ├── pom.xml ├── Assignment 9 ├── Reflection.md └── Domain Model Document.md ├── README.md ├── Capstone DesignPhase.md └── HospitalAppointmentSystem.java /Assignment 14/VOTING_RESULTS.md: -------------------------------------------------------------------------------- 1 | # RESULTS 2 | 3 | ![m](https://github.com/user-attachments/assets/43b8586c-b310-4836-aee6-d6f2cd9b594e) 4 | -------------------------------------------------------------------------------- /Assignment 12/docs/SwaggerScreenshot.md: -------------------------------------------------------------------------------- 1 | # Swagger Screenshot 2 | 3 | 4 | ![SwaggerImage May 3, 2025, 01_24_41 PM](https://github.com/user-attachments/assets/c9da1ade-b995-4d8d-b6a1-ff0c3cb1301a) 5 | -------------------------------------------------------------------------------- /Documentation/StakeholderAnalysisTable.md: -------------------------------------------------------------------------------- 1 | # STAKEHOLDER ANALYSIS TABLE 2 | 3 | This is a table that identifies key stakeholders, their roles, concerns, pain points, and success metrics. 4 | 5 | ![STAKEHOLDER ANALYSIS TABLE](https://github.com/user-attachments/assets/a3527ee2-06e1-4085-98cd-e23a7d685e1f) 6 | -------------------------------------------------------------------------------- /Assignment 11/repositories/AppointmentRepository.java: -------------------------------------------------------------------------------- 1 | package repositories; 2 | 3 | import hospitalappointmentsystem.Appointment; 4 | 5 | /** 6 | * Specific repository interface for Appointment entities. 7 | */ 8 | public interface AppointmentRepository extends Repository { 9 | // No extra methods needed for now 10 | } 11 | -------------------------------------------------------------------------------- /Assignment 11/repositories/Repository.java: -------------------------------------------------------------------------------- 1 | package repositories; 2 | 3 | import java.util.List; 4 | import java.util.Optional; 5 | 6 | /** 7 | * A generic Repository interface for basic CRUD operations. 8 | * 9 | * @param Entity type 10 | * @param ID type 11 | */ 12 | public interface Repository { 13 | void save(T entity); // Create/Update 14 | Optional findById(ID id); // Read (Single) 15 | List findAll(); // Read (All) 16 | void delete(ID id); // Delete 17 | } 18 | 19 | -------------------------------------------------------------------------------- /Assignment 14/LICENSE: -------------------------------------------------------------------------------- 1 | **LICENSE** 2 | 3 | ```plaintext 4 | MIT License 5 | 6 | Copyright (c) 2025 mbalitoh56 7 | 8 | Permission is hereby granted, free of charge, to any person obtaining a copy 9 | of this software and associated documentation files (the "Software"), to deal 10 | in the Software without restriction, including without limitation the rights 11 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 12 | copies of the Software, and to permit persons to whom the Software is 13 | furnished to do so, subject to the following conditions: 14 | 15 | ``` 16 | 17 | 18 | -------------------------------------------------------------------------------- /Assignment 11/UpdatedClassDiagram.md: -------------------------------------------------------------------------------- 1 | # Class Diagram (Repository Layer) 2 | 3 | 4 | ```mermaid 5 | classDiagram 6 | class Repository~T, ID~ { 7 | +void save(T entity) 8 | +Optional~T~ findById(ID id) 9 | +List~T~ findAll() 10 | +void delete(ID id) 11 | } 12 | 13 | class AppointmentRepository { 14 | } 15 | 16 | class InMemoryAppointmentRepository { 17 | } 18 | 19 | class DatabaseAppointmentRepository { 20 | } 21 | 22 | Repository <|-- AppointmentRepository 23 | AppointmentRepository <|-- InMemoryAppointmentRepository 24 | AppointmentRepository <|-- DatabaseAppointmentRepository 25 | ``` 26 | -------------------------------------------------------------------------------- /Assignment 11/factories/RepositoryFactory.java: -------------------------------------------------------------------------------- 1 | package factories; 2 | 3 | import repositories.AppointmentRepository; 4 | import repositories.inmemory.InMemoryAppointmentRepository; 5 | 6 | public class RepositoryFactory { 7 | 8 | public static AppointmentRepository getAppointmentRepository(String storageType) { 9 | switch (storageType.toUpperCase()) { 10 | case "MEMORY": 11 | return new InMemoryAppointmentRepository(); 12 | // case "DATABASE": 13 | // return new DatabaseAppointmentRepository(); // Future implementation 14 | default: 15 | throw new IllegalArgumentException("Invalid storage type: " + storageType); 16 | } 17 | } 18 | } 19 | -------------------------------------------------------------------------------- /Assignment 10/test/PrototypeTest.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/UnitTests/JUnit5TestClass.java to edit this template 4 | */ 5 | 6 | import org.junit.jupiter.api.BeforeAll; 7 | import org.junit.jupiter.api.Test; 8 | import static org.junit.jupiter.api.Assertions.*; 9 | 10 | /** 11 | * 12 | * @author Lenovo 13 | */ 14 | public class PrototypeTest { 15 | 16 | public PrototypeTest() { 17 | } 18 | 19 | @BeforeAll 20 | public static void setUpClass() { 21 | } 22 | 23 | @Test 24 | public void testSomeMethod() { 25 | fail("The test case is a prototype."); 26 | } 27 | 28 | } 29 | -------------------------------------------------------------------------------- /Assignment 12/api/tests/AppointmentApiTests.java: -------------------------------------------------------------------------------- 1 | @SpringBootTest 2 | @AutoConfigureMockMvc 3 | public class AppointmentApiTests { 4 | 5 | @Autowired 6 | private MockMvc mockMvc; 7 | 8 | @Test 9 | public void testGetAppointments() throws Exception { 10 | mockMvc.perform(get("/api/appointments")) 11 | .andExpect(status().isOk()); 12 | } 13 | 14 | @Test 15 | public void testCreateAppointment() throws Exception { 16 | String json = "{ \"doctorId\": \"D1\", \"patientId\": \"P1\", \"dateTime\": \"2025-06-01T10:00\" }"; 17 | mockMvc.perform(post("/api/appointments") 18 | .contentType(MediaType.APPLICATION_JSON) 19 | .content(json)) 20 | .andExpect(status().isOk()); 21 | } 22 | } 23 | -------------------------------------------------------------------------------- /Assignment 10/test/PatientProfileTest.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/UnitTests/JUnit5TestClass.java to edit this template 4 | */ 5 | 6 | import org.junit.jupiter.api.BeforeAll; 7 | import org.junit.jupiter.api.Test; 8 | import static org.junit.jupiter.api.Assertions.*; 9 | 10 | /** 11 | * 12 | * @author Lenovo 13 | */ 14 | public class PatientProfileTest { 15 | 16 | public PatientProfileTest() { 17 | } 18 | 19 | @BeforeAll 20 | public static void setUpClass() { 21 | } 22 | 23 | @Test 24 | public void testSomeMethod() { 25 | fail("The test case is a prototype."); 26 | } 27 | 28 | } 29 | -------------------------------------------------------------------------------- /Assignment 10/test/AbstractFactoryTest.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/UnitTests/JUnit5TestClass.java to edit this template 4 | */ 5 | 6 | import org.junit.jupiter.api.BeforeAll; 7 | import org.junit.jupiter.api.Test; 8 | import static org.junit.jupiter.api.Assertions.*; 9 | 10 | /** 11 | * 12 | * @author Lenovo 13 | */ 14 | public class AbstractFactoryTest { 15 | 16 | public AbstractFactoryTest() { 17 | } 18 | 19 | @BeforeAll 20 | public static void setUpClass() { 21 | } 22 | 23 | @Test 24 | public void testSomeMethod() { 25 | fail("The test case is a prototype."); 26 | } 27 | 28 | } 29 | -------------------------------------------------------------------------------- /Assignment 10/src/Notification.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/Classes/Class.java to edit this template 4 | */ 5 | 6 | /** 7 | * 8 | * @author Lenovo 9 | */ 10 | public class Notification { 11 | private String message; 12 | private String recipientId; 13 | 14 | public Notification(String message, String recipientId) { 15 | this.message = message; 16 | this.recipientId = recipientId; 17 | } 18 | 19 | public void send() { 20 | System.out.println("Notification sent to " + recipientId + ": " + message); 21 | } 22 | 23 | public void scheduleReminder() { 24 | System.out.println("Reminder scheduled for " + recipientId); 25 | } 26 | } 27 | -------------------------------------------------------------------------------- /Assignment 10/test/coverage report.md: -------------------------------------------------------------------------------- 1 | ### 📊 Coverage Report 2 | 3 | Use **JaCoCo** for coverage: 4 | 5 | 1. Add plugin in `pom.xml`: 6 | ```xml 7 | 8 | org.jacoco 9 | jacoco-maven-plugin 10 | 0.8.10 11 | 12 | 13 | 14 | prepare-agent 15 | 16 | 17 | 18 | report 19 | verify 20 | 21 | report 22 | 23 | 24 | 25 | 26 | ``` 27 | 28 | 2. Run: 29 | ```bash 30 | mvn clean verify 31 | ``` 32 | 33 | 3. Find reports under: 34 | ``` 35 | /target/site/jacoco/index.html 36 | ``` 37 | 38 | --- 39 | -------------------------------------------------------------------------------- /.github/workflows/ci.yml: -------------------------------------------------------------------------------- 1 | name: Java CI with Maven 2 | 3 | on: 4 | push: 5 | branches: 6 | - main 7 | 8 | jobs: 9 | build: 10 | runs-on: ubuntu-latest 11 | 12 | steps: 13 | - name: Checkout code 14 | uses: actions/checkout@v4 15 | 16 | - name: Set up JDK 17 17 | uses: actions/setup-java@v3 18 | with: 19 | java-version: '17' 20 | distribution: 'adoptopenjdk' 21 | 22 | - name: Build with Maven 23 | run: mvn clean package --file pom.xml 24 | 25 | - name: Upload JAR as artifact 26 | uses: actions/upload-artifact@v3 27 | with: 28 | name: hospital-appointment-system 29 | path: target/*.jar 30 | 31 | - name: Create Release and Upload JAR 32 | uses: softprops/action-gh-release@v1 33 | with: 34 | files: target/*.jar 35 | env: 36 | GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 37 | -------------------------------------------------------------------------------- /Assignment 10/creational_patterns/NotificationService.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/Classes/Class.java to edit this template 4 | */ 5 | 6 | /** 7 | * 8 | * @author Lenovo 9 | */ 10 | // NotificationService.java 11 | public class NotificationService { 12 | private static NotificationService instance; 13 | 14 | private NotificationService() { 15 | System.out.println("NotificationService initialized."); 16 | } 17 | 18 | public static NotificationService getInstance() { 19 | if (instance == null) { 20 | instance = new NotificationService(); 21 | } 22 | return instance; 23 | } 24 | 25 | public void sendNotification(String message) { 26 | System.out.println("Sending notification: " + message); 27 | } 28 | } -------------------------------------------------------------------------------- /Assignment 12/api/DoctorController.java: -------------------------------------------------------------------------------- 1 | @RestController 2 | @RequestMapping("/api/doctors") 3 | public class DoctorController { 4 | private final DoctorService doctorService; 5 | 6 | public DoctorController(DoctorService doctorService) { 7 | this.doctorService = doctorService; 8 | } 9 | 10 | @GetMapping 11 | public List getAllDoctors() { 12 | return doctorService.getAllDoctors(); 13 | } 14 | 15 | @PostMapping 16 | public Doctor createDoctor(@RequestBody Doctor doctor) { 17 | return doctorService.addDoctor(doctor); 18 | } 19 | 20 | @PutMapping("/{id}") 21 | public Doctor updateDoctor(@PathVariable String id, @RequestBody Doctor updatedDoctor) { 22 | return doctorService.updateDoctor(id, updatedDoctor); 23 | } 24 | 25 | @DeleteMapping("/{id}") 26 | public void deleteDoctor(@PathVariable String id) { 27 | doctorService.deleteDoctor(id); 28 | } 29 | } 30 | -------------------------------------------------------------------------------- /Assignment 10/test/UserFactoryTest.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/UnitTests/JUnit5TestClass.java to edit this template 4 | */ 5 | 6 | import org.junit.jupiter.api.BeforeAll; 7 | import org.junit.jupiter.api.Test; 8 | import static org.junit.jupiter.api.Assertions.*; 9 | 10 | /** 11 | * 12 | * @author Lenovo 13 | */ 14 | public class UserFactoryTest { 15 | 16 | public UserFactoryTest() { 17 | } 18 | 19 | @BeforeAll 20 | public static void setUpClass() { 21 | } 22 | 23 | /** 24 | * Test of createUser method, of class UserFactory. 25 | */ 26 | @Test 27 | public void testCreateUser() { 28 | User user = (User) UserFactory.createUser("Patient", "John"); 29 | assertTrue(user instanceof Patient); 30 | assertEquals("John", user.getName()); 31 | } 32 | 33 | } 34 | -------------------------------------------------------------------------------- /Assignment 10/src/User.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/Classes/Class.java to edit this template 4 | */ 5 | 6 | /** 7 | * 8 | * @author Lenovo 9 | */ 10 | public abstract class User { 11 | protected String userId; 12 | protected String name; 13 | protected String username; 14 | protected String password; 15 | 16 | public User(String userId, String name, String username, String password) { 17 | this.userId = userId; 18 | this.name = name; 19 | this.username = username; 20 | this.password = password; 21 | } 22 | 23 | public abstract void login(); 24 | public abstract void logout(); 25 | 26 | // Getters and Setters 27 | public String getUserId() { return userId; } 28 | public String getName() { return name; } 29 | public String getUsername() { return username; } 30 | } -------------------------------------------------------------------------------- /Assignment 10/src/Admin.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/Classes/Class.java to edit this template 4 | */ 5 | 6 | /** 7 | * 8 | * @author Lenovo 9 | */ 10 | public class Admin extends User { 11 | 12 | public Admin(String userId, String name, String username, String password) { 13 | super(userId, name, username, password); 14 | } 15 | 16 | @Override 17 | public void login() { 18 | System.out.println("Admin " + username + " logged in."); 19 | } 20 | 21 | @Override 22 | public void logout() { 23 | System.out.println("Admin " + username + " logged out."); 24 | } 25 | 26 | public void cancelAppointment(Appointment appointment) { 27 | System.out.println("Admin canceled appointment: " + appointment.getAppointmentId()); 28 | } 29 | 30 | public void manageUsers() { 31 | System.out.println("Admin managing users."); 32 | } 33 | } 34 | -------------------------------------------------------------------------------- /Assignment 10/src/Doctor.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/Classes/Class.java to edit this template 4 | */ 5 | 6 | /** 7 | * 8 | * @author Lenovo 9 | */ 10 | public class Doctor extends User { 11 | private String specialization; 12 | 13 | public Doctor(String userId, String name, String username, String password, String specialization) { 14 | super(userId, name, username, password); 15 | this.specialization = specialization; 16 | } 17 | 18 | @Override 19 | public void login() { 20 | System.out.println("Doctor " + username + " logged in."); 21 | } 22 | 23 | @Override 24 | public void logout() { 25 | System.out.println("Doctor " + username + " logged out."); 26 | } 27 | 28 | public void viewAppointments() { 29 | System.out.println("Doctor is viewing today's appointments."); 30 | } 31 | 32 | public String getSpecialization() { 33 | return specialization; 34 | } 35 | } 36 | -------------------------------------------------------------------------------- /Assignment 10/src/Patient.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/Classes/Class.java to edit this template 4 | */ 5 | 6 | /** 7 | * 8 | * @author Lenovo 9 | */ 10 | public class Patient extends User { 11 | public Patient(String userId, String name, String username, String password) { 12 | super(userId, name, username, password); 13 | } 14 | 15 | @Override 16 | public void login() { 17 | System.out.println("Patient " + username + " logged in."); 18 | } 19 | 20 | @Override 21 | public void logout() { 22 | System.out.println("Patient " + username + " logged out."); 23 | } 24 | 25 | public void bookAppointment(Appointment appointment) { 26 | System.out.println("Appointment booked: " + appointment.getAppointmentId()); 27 | } 28 | 29 | public void cancelAppointment(Appointment appointment) { 30 | System.out.println("Appointment canceled: " + appointment.getAppointmentId()); 31 | } 32 | 33 | } 34 | -------------------------------------------------------------------------------- /Assignment 12/api/AppointmentController.java: -------------------------------------------------------------------------------- 1 | // /api/controller/AppointmentController.java 2 | @RestController 3 | @RequestMapping("/api/appointments") 4 | public class AppointmentController { 5 | 6 | private final AppointmentService appointmentService; 7 | 8 | public AppointmentController(AppointmentService appointmentService) { 9 | this.appointmentService = appointmentService; 10 | } 11 | 12 | @GetMapping 13 | public List getAllAppointments() { 14 | return appointmentService.findAll(); 15 | } 16 | 17 | @PostMapping 18 | public Appointment createAppointment(@RequestBody Appointment appointment) { 19 | return appointmentService.save(appointment); 20 | } 21 | 22 | @PutMapping("/{id}") 23 | public Appointment updateAppointment(@PathVariable String id, @RequestBody Appointment updated) { 24 | return appointmentService.update(id, updated); 25 | } 26 | 27 | @PostMapping("/{id}/confirm") 28 | public ResponseEntity confirmAppointment(@PathVariable String id) { 29 | appointmentService.confirm(id); 30 | return ResponseEntity.ok("Appointment confirmed"); 31 | } 32 | } 33 | -------------------------------------------------------------------------------- /Assignment 12/services/DoctorService.java: -------------------------------------------------------------------------------- 1 | package com.hospital.services; 2 | 3 | import com.hospital.models.Doctor; 4 | import com.hospital.repositories.DoctorRepository; 5 | import java.util.List; 6 | 7 | public class DoctorService { 8 | private final DoctorRepository doctorRepo; 9 | 10 | public DoctorService(DoctorRepository doctorRepo) { 11 | this.doctorRepo = doctorRepo; 12 | } 13 | 14 | public Doctor addDoctor(Doctor doctor) { 15 | // Business logic to add a new doctor (e.g., check if the doctor already exists) 16 | List doctors = doctorRepo.findAll(); 17 | if (doctors.stream().anyMatch(d -> d.getLicenseNumber().equals(doctor.getLicenseNumber()))) { 18 | throw new IllegalArgumentException("Doctor with this license number already exists"); 19 | } 20 | return doctorRepo.save(doctor); 21 | } 22 | 23 | public Doctor getDoctorById(String doctorId) { 24 | return doctorRepo.findById(doctorId) 25 | .orElseThrow(() -> new RuntimeException("Doctor not found")); 26 | } 27 | 28 | public List getAllDoctors() { 29 | return doctorRepo.findAll(); 30 | } 31 | } 32 | -------------------------------------------------------------------------------- /Assignment 12/services/PatientService.java: -------------------------------------------------------------------------------- 1 | package com.hospital.services; 2 | 3 | import com.hospital.models.Patient; 4 | import com.hospital.repositories.PatientRepository; 5 | import java.util.Optional; 6 | 7 | public class PatientService { 8 | private final PatientRepository patientRepo; 9 | 10 | public PatientService(PatientRepository patientRepo) { 11 | this.patientRepo = patientRepo; 12 | } 13 | 14 | public Patient addPatient(Patient patient) { 15 | // Business logic for adding a new patient (e.g., validate age) 16 | if (patient.getAge() < 0) { 17 | throw new IllegalArgumentException("Age cannot be negative"); 18 | } 19 | return patientRepo.save(patient); 20 | } 21 | 22 | public Patient getPatientById(String patientId) { 23 | return patientRepo.findById(patientId) 24 | .orElseThrow(() -> new RuntimeException("Patient not found")); 25 | } 26 | 27 | public void removePatient(String patientId) { 28 | Patient patient = patientRepo.findById(patientId) 29 | .orElseThrow(() -> new RuntimeException("Patient not found")); 30 | patientRepo.delete(patientId); 31 | } 32 | } 33 | -------------------------------------------------------------------------------- /Assignment 11/inmemory/InMemoryAppointmentRepository.java: -------------------------------------------------------------------------------- 1 | package repositories.inmemory; 2 | 3 | import hospitalappointmentsystem.Appointment; 4 | import repositories.AppointmentRepository; 5 | 6 | import java.util.*; 7 | 8 | /** 9 | * In-memory implementation of AppointmentRepository. 10 | */ 11 | public class InMemoryAppointmentRepository implements AppointmentRepository { 12 | private final Map storage = new HashMap<>(); 13 | 14 | @Override 15 | public void save(Appointment appointment) { 16 | String key = generateKey(appointment); 17 | storage.put(key, appointment); 18 | } 19 | 20 | @Override 21 | public Optional findById(String id) { 22 | return Optional.ofNullable(storage.get(id)); 23 | } 24 | 25 | @Override 26 | public List findAll() { 27 | return new ArrayList<>(storage.values()); 28 | } 29 | 30 | @Override 31 | public void delete(String id) { 32 | storage.remove(id); 33 | } 34 | 35 | private String generateKey(Appointment appointment) { 36 | // Unique key based on doctor, date, and time 37 | return appointment.doctorName + "_" + appointment.date + "_" + appointment.time; 38 | } 39 | } 40 | -------------------------------------------------------------------------------- /Assignment 11/inmemory/tests/InMemoryAppointmentRepositoryTest.java: -------------------------------------------------------------------------------- 1 | package repositories.inmemory; 2 | 3 | import hospitalappointmentsystem.Appointment; 4 | import org.junit.jupiter.api.Test; 5 | 6 | import java.util.Optional; 7 | import java.util.List; 8 | 9 | import static org.junit.jupiter.api.Assertions.*; 10 | 11 | class InMemoryAppointmentRepositoryTest { 12 | 13 | @Test 14 | void testCRUDOperations() { 15 | InMemoryAppointmentRepository repo = new InMemoryAppointmentRepository(); 16 | 17 | // Create and Save 18 | Appointment appointment = new Appointment("John Doe", "Dr. Smith", "2025-05-01", "10:00", "Check-up"); 19 | repo.save(appointment); 20 | 21 | // Read - findById 22 | String id = "Dr. Smith_2025-05-01_10:00"; 23 | Optional found = repo.findById(id); 24 | assertTrue(found.isPresent()); 25 | assertEquals("John Doe", found.get().patientName); 26 | 27 | // Read - findAll 28 | List all = repo.findAll(); 29 | assertEquals(1, all.size()); 30 | 31 | // Delete 32 | repo.delete(id); 33 | Optional afterDelete = repo.findById(id); 34 | assertFalse(afterDelete.isPresent()); 35 | } 36 | } 37 | -------------------------------------------------------------------------------- /Assignment 10/test/AppointmentProcessorTest.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/UnitTests/JUnit5TestClass.java to edit this template 4 | */ 5 | 6 | import org.junit.jupiter.api.BeforeAll; 7 | import org.junit.jupiter.api.Test; 8 | import static org.junit.jupiter.api.Assertions.*; 9 | 10 | /** 11 | * 12 | * @author Lenovo 13 | */ 14 | public class AppointmentProcessorTest { 15 | 16 | public AppointmentProcessorTest() { 17 | } 18 | 19 | @BeforeAll 20 | public static void setUpClass() { 21 | } 22 | 23 | /** 24 | * Test of processAppointment method, of class AppointmentProcessor. 25 | */ 26 | @Test 27 | public void testProcessAppointment() { 28 | System.out.println("processAppointment"); 29 | AppointmentProcessor instance = new AppointmentProcessorImpl(); 30 | instance.processAppointment(); 31 | fail("The test case is a prototype."); 32 | } 33 | 34 | public class AppointmentProcessorImpl implements AppointmentProcessor { 35 | 36 | public void processAppointment() { 37 | } 38 | } 39 | 40 | } 41 | -------------------------------------------------------------------------------- /Assignment 11/database/DatabaseAppointmentRepository.java: -------------------------------------------------------------------------------- 1 | package repositories.database; 2 | 3 | import models.Appointment; 4 | import repositories.AppointmentRepository; 5 | 6 | import java.util.List; 7 | import java.util.Optional; 8 | 9 | public class DatabaseAppointmentRepository implements AppointmentRepository { 10 | 11 | @Override 12 | public void save(Appointment entity) { 13 | // TODO: Implement saving to database (e.g., SQL INSERT) 14 | throw new UnsupportedOperationException("Database storage not yet implemented."); 15 | } 16 | 17 | @Override 18 | public Optional findById(String id) { 19 | // TODO: Implement finding by ID from database (e.g., SQL SELECT) 20 | throw new UnsupportedOperationException("Database storage not yet implemented."); 21 | } 22 | 23 | @Override 24 | public List findAll() { 25 | // TODO: Implement fetching all appointments from database 26 | throw new UnsupportedOperationException("Database storage not yet implemented."); 27 | } 28 | 29 | @Override 30 | public void delete(String id) { 31 | // TODO: Implement deleting from database 32 | throw new UnsupportedOperationException("Database storage not yet implemented."); 33 | } 34 | } 35 | -------------------------------------------------------------------------------- /Assignment 7/template_analysis.md: -------------------------------------------------------------------------------- 1 | # Comparison Table 2 | 3 | | Template | Columns & Workflows | Automation Features | Agile Suitability | 4 | |---------------------|--------------------------------------|----------------------------------------------|----------------------------------------| 5 | | **Basic Kanban** | "To Do," "In Progress," "Done" | Manual issue movement | Suitable for simple Agile workflows, but lacks automation for sprints. | 6 | | **Automated Kanban**| "To Do," "In Progress," "Done" | Auto-moves issues based on commits and PRs | Ideal for Agile teams tracking sprint progress efficiently. | 7 | | **Bug Triage** | "New," "Needs Triage," "In Progress," "Closed" | Auto-labels and prioritizes issues | Useful for Agile bug tracking but not for full project management. | 8 | 9 | 10 | # Justification for Selection 11 | 12 | For the Hospital Appointment Scheduling System, the best choice is **Automated Kanban** because: 13 | 14 | - It supports sprint tracking with built-in automation. 15 | 16 | - Issues move automatically based on PRs and commits, reducing manual effort. 17 | 18 | - It aligns well with Agile principles by enabling continuous tracking and iteration. 19 | -------------------------------------------------------------------------------- /Assignment 12/api/tests/PatientApiTests.java: -------------------------------------------------------------------------------- 1 | package com.hospital.api; 2 | 3 | import org.junit.jupiter.api.Test; 4 | import org.springframework.beans.factory.annotation.Autowired; 5 | import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc; 6 | import org.springframework.boot.test.context.SpringBootTest; 7 | import org.springframework.http.MediaType; 8 | import org.springframework.test.web.servlet.MockMvc; 9 | 10 | import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*; 11 | import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*; 12 | 13 | @SpringBootTest 14 | @AutoConfigureMockMvc 15 | public class PatientApiTests { 16 | 17 | @Autowired 18 | private MockMvc mockMvc; 19 | 20 | @Test 21 | public void testGetPatients() throws Exception { 22 | mockMvc.perform(get("/api/patients")) 23 | .andExpect(status().isOk()); 24 | } 25 | 26 | @Test 27 | public void testCreatePatient() throws Exception { 28 | String json = "{ \"id\": \"P1\", \"name\": \"John Doe\" }"; 29 | mockMvc.perform(post("/api/patients") 30 | .contentType(MediaType.APPLICATION_JSON) 31 | .content(json)) 32 | .andExpect(status().isOk()); 33 | } 34 | } 35 | -------------------------------------------------------------------------------- /Assignment 10/CHANGELOG.md: -------------------------------------------------------------------------------- 1 | # CHANGELOG 2 | 3 | ## [v1.0.0] - 2025-04-19 4 | 5 | ### Added 6 | - Implemented all six creational design patterns: 7 | - Singleton: Ensured thread-safe instance for DatabaseConnection. 8 | - Simple Factory: Created AppointmentFactory to generate various appointment types. 9 | - Factory Method: Used NotificationFactory to delegate email and SMS instantiation. 10 | - Abstract Factory: Designed UserUIFactory to return GUI elements based on user roles. 11 | - Builder: Developed DoctorBuilder for customizable Doctor profiles. 12 | - Prototype: Built AppointmentPrototypeRegistry for cloning appointment templates. 13 | 14 | ### Testing 15 | - Added BookingWorkflowTest to simulate the appointment lifecycle. 16 | - Implemented test coverage for all patterns. 17 | - Verified thread safety, invalid input handling, and attribute initialization. 18 | 19 | ### Changed 20 | - Refactored file structure under `/creational_patterns`. 21 | - Grouped pattern implementations with appropriate Java classes. 22 | 23 | ### Known Issues 24 | - Need better error handling in DoctorBuilder for null specialties. 25 | - Prototype pattern lacks support for deep cloning nested objects. 26 | 27 | ### Upcoming 28 | - File-based persistence (appointments.txt) to be added. 29 | - UI integration planned for demonstration of pattern interactions. 30 | 31 | -------------------------------------------------------------------------------- /Assignment 12/api/PatientController.java: -------------------------------------------------------------------------------- 1 | package api; 2 | 3 | import models.Patient; 4 | import org.springframework.http.ResponseEntity; 5 | import org.springframework.web.bind.annotation.*; 6 | import services.PatientService; 7 | 8 | import java.util.List; 9 | 10 | @RestController 11 | @RequestMapping("/api/patients") 12 | public class PatientController { 13 | private final PatientService patientService; 14 | 15 | public PatientController(PatientService patientService) { 16 | this.patientService = patientService; 17 | } 18 | 19 | @GetMapping 20 | public ResponseEntity> getAllPatients() { 21 | return ResponseEntity.ok(patientService.findAllPatients()); 22 | } 23 | 24 | @PostMapping 25 | public ResponseEntity createPatient(@RequestBody Patient patient) { 26 | return ResponseEntity.ok(patientService.createPatient(patient)); 27 | } 28 | 29 | @PutMapping("/{id}") 30 | public ResponseEntity updatePatient(@PathVariable String id, @RequestBody Patient patient) { 31 | patient.setId(id); 32 | return ResponseEntity.ok(patientService.updatePatient(patient)); 33 | } 34 | 35 | @DeleteMapping("/{id}") 36 | public ResponseEntity deletePatient(@PathVariable String id) { 37 | patientService.deletePatient(id); 38 | return ResponseEntity.ok().build(); 39 | } 40 | } 41 | -------------------------------------------------------------------------------- /Assignment 12/services/tests/AppointmentServiceTest.java: -------------------------------------------------------------------------------- 1 | package tests; 2 | 3 | import services.AppointmentService; 4 | import repositories.inmemory.InMemoryAppointmentRepository; 5 | import repositories.inmemory.InMemoryPatientRepository; 6 | import entities.Appointment; 7 | import entities.Patient; 8 | 9 | import java.util.UUID; 10 | 11 | public class AppointmentServiceTest { 12 | public static void main(String[] args) { 13 | var patientRepo = new InMemoryPatientRepository(); 14 | var appointmentRepo = new InMemoryAppointmentRepository(); 15 | var service = new AppointmentService(appointmentRepo, patientRepo); 16 | 17 | String patientId = UUID.randomUUID().toString(); 18 | patientRepo.save(new Patient(patientId, "Alice")); 19 | 20 | // Book 3 appointments 21 | for (int i = 0; i < 3; i++) { 22 | service.bookAppointment(patientId, new Appointment(UUID.randomUUID().toString(), "Doctor A", "Pending")); 23 | } 24 | 25 | // 4th booking should throw error 26 | try { 27 | service.bookAppointment(patientId, new Appointment(UUID.randomUUID().toString(), "Doctor A", "Pending")); 28 | System.out.println("Test failed: Limit not enforced"); 29 | } catch (IllegalStateException e) { 30 | System.out.println("Test passed: " + e.getMessage()); 31 | } 32 | } 33 | } 34 | -------------------------------------------------------------------------------- /Assignment 12/CHANGELOG.md: -------------------------------------------------------------------------------- 1 | # CHANGELOG 2 | 3 | ## [v1.0.0] - 2025-05-03 4 | 5 | ### Features 6 | - Added RESTful API endpoints for core entities: 7 | - `GET /api/patients` - Fetch all patients 8 | - `POST /api/patients` - Register a new patient 9 | - `PUT /api/patients/{id}` - Update patient details 10 | - `GET /api/doctors` - List all doctors 11 | - `POST /api/appointments` - Book a new appointment 12 | - `POST /api/appointments/{id}/cancel` - Cancel an appointment 13 | - Integrated Swagger (OpenAPI) UI at `/swagger-ui.html` for documentation and testing 14 | - Implemented in-memory storage for all repositories 15 | - Business logic added to service layer: 16 | - Validate patient input 17 | - Prevent booking if doctor is unavailable 18 | - Limit patients to one appointment at a time slot 19 | 20 | ### Fixes 21 | - **#20**: Fixed `NullPointerException` when email is missing during patient registration 22 | - **#21**: AppointmentService now validates doctor availability before booking 23 | - **#22**: Refactored `bookAppointment()` method to improve code readability and maintainability 24 | 25 | ### Improvements 26 | - Unit tests added for `PatientService`, `DoctorService`, and `AppointmentService` 27 | - Created Factory pattern to abstract repository instantiation for future support (e.g., file system, database) 28 | - Added support for linking tasks to GitHub Issues using `git commit -m "Close #XX: ..."` 29 | 30 | 31 | -------------------------------------------------------------------------------- /Assignment 10/creational_patterns/AbstractFactory.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/Classes/Class.java to edit this template 4 | */ 5 | 6 | /** 7 | * 8 | * @author Lenovo 9 | */ 10 | public class AbstractFactory { 11 | // Button.java 12 | public interface Button { 13 | void render(); 14 | } 15 | 16 | // PublicHospitalButton.java 17 | public class PublicHospitalButton implements Button { 18 | public void render() { 19 | System.out.println("Rendering Public Hospital Button"); 20 | } 21 | } 22 | 23 | // PrivateHospitalButton.java 24 | public class PrivateHospitalButton implements Button { 25 | public void render() { 26 | System.out.println("Rendering Private Hospital Button"); 27 | } 28 | } 29 | 30 | // UIFactory.java 31 | public interface UIFactory { 32 | Button createButton(); 33 | } 34 | 35 | // PublicHospitalUIFactory.java 36 | public class PublicHospitalUIFactory implements UIFactory { 37 | public Button createButton() { 38 | return new PublicHospitalButton(); 39 | } 40 | } 41 | 42 | // PrivateHospitalUIFactory.java 43 | public class PrivateHospitalUIFactory implements UIFactory { 44 | public Button createButton() { 45 | return new PrivateHospitalButton(); 46 | } 47 | } 48 | } 49 | -------------------------------------------------------------------------------- /Assignment 12/services/AppointmentService.java: -------------------------------------------------------------------------------- 1 | package services; 2 | 3 | import entities.Appointment; 4 | import entities.Patient; 5 | import repositories.AppointmentRepository; 6 | import repositories.PatientRepository; 7 | 8 | import java.util.List; 9 | 10 | public class AppointmentService { 11 | private final AppointmentRepository appointmentRepo; 12 | private final PatientRepository patientRepo; 13 | 14 | public AppointmentService(AppointmentRepository appointmentRepo, PatientRepository patientRepo) { 15 | this.appointmentRepo = appointmentRepo; 16 | this.patientRepo = patientRepo; 17 | } 18 | 19 | public Appointment bookAppointment(String patientId, Appointment appointment) { 20 | Patient patient = patientRepo.findById(patientId) 21 | .orElseThrow(() -> new IllegalArgumentException("Patient not found")); 22 | 23 | List existing = appointmentRepo.findByPatientId(patientId); 24 | long activeCount = existing.stream() 25 | .filter(a -> !a.getStatus().equals("Completed")) 26 | .count(); 27 | 28 | if (activeCount >= 3) { 29 | throw new IllegalStateException("Patient has reached the appointment limit."); 30 | } 31 | 32 | appointment.setPatientId(patientId); 33 | appointment.setStatus("Scheduled"); 34 | 35 | appointmentRepo.save(appointment); 36 | return appointment; 37 | } 38 | } 39 | -------------------------------------------------------------------------------- /Assignment 10/test/NotificationServiceTest.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/UnitTests/JUnit5TestClass.java to edit this template 4 | */ 5 | 6 | import org.junit.jupiter.api.BeforeAll; 7 | import org.junit.jupiter.api.Test; 8 | import static org.junit.jupiter.api.Assertions.*; 9 | 10 | /** 11 | * 12 | * @author Lenovo 13 | */ 14 | public class NotificationServiceTest { 15 | 16 | public NotificationServiceTest() { 17 | } 18 | 19 | @BeforeAll 20 | public static void setUpClass() { 21 | } 22 | 23 | /** 24 | * Test of getInstance method, of class NotificationService. 25 | */ 26 | @Test 27 | public void testGetInstance() { 28 | System.out.println("getInstance"); 29 | NotificationService expResult = null; 30 | NotificationService result = NotificationService.getInstance(); 31 | assertEquals(expResult, result); 32 | fail("The test case is a prototype."); 33 | } 34 | 35 | /** 36 | * Test of sendNotification method, of class NotificationService. 37 | */ 38 | @Test 39 | public void testSendNotification() { 40 | System.out.println("sendNotification"); 41 | String message = ""; 42 | NotificationService instance = null; 43 | instance.sendNotification(message); 44 | fail("The test case is a prototype."); 45 | } 46 | 47 | } 48 | -------------------------------------------------------------------------------- /Assignment 10/creational_patterns/AppointmentProcessor.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/Classes/Class.java to edit this template 4 | */ 5 | 6 | /** 7 | * 8 | * @author Lenovo 9 | */ 10 | // AppointmentProcessor.java 11 | public interface AppointmentProcessor { 12 | void processAppointment(); 13 | 14 | 15 | // RegularAppointment.java 16 | public class RegularAppointment implements AppointmentProcessor { 17 | public void processAppointment() { 18 | System.out.println("Processing regular appointment."); 19 | } 20 | } 21 | 22 | // EmergencyAppointment.java 23 | public class EmergencyAppointment implements AppointmentProcessor { 24 | public void processAppointment() { 25 | System.out.println("Processing emergency appointment."); 26 | } 27 | } 28 | 29 | // AppointmentCreator.java 30 | public abstract class AppointmentCreator { 31 | public abstract AppointmentProcessor createAppointment(); 32 | } 33 | 34 | // RegularAppointmentCreator.java 35 | public class RegularAppointmentCreator extends AppointmentCreator { 36 | public AppointmentProcessor createAppointment() { 37 | return new RegularAppointment(); 38 | } 39 | } 40 | 41 | // EmergencyAppointmentCreator.java 42 | public class EmergencyAppointmentCreator extends AppointmentCreator { 43 | public AppointmentProcessor createAppointment() { 44 | return new EmergencyAppointment(); 45 | } 46 | }} 47 | -------------------------------------------------------------------------------- /Assignment 10/src/Appointment.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/Classes/Class.java to edit this template 4 | */ 5 | 6 | /** 7 | * 8 | * @author Lenovo 9 | */ 10 | import java.time.LocalDateTime; 11 | 12 | public class Appointment { 13 | private String appointmentId; 14 | private LocalDateTime dateTime; 15 | private Doctor doctor; 16 | private Patient patient; 17 | private String status; // e.g., Scheduled, Cancelled 18 | 19 | public Appointment(String appointmentId, LocalDateTime dateTime, Doctor doctor, Patient patient) { 20 | this.appointmentId = appointmentId; 21 | this.dateTime = dateTime; 22 | this.doctor = doctor; 23 | this.patient = patient; 24 | this.status = "Scheduled"; 25 | } 26 | 27 | public void confirm() { 28 | this.status = "Confirmed"; 29 | System.out.println("Appointment confirmed."); 30 | } 31 | 32 | public void cancel() { 33 | this.status = "Cancelled"; 34 | System.out.println("Appointment cancelled."); 35 | } 36 | 37 | public String getAppointmentId() { 38 | return appointmentId; 39 | } 40 | 41 | public LocalDateTime getDateTime() { 42 | return dateTime; 43 | } 44 | 45 | public Doctor getDoctor() { 46 | return doctor; 47 | } 48 | 49 | public Patient getPatient() { 50 | return patient; 51 | } 52 | 53 | public String getStatus() { 54 | return status; 55 | } 56 | } -------------------------------------------------------------------------------- /Assignment 10/creational_patterns/PatientProfile.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/Classes/Class.java to edit this template 4 | */ 5 | 6 | /** 7 | * 8 | * @author Lenovo 9 | */ 10 | // PatientProfile.java 11 | public class PatientProfile { 12 | private String name; 13 | private int age; 14 | private String allergies; 15 | private String chronicConditions; 16 | 17 | public static class Builder { 18 | private final String name; 19 | private int age; 20 | private String allergies = ""; 21 | private String chronicConditions = ""; 22 | 23 | public Builder(String name) { 24 | this.name = name; 25 | } 26 | 27 | public Builder age(int age) { 28 | this.age = age; 29 | return this; 30 | } 31 | 32 | public Builder allergies(String allergies) { 33 | this.allergies = allergies; 34 | return this; 35 | } 36 | 37 | public Builder chronicConditions(String chronicConditions) { 38 | this.chronicConditions = chronicConditions; 39 | return this; 40 | } 41 | 42 | public PatientProfile build() { 43 | PatientProfile profile = new PatientProfile(); 44 | profile.name = this.name; 45 | profile.age = this.age; 46 | profile.allergies = this.allergies; 47 | profile.chronicConditions = this.chronicConditions; 48 | return profile; 49 | } 50 | } 51 | } 52 | -------------------------------------------------------------------------------- /Assignment 10/creational_patterns/UserFactory.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/Classes/Class.java to edit this template 4 | */ 5 | 6 | /** 7 | * 8 | * @author Lenovo 9 | */ 10 | 11 | // UserFactory.java 12 | public class UserFactory { 13 | 14 | static User createUser(String patient, String john) { 15 | throw new UnsupportedOperationException("Not supported yet."); // Generated from nbfs://nbhost/SystemFileSystem/Templates/Classes/Code/GeneratedMethodBody 16 | } 17 | public User createUser(String role) { 18 | switch (role.toLowerCase()) { 19 | case "patient": return new Patient(); 20 | case "doctor": return new Doctor(); 21 | case "admin": return new Admin(); 22 | default: throw new IllegalArgumentException("Invalid role: " + role); 23 | } 24 | } 25 | 26 | 27 | // User.java 28 | public interface User { 29 | void accessSystem(); 30 | } 31 | 32 | // Patient.java 33 | public class Patient implements User { 34 | public void accessSystem() { 35 | System.out.println("Patient accessing the appointment system."); 36 | } 37 | } 38 | 39 | // Doctor.java 40 | public class Doctor implements User { 41 | public void accessSystem() { 42 | System.out.println("Doctor accessing appointment schedule."); 43 | } 44 | } 45 | 46 | // Admin.java 47 | public class Admin implements User { 48 | public void accessSystem() { 49 | System.out.println("Admin managing the hospital system."); 50 | } 51 | } 52 | } -------------------------------------------------------------------------------- /Assignment 12/services/tests/DoctorServiceTest.java: -------------------------------------------------------------------------------- 1 | package com.hospital.services; 2 | 3 | import com.hospital.models.Doctor; 4 | import com.hospital.repositories.inmemory.InMemoryDoctorRepository; 5 | import org.junit.jupiter.api.BeforeEach; 6 | import org.junit.jupiter.api.Test; 7 | 8 | import static org.junit.jupiter.api.Assertions.*; 9 | 10 | class DoctorServiceTest { 11 | private DoctorService doctorService; 12 | private InMemoryDoctorRepository doctorRepo; 13 | 14 | @BeforeEach 15 | void setUp() { 16 | doctorRepo = new InMemoryDoctorRepository(); 17 | doctorService = new DoctorService(doctorRepo); 18 | } 19 | 20 | @Test 21 | void testAddDoctor() { 22 | Doctor doctor = new Doctor("1", "Dr. Smith", "ABC123"); 23 | Doctor savedDoctor = doctorService.addDoctor(doctor); 24 | 25 | assertEquals(doctor, savedDoctor); 26 | } 27 | 28 | @Test 29 | void testAddDoctorWithDuplicateLicense() { 30 | Doctor doctor1 = new Doctor("1", "Dr. Smith", "ABC123"); 31 | Doctor doctor2 = new Doctor("2", "Dr. Lee", "ABC123"); 32 | doctorService.addDoctor(doctor1); 33 | 34 | IllegalArgumentException thrown = assertThrows(IllegalArgumentException.class, () -> { 35 | doctorService.addDoctor(doctor2); 36 | }); 37 | assertEquals("Doctor with this license number already exists", thrown.getMessage()); 38 | } 39 | 40 | @Test 41 | void testGetDoctorById() { 42 | Doctor doctor = new Doctor("3", "Dr. Jones", "XYZ789"); 43 | doctorService.addDoctor(doctor); 44 | 45 | Doctor fetchedDoctor = doctorService.getDoctorById("3"); 46 | assertEquals(doctor, fetchedDoctor); 47 | } 48 | } 49 | -------------------------------------------------------------------------------- /Assignment 12/api/tests/DoctorApiTests.java: -------------------------------------------------------------------------------- 1 | package com.hospital.api; 2 | 3 | import org.junit.jupiter.api.Test; 4 | import org.springframework.beans.factory.annotation.Autowired; 5 | import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc; 6 | import org.springframework.boot.test.context.SpringBootTest; 7 | import org.springframework.http.MediaType; 8 | import org.springframework.test.web.servlet.MockMvc; 9 | 10 | import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*; 11 | import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*; 12 | 13 | @SpringBootTest 14 | @AutoConfigureMockMvc 15 | public class DoctorApiTests { 16 | 17 | @Autowired 18 | private MockMvc mockMvc; 19 | 20 | @Test 21 | public void testGetDoctors() throws Exception { 22 | mockMvc.perform(get("/api/doctors")) 23 | .andExpect(status().isOk()); 24 | } 25 | 26 | @Test 27 | public void testCreateDoctor() throws Exception { 28 | String json = "{ \"id\": \"D1\", \"name\": \"Dr. House\", \"specialization\": \"Diagnostics\" }"; 29 | 30 | mockMvc.perform(post("/api/doctors") 31 | .contentType(MediaType.APPLICATION_JSON) 32 | .content(json)) 33 | .andExpect(status().isOk()); 34 | } 35 | 36 | @Test 37 | public void testUpdateDoctor() throws Exception { 38 | String json = "{ \"id\": \"D1\", \"name\": \"Dr. Wilson\", \"specialization\": \"Oncology\" }"; 39 | 40 | mockMvc.perform(put("/api/doctors/D1") 41 | .contentType(MediaType.APPLICATION_JSON) 42 | .content(json)) 43 | .andExpect(status().isOk()); 44 | } 45 | } 46 | -------------------------------------------------------------------------------- /Assignment 10/creational_patterns/Prototype.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/Classes/Class.java to edit this template 4 | */ 5 | import java.util.HashMap; 6 | /** 7 | * 8 | * @author Lenovo 9 | */ 10 | public class Prototype { 11 | 12 | // Schedule.java 13 | public abstract class Schedule implements Cloneable { 14 | protected String doctorName; 15 | protected String timeSlot; 16 | 17 | public void setDoctorName(String name) { 18 | this.doctorName = name; 19 | } 20 | 21 | public void setTimeSlot(String slot) { 22 | this.timeSlot = slot; 23 | } 24 | 25 | public abstract void showSchedule(); 26 | 27 | public Schedule clone() { 28 | try { 29 | return (Schedule) super.clone(); 30 | } catch (CloneNotSupportedException e) { 31 | return null; 32 | } 33 | } 34 | } 35 | 36 | // WeeklySchedule.java 37 | public class WeeklySchedule extends Schedule { 38 | public void showSchedule() { 39 | System.out.println("Doctor " + doctorName + " - Weekly Schedule: " + timeSlot); 40 | } 41 | } 42 | 43 | // ScheduleCache.java 44 | 45 | public class ScheduleCache { 46 | private static HashMap scheduleMap = new HashMap<>(); 47 | 48 | public void loadCache() { 49 | WeeklySchedule weekly = new WeeklySchedule(); 50 | weekly.setDoctorName("Dr. Smith"); 51 | weekly.setTimeSlot("Mon-Fri 10AM-2PM"); 52 | scheduleMap.put("weekly", weekly); 53 | } 54 | 55 | public static Schedule getSchedule(String id) { 56 | return scheduleMap.get(id).clone(); 57 | } 58 | } 59 | } 60 | -------------------------------------------------------------------------------- /Assignment 7/reflection.md: -------------------------------------------------------------------------------- 1 | # **Reflection** 2 | 3 | ### **Challenges in Selecting and Customizing the Template** 4 | 5 | **Choosing the Right Template** 6 | 7 | - GitHub offers multiple templates like **Basic Kanban, Automated Kanban, and Bug Triage**. 8 | - The challenge was selecting the most suitable one for our **Hospital Appointment Scheduling System**. 9 | - We chose **Automated Kanban** because it provides **built-in issue tracking and workflow automation**. 10 | 11 | **Customization Difficulties** 12 | 13 | - **Adding new columns:** Creating **"Testing"** and **"Blocked"** required adjusting workflows. 14 | - **Managing automation:** Some tasks moved automatically, but others needed manual updates. 15 | - **WIP Limit Implementation:** Unlike Jira, GitHub does not enforce WIP limits, so we had to track them manually. 16 | 17 | ### **Comparing GitHub’s Templates to Other Tools** 18 | 19 | | Feature | GitHub Projects | Trello | Jira | 20 | |--------------|---------------|--------|------| 21 | | **Ease of Use** | ✅ Simple, but limited automation | ✅ Drag-and-drop, intuitive | ❌ Complex, steep learning curve | 22 | | **Automation** | ✅ Some built-in automation | ❌ Mostly manual | ✅ Advanced workflow automation | 23 | | **Integration** | ✅ Strong with GitHub | ✅ Supports many third-party tools | ✅ Deep integration with CI/CD | 24 | | **Customization** | ⚠️ Limited (fixed column structure) | ✅ Highly flexible | ✅ Advanced, but complex | 25 | | **Best For** | **Developers using GitHub** | **Small teams, general tasks** | **Agile teams, complex projects** | 26 | 27 | ### **Key Takeaways** 28 | - **GitHub Projects** is best for teams already using GitHub but lacks **advanced automation**. 29 | - **Trello** is more **flexible and user-friendly** but has **less automation**. 30 | - **Jira** is the most **powerful for Agile workflows** but requires **more setup and learning**. 31 | 32 | -------------------------------------------------------------------------------- /Assignment 12/services/tests/PatientServiceTest.java: -------------------------------------------------------------------------------- 1 | package com.hospital.services; 2 | 3 | import com.hospital.models.Patient; 4 | import com.hospital.repositories.inmemory.InMemoryPatientRepository; 5 | import org.junit.jupiter.api.BeforeEach; 6 | import org.junit.jupiter.api.Test; 7 | 8 | import static org.junit.jupiter.api.Assertions.*; 9 | 10 | class PatientServiceTest { 11 | private PatientService patientService; 12 | private InMemoryPatientRepository patientRepo; 13 | 14 | @BeforeEach 15 | void setUp() { 16 | patientRepo = new InMemoryPatientRepository(); 17 | patientService = new PatientService(patientRepo); 18 | } 19 | 20 | @Test 21 | void testAddPatient() { 22 | Patient patient = new Patient("1", "John Doe", 30); 23 | Patient savedPatient = patientService.addPatient(patient); 24 | 25 | assertEquals(patient, savedPatient); 26 | } 27 | 28 | @Test 29 | void testAddPatientWithNegativeAge() { 30 | Patient patient = new Patient("2", "Jane Doe", -5); 31 | 32 | IllegalArgumentException thrown = assertThrows(IllegalArgumentException.class, () -> { 33 | patientService.addPatient(patient); 34 | }); 35 | assertEquals("Age cannot be negative", thrown.getMessage()); 36 | } 37 | 38 | @Test 39 | void testGetPatientById() { 40 | Patient patient = new Patient("3", "John Smith", 25); 41 | patientService.addPatient(patient); 42 | 43 | Patient fetchedPatient = patientService.getPatientById("3"); 44 | assertEquals(patient, fetchedPatient); 45 | } 46 | 47 | @Test 48 | void testRemovePatient() { 49 | Patient patient = new Patient("4", "Lisa White", 28); 50 | patientService.addPatient(patient); 51 | 52 | patientService.removePatient("4"); 53 | assertThrows(RuntimeException.class, () -> patientService.getPatientById("4")); 54 | } 55 | } 56 | -------------------------------------------------------------------------------- /Documentation/Reflection.md: -------------------------------------------------------------------------------- 1 | # Reflection: Challenges in Meeting Stakeholder Needs 2 | 3 | Creating a hospital appointment system was not easy because different people had different needs. Patients, doctors, hospital staff, IT teams, and insurance companies all had their own expectations, and sometimes these needs are conflicted. 4 | 5 | **Different Priorities** – Patients wanted an easy way to book appointments, but doctors needed a well-organized schedule. Administrators wanted less paperwork. If I focused too much on one group, it could have caused problems for another. For example, allowing patients to reschedule freely could make doctors' schedules messy. 6 | 7 | **Technology vs. User Expectations** – People wanted a system that was simple and fast, but IT staff had to make sure it was safe and reliable. Some features, like real-time scheduling, needed complex technology, which made the system harder to maintain. 8 | 9 | **Overbooking and Cancellations** – Doctors didn’t want last-minute cancellations, but patients wanted flexibility. The system needed reminders to reduce missed appointments while still allowing changes when needed. 10 | 11 | **Data Security** – The system had to protect patient information while still letting insurance companies verify details. The challenge was making sure only the right people could access sensitive data. 12 | 13 | **Easy to Use for Everyone** – Some users, like doctors and administrators, needed advanced tools, while patients and receptionists needed something simple. The system had to work well for both technical and non-technical users. 14 | 15 | **Handling Growth** – The hospital wanted a system that could handle more patients in the future. IT staff had to make sure it didn’t slow down when many people used it at the same time. 16 | 17 | ### Conclusion 18 | To balance everyone’s needs, I had to listen to all users and find a fair solution. Adding features like reminders, role-based access, and an easy-to-use design helped make sure the system worked well for everyone. 19 | -------------------------------------------------------------------------------- /Protection.md: -------------------------------------------------------------------------------- 1 | ## 🔒 Branch Protection Rules for `master` 2 | 3 | ### ✔️ Rule Summary 4 | 5 | We have enabled the following protection rules on the `master` branch to ensure the stability, security, and quality of the codebase: 6 | 7 | 1. **Require Pull Request Reviews (At Least 1 Reviewer):** 8 | 9 | * No one can merge code directly without a review. 10 | * This encourages peer reviews, which catch bugs early and improve code quality. 11 | 12 | 2. **Require Status Checks to Pass (CI Integration):** 13 | 14 | * Only code that passes all automated tests (e.g., unit, integration, API) can be merged. 15 | * This prevents broken or untested features from being deployed to production. 16 | 17 | 3. **Disable Direct Pushes:** 18 | 19 | * Developers cannot push directly to the `master` branch. 20 | * All changes must go through a Pull Request (PR), fostering collaboration and transparency. 21 | 22 | 23 | 24 | ## 💡 Why These Rules Matter 25 | 26 | | Rule | Benefit | 27 | | ------------------------- | -------------------------------------------------------------------------------------------------- | 28 | | **Review Requirements** | Ensures code is seen by at least one other team member. Reduces errors and spreads knowledge. | 29 | | **Passing Status Checks** | Enforces automated testing before merge, preventing broken code in production. | 30 | | **No Direct Pushes** | Protects `main` from accidental or unauthorized changes. Enforces the proper development workflow. | 31 | 32 | --- 33 | 34 | ## ✅ Best Practices 35 | 36 | * Create feature branches from `main`. 37 | * Open a pull request and request a review. 38 | * Ensure your commits pass all checks (e.g., GitHub Actions). 39 | * Only merge once approved and all checks have passed. 40 | 41 | # Branch protection rule screenshot 42 | 43 | ![Branch Protection](https://github.com/user-attachments/assets/9f727b02-3866-4698-b3a9-cdaa04ca979e) 44 | 45 | 46 | 47 | -------------------------------------------------------------------------------- /Assignment 7/kanban_explanation.md: -------------------------------------------------------------------------------- 1 | # Hospital Appointment Scheduling Board 2 | 3 | # Screenshots 4 | ## Custom Columns 5 | ![aa2](https://github.com/user-attachments/assets/8c519eaf-0c08-4513-91e8-2cec5389eec9) 6 | 7 | ## Linked Issues with Labels 8 | ![aa3](https://github.com/user-attachments/assets/75a8a484-7b46-48d7-9f1b-901ecbb9cce7) 9 | ## Issues and Statuses 10 | ![aa4](https://github.com/user-attachments/assets/9060a430-9ea2-4e53-85fa-26a0c08a8188) 11 | 12 | ## Task Assigned 13 | ![aa5](https://github.com/user-attachments/assets/8b92fcf5-f90b-4e91-bbbd-0cb9f41b8cfc) 14 | 15 | 16 | 17 | 18 | 19 | ## Customization Choices 20 | - **Added "Testing" Column**: Ensures features are verified by QA before moving to "Done". 21 | - **Added "Blocked" Column**: Highlights tasks that are stalled due to dependencies. 22 | - **Linked GitHub Issues**: Tracks progress of key features (`feature`) and bug fixes (`bug`). 23 | - **Task Assignments**: Uses `@mentions` to distribute work among team members. 24 | 25 | 26 | # **Kanban Board Explanation** 27 | 28 | A **Kanban board** is a visual tool used to track tasks as they move through different stages of a workflow. It helps teams manage work efficiently by displaying tasks in columns that represent their progress (e.g., *To Do, In Progress, Done*). 29 | 30 | ### **How Our Kanban Board Works** 31 | 32 | **Visualizing Workflow** 33 | - Each column represents a stage in the development process: 34 | - *To Do* – Tasks that need to be started. 35 | - *In Progress* – Tasks currently being worked on. 36 | - *Testing* – Tasks waiting for quality checks. 37 | - *Blocked* – Tasks that are stalled due to dependencies. 38 | - *Done* – Completed tasks. 39 | - Team members can see which tasks are active, pending, or completed at a glance. 40 | 41 | **Limiting Work-in-Progress (WIP)** 42 | - To avoid overload, we limit **WIP** to a maximum of **3 tasks per column** (except "Blocked"). 43 | - This prevents multitasking, reduces bottlenecks, and ensures smooth task progression. 44 | 45 | **Supporting Agile Principles** 46 | - The board enables **continuous delivery** by allowing tasks to flow through stages efficiently. 47 | - **Adaptability** is improved as team members can quickly adjust priorities based on sprint needs. 48 | - Issues and features are categorized (`feature`, `bug`), ensuring structured and iterative improvements. 49 | 50 | 51 | -------------------------------------------------------------------------------- /Assignment 10/creational_patterns/README.md: -------------------------------------------------------------------------------- 1 | ## Creational Patterns 2 | 3 | ### Language Choice: Java 4 | Java was chosen for this implementation because: 5 | - It supports **object-oriented principles** critical to design patterns. 6 | - It offers robust support for **interfaces, abstract classes**, and **modular design**. 7 | - It integrates easily with **Swing** for GUI and **file-based persistence**, which aligns with our non-functional requirements. 8 | 9 | 10 | ### Pattern Justifications and Use Cases 11 | 12 | #### 1. Simple Factory Pattern 13 | - **Use Case:** Creating different types of `User` objects (Patient, Doctor, Admin). 14 | - **Why:** Centralizes creation logic, avoiding direct instantiation in client code. 15 | - **Class:** `UserFactory` 16 | - **Example:** 17 | ```java 18 | User user = UserFactory.createUser("Doctor"); 19 | ``` 20 | 21 | #### 2. Factory Method Pattern 22 | - **Use Case:** Creating payment handlers for appointment payments (e.g., `CashPayment`, `CardPayment`). 23 | - **Why:** Enables subclass-specific object creation logic without altering client code. 24 | - **Class:** `PaymentProcessor` interface with concrete factories like `CardPaymentProcessor`, `CashPaymentProcessor`. 25 | 26 | #### 3. Abstract Factory Pattern 27 | - **Use Case:** Creating a UI component family (e.g., `LightThemeButton`, `DarkThemeTextBox`). 28 | - **Why:** Ensures that UI components are consistent within a theme. 29 | - **Class:** `UIFactory` interface with factories like `LightThemeFactory`, `DarkThemeFactory`. 30 | 31 | #### 4. Builder Pattern 32 | - **Use Case:** Creating complex `PatientProfile` with optional data (e.g., allergies, insurance info). 33 | - **Why:** Simplifies the creation of complex objects with many optional parameters. 34 | - **Class:** `PatientProfileBuilder` 35 | 36 | #### 5. Prototype Pattern 37 | - **Use Case:** Cloning reusable notification templates (`Reminder`, `CancellationNotice`). 38 | - **Why:** Avoids costly reinitialization of common objects like system-generated messages. 39 | - **Class:** `NotificationTemplate` with `clone()` functionality. 40 | 41 | #### 6. Singleton Pattern 42 | - **Use Case:** Ensuring a single instance of the `NotificationManager` to handle system-wide alerts. 43 | - **Why:** Prevents creation of multiple instances that could lead to duplicate notifications or race conditions. 44 | - **Class:** `NotificationManager` 45 | 46 | --- 47 | 48 | ### Summary 49 | 50 | These patterns promote: 51 | - **Scalability** — Adding new roles or notification types without major rewrites. 52 | - **Maintainability** — Encapsulated logic for object creation. 53 | - **Extensibility** — Future integration with billing, electronic health records (EHR), or cloud storage. 54 | -------------------------------------------------------------------------------- /Assignment 14/README.md: -------------------------------------------------------------------------------- 1 | # 🏥 Hospital Appointment Scheduling System 2 | 3 | 4 | A comprehensive Java Spring Boot application designed to streamline hospital appointment scheduling, enhancing patient care and administrative efficiency. 5 | 6 | ## Features for Contribution 7 | 8 | ### 🚀 Getting Started 9 | 10 | Follow these steps to set up and run the project locally: 11 | 12 | ### Prerequisites 13 | 14 | - **Java 17** or higher 15 | - **Maven 3.8+** 16 | - A GitHub account 17 | 18 | ### Installation 19 | 20 | 1. **Clone the Repository** 21 | 22 | ```bash 23 | git clone https://github.com/yourusername/hospital-appointment-scheduling.git 24 | cd hospital-appointment-scheduling 25 | 26 | 27 | 2. **Build the Project** 28 | 29 | Compile the project and download dependencies: 30 | 31 | ```bash 32 | mvn clean install 33 | ``` 34 | 35 | 3. **Run the Application** 36 | 37 | Start the application using: 38 | 39 | ```bash 40 | mvn spring-boot:run 41 | ``` 42 | 43 | Access the application at `http://localhost:8080`. 44 | 45 | 4. **Run Tests** 46 | 47 | Execute all tests to ensure the application is functioning correctly: 48 | 49 | ```bash 50 | mvn test 51 | ``` 52 | 53 | 54 | 55 | ## 💡 Features for Contribution 56 | 57 | We welcome contributions to enhance the system. Below is a list of features open for development: 58 | 59 | | Feature Name | Description | Status | Suggested Label | 60 | | ------------------------------------ | ------------------------------------------------------------------------- | ---------- | ------------------ | 61 | | **Appointment Reminders** | Implement email/SMS notifications for upcoming appointments. | 🟡 Planned | `feature-request` | 62 | | **Doctor Availability Management** | Allow doctors to set and update their available time slots. | 🟡 Planned | `good first issue` | 63 | | **Role-Based Access Control (RBAC)** | Implement permissions based on user roles (e.g., admin, doctor, patient). | 🟡 Planned | `feature-request` | 64 | | **Calendar Integration** | Sync appointments with external calendars (e.g., Google Calendar). | 🟡 Planned | `feature-request` | 65 | | **Multilingual Support** | Add support for multiple languages to cater to a diverse user base. | 🟡 Planned | `good first issue` | 66 | 67 | *Status Legend:* 68 | 69 | * 🟢 Completed 70 | * 🟡 Planned 71 | * 🔴 In Progress 72 | 73 | --- 74 | 75 | ## 🤝 Contributing 76 | 77 | We appreciate your interest in contributing! Please refer to our [CONTRIBUTING.md](./CONTRIBUTING.md) for guidelines on how to get started. 78 | 79 | 80 | -------------------------------------------------------------------------------- /Assignment 8/Reflection.md: -------------------------------------------------------------------------------- 1 | # Reflection 2 | 3 | ### Challenges in Choosing Granularity for States/Actions 4 | 5 | One of the key challenges was **deciding the level of detail** for states and actions in both state and activity diagrams. If states were too granular (e.g., breaking down every micro-action like "Button Clicked" or "Input Field Validated"), the diagrams became cluttered and hard to read. On the other hand, if too abstract (e.g., just using “Processing” or “Completed”), important logic or transitions were lost. 6 | 7 | We aimed for a **balance between clarity and completeness**, especially for critical objects like `Appointment` and workflows like `Book Appointment`, where key transitions (e.g., “Pending → Confirmed → Completed”) needed to be visible without overwhelming the reader. 8 | 9 | --- 10 | 11 | ### Aligning Diagrams with Agile User Stories 12 | 13 | Another challenge was **mapping UML diagrams to Agile artifacts** such as user stories and sprint tasks. Agile user stories often describe *what* the user wants (“As a patient, I want to cancel my appointment”) without prescribing *how* it should be implemented. Translating that into precise UML transitions or workflows required close reading of the user stories and functional requirements. 14 | 15 | To address this, I used a **traceability matrix** to map diagrams to specific user stories and functional requirements, ensuring that **each diagram had a direct purpose** tied to a real stakeholder need. 16 | 17 | --- 18 | 19 | ### State Diagrams vs. Activity Diagrams 20 | 21 | | Aspect | State Diagrams | Activity Diagrams | 22 | |---------------------|--------------------------------------------|--------------------------------------------------| 23 | | Focus | Object behavior over time | Step-by-step workflow or process | 24 | | Best For | Modeling lifecycle of objects (e.g., Appointment) | Describing processes (e.g., Booking, Cancelling) | 25 | | Trigger | Events and conditions | Actions and decision points | 26 | | Challenges | Avoiding over-complex transitions | Representing concurrent actions clearly | 27 | | Strength | Great for understanding how an object reacts | Clear for visualizing full user/system processes | 28 | 29 | In summary, **state diagrams helped define how system entities behave**, such as how an `Appointment` moves from "Pending" to "Completed". Meanwhile, **activity diagrams were crucial for illustrating full workflows** involving multiple actors like the patient, system, and admin. Using both offered a holistic view of both **internal behavior** and **external processes**. 30 | 31 | 32 | 33 | 34 | -------------------------------------------------------------------------------- /pom.xml: -------------------------------------------------------------------------------- 1 | 5 | 6 | 4.0.0 7 | com.hospital 8 | hospital-system 9 | 1.0.0 10 | jar 11 | 12 | Hospital Appointment System 13 | Spring Boot Hospital Appointment System 14 | 15 | 16 | org.springframework.boot 17 | spring-boot-starter-parent 18 | 3.2.2 19 | 20 | 21 | 22 | 23 | 17 24 | 25 | 26 | 27 | 28 | 29 | org.springframework.boot 30 | spring-boot-starter-web 31 | 32 | 33 | 34 | 35 | org.springframework.boot 36 | spring-boot-starter-data-jpa 37 | 38 | 39 | 40 | 41 | com.h2database 42 | h2 43 | runtime 44 | 45 | 46 | 47 | 48 | org.springframework.boot 49 | spring-boot-starter-test 50 | test 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | org.springframework.boot 59 | spring-boot-maven-plugin 60 | 3.2.2 61 | 62 | 63 | 64 | 65 | org.apache.maven.plugins 66 | maven-surefire-plugin 67 | 3.0.0-M5 68 | 69 | com.hospital.HospitalSystemApplication 70 | 71 | 72 | 73 | 74 | 75 | 76 | -------------------------------------------------------------------------------- /Assignment 12/README.md: -------------------------------------------------------------------------------- 1 | 2 | # **Service Layer Implementation** 3 | 4 | ### **Why Service Classes Were Created** 5 | 6 | Service classes like `AppointmentService`, `PatientService`, and `DoctorService` separate **business logic** from **persistence logic** (repositories) and **presentation logic** (API controllers). 7 | This promotes **Separation of Concerns (SoC)** — making the system modular, testable, and maintainable. 8 | 9 | ### **Why Repositories Are Injected** 10 | 11 | Repositories are passed into service classes through constructor injection: 12 | 13 | ```java 14 | public AppointmentService(AppointmentRepository repo) { 15 | this.repo = repo; 16 | } 17 | ``` 18 | 19 | This allows services to remain **decoupled** from the actual storage implementation (in-memory, file-based, database), making unit testing easier. 20 | 21 | ### **Why Business Rules Are Handled in Services** 22 | 23 | Example: Preventing double-booking, checking doctor availability, or validating appointment times are core rules enforced in the service layer. 24 | 25 | **Justification:** 26 | Keeping this logic centralized avoids duplicating rules in multiple controllers or repositories and ensures consistency across the system. 27 | 28 | --- 29 | 30 | # **REST API Development** 31 | 32 | ### **Why RESTful Endpoints Were Used** 33 | 34 | Endpoints like `/api/patients`, `/api/doctors`, and `/api/appointments` follow REST principles and standard HTTP methods (GET, POST, PUT, DELETE). 35 | 36 | **Justification:** 37 | 38 | * Aligns with modern web API design. 39 | * Enables frontend apps or external systems to interact easily with the backend. 40 | * Standard HTTP status codes improve client-side error handling. 41 | 42 | ### **Why Spring Boot Was Used** 43 | 44 | Spring Boot simplifies dependency management, routing, and server startup, making it ideal for building robust, scalable REST APIs. 45 | 46 | **Justification:** 47 | It reduces boilerplate and includes built-in support for Swagger/OpenAPI, validation, and exception handling. 48 | 49 | ### **Why We Used Separate Controller Classes** 50 | 51 | Each controller (e.g., `AppointmentController`) maps to its domain entity and delegates calls to the service layer. 52 | 53 | **Justification:** 54 | This modular approach makes the API easier to maintain, test, and document. 55 | 56 | --- 57 | 58 | # **API Documentation** 59 | 60 | ### **Why OpenAPI/Swagger Was Used** 61 | 62 | Swagger auto-generates API docs based on Spring annotations like `@RestController`, `@GetMapping`, and `@RequestBody`. 63 | 64 | **Justification:** 65 | 66 | * Provides a UI at `/swagger-ui.html` for testing endpoints interactively. 67 | * Helps developers and testers understand available endpoints, parameters, and responses without reading source code. 68 | * Reduces onboarding time for new developers or frontend collaborators. 69 | 70 | ### **Why We Included YAML/JSON Schema Files** 71 | 72 | Generated YAML or JSON defines the API contract and supports client SDK generation or integration testing tools like Postman. 73 | -------------------------------------------------------------------------------- /Assignment 10/src/README.md: -------------------------------------------------------------------------------- 1 | ### Relationships Covered 2 | 3 | - **Inheritance**: 4 | - `Patient`, `Doctor`, `Admin` inherit from `User`. 5 | - **Association**: 6 | - `Appointment` has associations with `Patient` and `Doctor`. 7 | - **Composition**: 8 | - `Notification` is composed and used by appointments or user actions. 9 | 10 | --- 11 | 12 | ### Language Choice: **Java** 13 | 14 | **Why Java?** 15 | - **Platform-independent:** Java runs on any OS with a JVM (Windows, Linux, macOS), supporting the deployability requirement. 16 | - **Object-Oriented Design:** Perfect for modeling real-world hospital roles like Patients, Doctors, and Admins using inheritance and encapsulation. 17 | - **Strong Typing and Error Handling:** Reduces bugs and ensures better input validation, aligned with security and validation requirements. 18 | - **Rich Libraries:** Java provides built-in support for date/time (`LocalDateTime`), file handling, and GUI components (Swing), supporting features like reminders, persistence, and a future GUI. 19 | - **Community and Support:** Java is well-supported for both academic and enterprise-grade applications. 20 | 21 | --- 22 | 23 | ### Key Design Decisions 24 | 25 | #### 1. **Object-Oriented Structure** 26 | - Used **inheritance** by creating a base `User` class and extending it to `Patient`, `Doctor`, and `Admin` to reduce code duplication. 27 | - Each subclass overrides methods like `login()` and has its own role-specific operations (e.g., booking/canceling appointments). 28 | 29 | #### 2. **Encapsulation** 30 | - All class attributes are marked `private` or `protected`, with getters and setters where needed to enforce encapsulation and secure data handling. 31 | 32 | #### 3. **Appointment Management** 33 | - `Appointment` class includes composition with `Doctor` and `Patient`, ensuring direct association during creation. 34 | - Methods like `confirm()` and `cancel()` manage appointment state transitions aligned with use cases and behavioral models. 35 | 36 | #### 4. **Notifications** 37 | - `Notification` class sends or schedules reminders to patients and doctors, directly supporting functional requirements related to timely communication. 38 | 39 | #### 5. **Domain Alignment** 40 | - The class design mirrors domain entities like Patient, Doctor, Admin, and Appointment identified during domain modeling. 41 | - Every use case (e.g., "Book Appointment", "Cancel Appointment") maps to a method or relationship in the class structure. 42 | - State transitions (e.g., Appointment status: Scheduled → Confirmed → Cancelled) are modeled using simple string state variables for extensibility. 43 | 44 | #### 6. **Scalability and Modularity** 45 | - The modular architecture makes it easy to add new features (e.g., `MedicalHistory`, `Billing`, `AvailabilityCheck`) without modifying existing code drastically. 46 | 47 | #### 7. **Future-Ready** 48 | - Classes are designed with extensibility in mind — for instance: 49 | - Notifications could later support email/SMS integration. 50 | - File-based persistence could evolve into database storage. 51 | - CLI interactions can be upgraded to a full Java Swing GUI or JavaFX interface. 52 | 53 | -------------------------------------------------------------------------------- /Documentation/Use Case Diagram.md: -------------------------------------------------------------------------------- 1 | # Hospital Appointment System - Use Case Diagram 2 | 3 | ## Use Case Diagram 4 | 5 | ```mermaid 6 | graph TD; 7 | %% Actors %% 8 | Patient["👤 Patient"] 9 | Doctor["👤 Doctor"] 10 | Admin["👤 Admin"] 11 | Receptionist["👤 Receptionist"] 12 | IT_Support["👤 IT Support Staff"] 13 | Insurance_Provider["👤 Health Insurance Provider"] 14 | 15 | %% Use Cases %% 16 | Appointment_Booking["📅 Book Appointment"] 17 | Appointment_Cancellation["❌ Cancel Appointment"] 18 | Search_Appointment["🔍 Search Appointment"] 19 | Manage_Availability["🕒 Manage Availability"] 20 | View_Schedule["📋 View Schedule"] 21 | Notifications["📢 Receive Notifications"] 22 | User_Authentication["🔑 User Authentication"] 23 | Insurance_Verification["💳 Verify Insurance"] 24 | System_Maintenance["🛠 Maintain System"] 25 | 26 | %% Relationships %% 27 | Patient -->|Books| Appointment_Booking 28 | Patient -->|Cancels| Appointment_Cancellation 29 | Patient -->|Searches| Search_Appointment 30 | Patient -->|Receives| Notifications 31 | 32 | Doctor -->|Views| View_Schedule 33 | Doctor -->|Manages| Manage_Availability 34 | Doctor -->|Receives| Notifications 35 | 36 | Admin -->|Manages| Appointment_Booking 37 | Admin -->|Manages| Appointment_Cancellation 38 | Admin -->|Handles| User_Authentication 39 | 40 | Receptionist -->|Assists with| Appointment_Booking 41 | Receptionist -->|Checks| Manage_Availability 42 | Receptionist -->|Handles| Search_Appointment 43 | 44 | IT_Support -->|Maintains| System_Maintenance 45 | IT_Support -->|Ensures| User_Authentication 46 | IT_Support -->|Manages| Notifications 47 | 48 | Insurance_Provider -->|Verifies| Insurance_Verification 49 | ``` 50 | ## Key Actors and Their Roles 51 | **Patients** – Book, search,cancel appointments, and receive notifications. 52 | 53 | **Doctors** – Manage availability, view their schedules, and receive notifications. 54 | 55 | **Admins** – Manage all appointments and oversee user authentication. 56 | 57 | **Receptionists** – Assist with booking, search for appointments, and check doctor availability. 58 | 59 | **IT Support Staff** – Maintain the system, handle security, and ensure notifications function properly. 60 | 61 | **Health Insurance Providers** – Verify patient insurance before the appointment. 62 | 63 | ## Relationships Between Actors and Use Cases 64 | **Generalization:** Admins have the highest privileges, as they can manage all appointment-related actions. 65 | 66 | **Inclusion:** The Search Appointment feature includes filters like date, doctor name, and patient name. 67 | 68 | **Exclusion:** Doctors do not book appointments but only manage availability. 69 | 70 | ## How the Diagram Addresses Stakeholder Concerns 71 | **Patients:** The system provides easy booking and cancellation, doctor availability checks, and timely reminders to reduce missed appointments. 72 | 73 | **Doctors:** Doctors can view schedules, manage their availability, and receive notifications to prevent scheduling conflicts. 74 | 75 | **Admins:** Admins can manage all appointments, reducing manual work. 76 | 77 | **Receptionists:** They get quick access to doctor schedules, reducing errors during peak hours. 78 | 79 | **IT Support:** Ensures the system remains secure and operational. 80 | 81 | **Insurance Providers:** Integrate insurance verification to speed up billing. 82 | -------------------------------------------------------------------------------- /Assignment 14/REFLECTION.md: -------------------------------------------------------------------------------- 1 | # REFLECTION 2 | 3 | 4 | **Reflection on Enhancing My GitHub Repository and Open-Source Collaboration** 5 | 6 | Embarking on the journey of developing and maintaining the Hospital Appointment Scheduling System has been both challenging and enlightening. The feedback from peers and the broader open-source community has been instrumental in shaping the project's trajectory. 7 | 8 | **1. Improvements Based on Peer Feedback** 9 | 10 | Peer reviews highlighted areas where the repository could be more accessible and contributor-friendly. In response: 11 | 12 | * **Enhanced Documentation**: I developed a comprehensive `README.md` that outlines the project's purpose, setup instructions, and usage guidelines. This serves as a clear entry point for new users and contributors. 13 | 14 | * **Contribution Guidelines**: A `CONTRIBUTING.md` file was added, detailing the process for setting up the development environment, coding standards, and steps to submit pull requests. This clarity helps streamline the contribution process. 15 | 16 | * **Issue Labeling**: To assist newcomers, I labeled beginner-friendly tasks as `good first issue` and potential enhancements as `feature-request`. This categorization aids contributors in selecting tasks aligned with their skill levels. 17 | 18 | * **Project Roadmap**: A `ROADMAP.md` was introduced to outline future features and enhancements, providing transparency about the project's direction and inviting community input. 19 | 20 | **2. Challenges in Onboarding Contributors** 21 | 22 | Onboarding contributors presented several challenges: 23 | 24 | * **Complex Setup**: Some contributors faced difficulties setting up the development environment due to missing dependencies or unclear instructions. To mitigate this, I refined the setup guide and included troubleshooting tips. 25 | 26 | * **Understanding Project Structure**: New contributors sometimes struggled to grasp the project's architecture. I addressed this by adding diagrams and detailed explanations of the codebase structure. 27 | 28 | * **Communication Gaps**: Coordinating across different time zones and ensuring timely responses was challenging. Implementing a communication protocol and setting expectations for response times helped alleviate this issue. 29 | 30 | * **Maintaining Engagement**: Keeping contributors motivated, especially after their initial contributions, required effort. Recognizing their work in project updates and providing constructive feedback fostered a sense of belonging and appreciation. 31 | 32 | **3. Lessons Learned About Open-Source Collaboration** 33 | 34 | Through this experience, several key lessons emerged: 35 | 36 | * **Importance of Clear Communication**: Transparent and prompt communication is vital. It ensures that contributors feel valued and understand their impact on the project. 37 | 38 | * **Value of Inclusivity**: Creating an inclusive environment encourages diverse contributions, enriching the project with varied perspectives and ideas. 39 | 40 | * **Need for Structured Processes**: Having well-defined processes for contributions, reviews, and issue tracking enhances efficiency and reduces confusion. 41 | 42 | * **Continuous Learning**: Open-source collaboration is a dynamic learning experience. Embracing feedback and being open to change are crucial for personal and project growth. 43 | 44 | In conclusion, the journey of improving the repository and engaging with the open-source community has been profoundly rewarding. The challenges encountered have been learning opportunities, and the collaborative efforts have significantly enriched the project. I am committed to fostering an environment that welcomes contributions, values feedback, and continually evolves to meet the needs of its users and contributors. 45 | 46 | -------------------------------------------------------------------------------- /Documentation/Architecture.md: -------------------------------------------------------------------------------- 1 | # C4 Architecture Diagrams 2 | 3 | ## Project Title: 4 | Hospital Appointment System 5 | 6 | ## Domain: 7 | Healthcare 8 | 9 | The **Hospital Appointment System** is part of the **Healthcare** field, which focuses on providing medical services and managing things like patient visits, doctor appointments, and hospital operations. This system is designed to help patients book appointments with doctors, let admins manage and cancel appointments, and make sure doctors can see their own schedules. It makes the process of managing appointments smoother and more organized, which helps improve the patient experience and hospital efficiency. 10 | 11 | ## Problem Statement: 12 | The goal of this **Hospital Appointment System** is to solve problems that hospitals face with scheduling and managing appointments. In many hospitals, it's easy to have double-booked appointments, missed appointments, or patients struggling to find available doctors. This system helps by allowing patients to book appointments directly with doctors, giving admins the ability to manage and cancel appointments, and allowing doctors to view their own appointments. The system also stores appointment data so that information is saved even after closing the program. By making appointments more organized, the system helps hospitals run more smoothly and makes it easier for patients to access care. 13 | 14 | ## Context Diagram (Level 1) 15 | The Context Diagram shows the overall system and its interactions with external entities. 16 | 17 | 18 | ![Untitled Workspace](https://github.com/user-attachments/assets/3a726816-b11e-4224-a799-07f43937149a) 19 | 20 | ## Container Diagram (Level 2) 21 | The Container Diagram outlines the software's high-level structure, showing the main containers (applications, databases, etc.) that make up the system. 22 | 23 | ![C2](https://github.com/user-attachments/assets/25629140-9228-4906-ae6f-93d3aeab9885) 24 | 25 | ## Component Diagram (Level 3) 26 | The Component Diagram breaks down the key components inside each container. Here, we show how the Java Swing app connects to the Appointment Manager and how the system handles data. 27 | 28 | ![C3](https://github.com/user-attachments/assets/52ffdb4b-d815-4f0f-977e-39cf22c403e6) 29 | 30 | ## Code/Dynamic Diagram (Level 4) 31 | The Dynamic Diagram describes how the components interact during key operations such as booking an appointment. 32 | 33 | **Booking an Appointment:** 34 | - Step 1: The Patient enters their details (name, doctor, date, etc.) in the Java Swing Interface. 35 | - Step 2: The Appointment Manager checks if the doctor is available. 36 | - Step 3: If available, the appointment is saved in the Appointment Data (text file). 37 | - Step 4: The Patient and Doctor receive a confirmation via Notification Alerts. 38 | 39 | ![C4](https://github.com/user-attachments/assets/8198a67b-a5ca-4920-8124-0290bb9ad8ac) 40 | 41 | ## Feasibility Justification 42 | The Hospital Appointment System is feasible to implement in small to medium-sized healthcare facilities. It uses simple technology (Java Swing for the UI and text files for storage), which makes it accessible even with minimal technical infrastructure. 43 | 44 | - **Cost:** Development costs are low because it uses basic Java technology and does not require expensive servers or databases. 45 | - **Time:** The system can be developed quickly as it is relatively simple and focuses on core features that solve specific problems. 46 | - **Scalability:** While the system can handle a moderate number of users and appointments, future upgrades like a cloud-based database or mobile version can easily scale the system for larger healthcare facilities. 47 | - **User Adoption:** The system is designed to be intuitive and easy to use, reducing training time for hospital staff. 48 | -------------------------------------------------------------------------------- /Assignment 14/ROADMAP.md: -------------------------------------------------------------------------------- 1 | # 🗺️ Hospital Appointment Scheduling System Roadmap 2 | 3 | Welcome to the roadmap for the Hospital Appointment Scheduling System. This document outlines our vision, current progress, and planned features to enhance patient care and streamline hospital operations. 4 | 5 | 6 | 7 | ## ✅ Completed Features 8 | 9 | - **User Registration & Authentication**: Secure sign-up and login functionalities for patients and staff. 10 | - **Appointment Booking**: Patients can schedule appointments with available doctors. 11 | - **Admin Dashboard**: Administrative interface to manage users, appointments, and system settings. 12 | - **Basic Notifications**: Email confirmations for appointment bookings. 13 | 14 | 15 | 16 | ## 🚧 In Progress 17 | 18 | - **Role-Based Access Control (RBAC)**: Implementing permissions based on user roles (e.g., admin, doctor, patient). 19 | - **Appointment Reminders**: Automated email/SMS reminders for upcoming appointments. 20 | - **Doctor Availability Management**: Doctors can set and update their availability slots. 21 | 22 | 23 | 24 | ## 📝 Planned Features 25 | 26 | ### 🔒 Security & Compliance 27 | 28 | - **Two-Factor Authentication (2FA)**: Enhance account security with 2FA options. 29 | - **Data Encryption**: Encrypt sensitive patient data both at rest and in transit. 30 | - **Audit Logs**: Maintain logs of user activities for compliance and monitoring. 31 | 32 | ### 📅 Scheduling Enhancements 33 | 34 | - **Calendar Integration**: Sync appointments with external calendars (e.g., Google Calendar). 35 | - **Waitlist Management**: Allow patients to join a waitlist for earlier appointment slots. 36 | - **Recurring Appointments**: Support for scheduling recurring visits for chronic care patients. 37 | 38 | ### 📊 Analytics & Reporting 39 | 40 | - **Dashboard Metrics**: Visualize key metrics like appointment rates, cancellations, and no-shows. 41 | - **Custom Reports**: Generate reports based on date ranges, departments, or doctors. 42 | 43 | ### 🌐 User Experience 44 | 45 | - **Multilingual Support**: Interface translations for multiple languages to cater to diverse users. 46 | - **Responsive Design**: Ensure optimal usability across devices (desktop, tablet, mobile). 47 | - **Accessibility Compliance**: Adhere to WCAG standards for users with disabilities. 48 | 49 | ### 📱 Mobile Application 50 | 51 | - **Patient App**: Allow patients to book, reschedule, or cancel appointments via a mobile app. 52 | - **Doctor App**: Enable doctors to manage their schedules and view patient information on-the-go. 53 | 54 | ### 🧩 Integrations 55 | 56 | - **Electronic Health Records (EHR)**: Integrate with existing EHR systems for seamless data flow. 57 | - **Payment Gateways**: Facilitate online payments for consultations and services. 58 | - **Telemedicine Support**: Incorporate video conferencing tools for remote consultations. 59 | 60 | 61 | 62 | ## 🌟 Future Considerations 63 | 64 | - **AI-Powered Scheduling**: Utilize AI to suggest optimal appointment times based on historical data. 65 | - **Chatbot Assistance**: Implement a chatbot to assist patients with common queries and appointment bookings. 66 | - **Feedback System**: Collect and analyze patient feedback post-appointment for quality improvement. 67 | 68 | 69 | 70 | ## 🤝 Contributing 71 | 72 | We welcome contributions to help bring these features to life. If you're interested in working on any of the planned features: 73 | 74 | 1. **Check Issues**: Look for open issues labeled `good first issue` or `feature-request`. 75 | 2. **Discuss**: Comment on the issue to express your interest and discuss implementation details. 76 | 3. **Fork & Branch**: Fork the repository and create a feature branch. 77 | 4. **Develop & Test**: Implement the feature and ensure all tests pass. 78 | 5. **Pull Request**: Submit a pull request with a clear description of your changes. 79 | 80 | For detailed contribution guidelines, refer to [CONTRIBUTING.md](./CONTRIBUTING.md). 81 | 82 | --- 83 | 84 | *Last updated: May 17, 2025* 85 | 86 | -------------------------------------------------------------------------------- /Assignment 11/README.md: -------------------------------------------------------------------------------- 1 | # JUSTIFICATION 2 | 3 | # TASK 1 4 | 5 | **Deliverables** 6 | - `/repositories/Repository.java` (generic) 7 | - `/repositories/AppointmentRepository.java` (specific to Appointment) 8 | 9 | ## Justification 10 | I created a **generic `Repository` interface** to define standard CRUD operations like **save**, **findById**, **findAll**, and **delete**. 11 | 12 | By using **Java Generics**, I **avoided duplication** across entity repositories. 13 | 14 | This approach makes it easy to create specific repositories (like `AppointmentRepository`) without rewriting basic CRUD logic for every entity (e.g., if later we add `DoctorRepository`, `PatientRepository`, etc.). 15 | 16 | **Advantages:** 17 | - Less repetitive code. 18 | - Consistent structure for all repositories. 19 | - Easier maintenance and testing. 20 | 21 | --- 22 | 23 | # TASK 2 24 | 25 | **Deliveries** 26 | - `/repositories/inmemory/InMemoryAppointmentRepository.java` 27 | - `/repositories/inmemory/InMemoryAppointmentRepositoryTest.java` 28 | --- 29 | 30 | ## Justification 31 | 32 | ### In-Memory Repository Justification 33 | I implemented an **In-Memory Appointment Repository** using a `HashMap`. 34 | 35 | - The **key** is generated from the doctor name, date, and time to ensure appointment uniqueness. 36 | - **HashMap** provides **fast O(1) CRUD operations** (save, find, delete). 37 | 38 | I also created **JUnit 5** test cases to verify that CRUD methods work correctly. 39 | 40 | ### 📄 Note: 41 | I use `doctorName_date_time` as the **unique key** since in your system, a doctor cannot have two appointments at the same time. 42 | 43 | 44 | --- 45 | 46 | # TASK 3 47 | 48 | 49 | **Explanation:** 50 | - You call `RepositoryFactory.getAppointmentRepository("MEMORY")` 51 | - It gives you the **InMemoryAppointmentRepository**. 52 | - In future, if you add a database, you can simply add a `"DATABASE"` case! 53 | 54 | 55 | ### Justification 56 | 57 | ### Storage Abstraction Justification 58 | I used the **Factory Pattern** to decouple our service layer from specific storage implementations. 59 | 60 | - **Why Factory?** 61 | Factories allow easy swapping between different storage backends (e.g., Memory, Database) without changing service logic. 62 | 63 | - **Current Setup:** 64 | `RepositoryFactory` returns an `InMemoryAppointmentRepository`. 65 | 66 | - **Future-proof:** 67 | When I add database support, we can extend `RepositoryFactory` with a `"DATABASE"` case without touching the rest of the system. 68 | 69 | 70 | 71 | ### How you now use it in the **HospitalAppointmentSystem** class: 72 | 73 | Instead of: 74 | ```java 75 | private static AppointmentRepository appointmentRepository = new InMemoryAppointmentRepository(); 76 | ``` 77 | You write: 78 | ```java 79 | private static AppointmentRepository appointmentRepository = RepositoryFactory.getAppointmentRepository("MEMORY"); 80 | ``` 81 | --- 82 | 83 | # TASK 4 84 | 85 | 86 | **Stub is ready:** 87 | - All methods throw `UnsupportedOperationException`. 88 | - You can fill them in later when you actually connect to a real database! 89 | 90 | 91 | ## Updated Class Diagram 92 | 93 | **What this shows:** 94 | - `Repository` is a generic interface. 95 | - `AppointmentRepository` **extends** `Repository`. 96 | - `InMemoryAppointmentRepository` and `DatabaseAppointmentRepository` **implement** `AppointmentRepository`. 97 | - Very easy for someone reading it to understand the layers and how future storage types plug in. 98 | 99 | 100 | ## Final Update 101 | 102 | ### Future-Proofing Strategy 103 | 104 | I created a **DatabaseAppointmentRepository** stub to prepare for future storage options. 105 | Using the **Repository Interface** and **Factory Pattern**, the system can easily swap between: 106 | - In-memory storage (for development and testing) 107 | - Database storage (for production) 108 | - Other storage like File System or Cloud Storage. 109 | 110 | This design ensures **scalability**, **flexibility**, and **minimal code changes** when upgrading the backend. 111 | -------------------------------------------------------------------------------- /Assignment 12/docs/openapi.yaml: -------------------------------------------------------------------------------- 1 | openapi: 3.0.1 2 | info: 3 | title: Hospital Appointment Scheduling API 4 | version: 1.0.0 5 | description: API for managing hospital appointments, patients, doctors, and users. 6 | 7 | servers: 8 | - url: http://localhost:8080/api 9 | 10 | paths: 11 | /patients: 12 | get: 13 | summary: Get all patients 14 | tags: [Patients] 15 | responses: 16 | '200': 17 | description: A list of patients 18 | content: 19 | application/json: 20 | schema: 21 | type: array 22 | items: 23 | $ref: '#/components/schemas/Patient' 24 | post: 25 | summary: Add a new patient 26 | tags: [Patients] 27 | requestBody: 28 | required: true 29 | content: 30 | application/json: 31 | schema: 32 | $ref: '#/components/schemas/Patient' 33 | responses: 34 | '201': 35 | description: Patient created 36 | '400': 37 | description: Invalid input 38 | 39 | /patients/{id}: 40 | get: 41 | summary: Get patient by ID 42 | tags: [Patients] 43 | parameters: 44 | - name: id 45 | in: path 46 | required: true 47 | schema: 48 | type: string 49 | responses: 50 | '200': 51 | description: Patient found 52 | content: 53 | application/json: 54 | schema: 55 | $ref: '#/components/schemas/Patient' 56 | '404': 57 | description: Patient not found 58 | 59 | /doctors: 60 | get: 61 | summary: Get all doctors 62 | tags: [Doctors] 63 | responses: 64 | '200': 65 | description: A list of doctors 66 | content: 67 | application/json: 68 | schema: 69 | type: array 70 | items: 71 | $ref: '#/components/schemas/Doctor' 72 | post: 73 | summary: Add a new doctor 74 | tags: [Doctors] 75 | requestBody: 76 | required: true 77 | content: 78 | application/json: 79 | schema: 80 | $ref: '#/components/schemas/Doctor' 81 | responses: 82 | '201': 83 | description: Doctor created 84 | '400': 85 | description: Duplicate license or invalid input 86 | 87 | /users: 88 | post: 89 | summary: Register a new user 90 | tags: [Users] 91 | requestBody: 92 | required: true 93 | content: 94 | application/json: 95 | schema: 96 | $ref: '#/components/schemas/User' 97 | responses: 98 | '201': 99 | description: User created 100 | '400': 101 | description: User already exists 102 | 103 | /appointments: 104 | post: 105 | summary: Book a new appointment 106 | tags: [Appointments] 107 | requestBody: 108 | required: true 109 | content: 110 | application/json: 111 | schema: 112 | $ref: '#/components/schemas/Appointment' 113 | responses: 114 | '201': 115 | description: Appointment booked 116 | '400': 117 | description: Invalid input or time conflict 118 | 119 | components: 120 | schemas: 121 | Patient: 122 | type: object 123 | properties: 124 | id: 125 | type: string 126 | name: 127 | type: string 128 | age: 129 | type: integer 130 | required: [id, name, age] 131 | 132 | Doctor: 133 | type: object 134 | properties: 135 | id: 136 | type: string 137 | name: 138 | type: string 139 | licenseNumber: 140 | type: string 141 | required: [id, name, licenseNumber] 142 | 143 | User: 144 | type: object 145 | properties: 146 | id: 147 | type: string 148 | name: 149 | type: string 150 | role: 151 | type: string 152 | enum: [admin, doctor, patient] 153 | required: [id, name, role] 154 | 155 | Appointment: 156 | type: object 157 | properties: 158 | id: 159 | type: string 160 | patientId: 161 | type: string 162 | doctorId: 163 | type: string 164 | time: 165 | type: string 166 | format: date-time 167 | required: [id, patientId, doctorId, time] 168 | -------------------------------------------------------------------------------- /Assignment 9/Reflection.md: -------------------------------------------------------------------------------- 1 | # DOMAIN MODEL REFLECTION 2 | 3 | ### Reflection on Designing the Domain Model and Class Diagram 4 | 5 | Designing the domain model and class diagram for the Hospital Appointment Scheduling System was both a rewarding and challenging process. As the system touches on multiple user roles (patients, doctors, admins), integrates functional interactions (booking, canceling, notifications), and must adhere to both functional and non-functional requirements, it required careful planning to translate textual requirements into structured design. 6 | 7 | 8 | #### **1. Challenges Faced** 9 | 10 | One of the major challenges was abstracting the correct set of domain entities while ensuring the model remained both comprehensive and manageable. Initially, it was tempting to define too many classes (e.g., for each feature like `Reminder`, `ScheduleManager`, or `MessageService`). However, I realized that bloating the model could make it unnecessarily complex and hard to maintain. 11 | 12 | Another difficulty was identifying appropriate relationships and multiplicities between classes. For example, understanding that an `Appointment` should always link to exactly one `Doctor` and one `Patient`, while a `Doctor` or `Patient` could have many appointments, required reviewing both real-world logic and the use case scenarios. Implementing inheritance also posed a challenge — deciding which attributes and methods should belong in the `User` superclass versus what should be specialized in subclasses like `Doctor` or `Patient`. 13 | 14 | Defining methods for each class also involved deep consideration. Some responsibilities could be spread across multiple classes (e.g., canceling an appointment could be allowed by both patients and admins), so ensuring that the methods matched each class's role without redundancy required a few iterations. 15 | 16 | #### **2. Alignment with Previous Assignments** 17 | 18 | The class diagram and domain model closely reflect prior work, including the requirements document, use case definitions, and state diagrams. Each core function in the functional requirements — such as appointment booking, cancellation, login, availability check, and notifications — is represented by corresponding classes and methods. 19 | 20 | For example: 21 | - The **Use Case: Book Appointment** translates into the `bookAppointment()` method in the `Patient` class. 22 | - The **State Diagram: Appointment Lifecycle** aligns with the `Appointment` class methods like `confirm()` and `cancel()`. 23 | - The **Functional Requirement: Notifications** is captured by the `Notification` class and its `send()` and `scheduleReminder()` methods. 24 | 25 | Additionally, the non-functional requirements like **role-based access**, **data persistence**, and **usability** informed the inclusion of a clear hierarchy (`User` inheritance), modular responsibilities, and a separation of concerns (e.g., notifications separated from appointment logic). 26 | 27 | #### **3. Trade-offs Made** 28 | 29 | Some trade-offs were made to maintain clarity and reduce complexity. For instance, instead of deeply modeling internal systems like `FileManager`, `AvailabilityManager`, or `ReminderService`, we focused on high-level domain entities and their primary responsibilities. This made the diagram easier to understand while leaving room for future expansion. 30 | 31 | In terms of composition vs. inheritance, I chose to use inheritance for user roles (`Patient`, `Doctor`, `Admin`) to reflect shared behaviors like login/logout, rather than embedding them within `User` as composed objects. This simplified role-based behavior modeling and aligned with object-oriented best practices. 32 | 33 | Another trade-off involved leaving out fine-grained control logic (e.g., checking if an appointment is within working hours), which would typically be handled in the business logic layer, not the domain model. 34 | 35 | #### **4. Lessons Learned** 36 | 37 | This project taught me the importance of thinking abstractly but practically when designing systems. Object-oriented design isn’t just about representing objects but also about responsibility assignment and ensuring cohesion within classes and low coupling between them. 38 | 39 | I learned that creating a solid domain model early on serves as a blueprint for later development phases — including coding, testing, and UI design. Properly defining responsibilities and relationships helps avoid logic duplication and paves the way for easier maintenance and future enhancements. 40 | 41 | Most importantly, I learned that **clear design decisions** backed by requirement traceability improve the system’s coherence. Aligning diagrams with previous artifacts, such as use cases and state diagrams, ensures that every part of the system is justified and purposeful. 42 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Hospital_Appointment_Scheduling 2 | 3 | ## Introduction 4 | 5 | This is a **Hospital Appointment System** that I created using Java to manage appointments in a hospital. It allows users to log in as either an **Admin**, **Doctor**, or **Patient**, with each role having different privileges. Patients can book appointments with doctors, while admins can cancel appointments and view all appointments. The system also supports searching for appointments by patient or doctor name. Appointments are stored in a text file, ensuring data persistence between sessions. This application also provides a simple graphical user interface (GUI) for easy interaction. 6 | 7 | ### LINKS 8 | [specification.md](Documentation/Specification.md) 9 | 10 | [Architecture.md](Documentation/Architecture.md) 11 | 12 | ### Assignment 8 Links 13 | 14 | [Assignment 8 folder](https://github.com/mbalitoh56/Hospital_Appointment_Scheduling/tree/6fa67baaa000b23ae6c079d92b74190ac97a6589/Assignment%208) 15 | 16 | [Activity Diagram.md](https://github.com/mbalitoh56/Hospital_Appointment_Scheduling/blob/ca2cb1f34e96ded519fc012fd67ae675491467ec/Assignment%208/Activity%20Diagram.md) 17 | 18 | [State Transition](https://github.com/mbalitoh56/Hospital_Appointment_Scheduling/blob/df715f1cac7228ee5500872c32c253ae43439727/Assignment%208/State%20transition.md) 19 | 20 | ### Assignment 9 Links 21 | 22 | [Assignment 9 folder](https://github.com/mbalitoh56/Hospital_Appointment_Scheduling/tree/eb04e8930300a51e30b2a347a2fcfd49541683a6/Assignment%209) 23 | 24 | [Domain Model](https://github.com/mbalitoh56/Hospital_Appointment_Scheduling/blob/bbd5d8afb74ef453b32148ed81b25ff9001798ff/Assignment%209/Domain%20Model%20Document.md) 25 | 26 | [Reflection](https://github.com/mbalitoh56/Hospital_Appointment_Scheduling/blob/8b563be4b929c13a1c8dadef8f4bc70a890aea77/Assignment%209/Reflection.md) 27 | 28 | ### Assignment 10 Links 29 | 30 | [Assignment 10 folder](https://github.com/mbalitoh56/Hospital_Appointment_Scheduling/tree/011a8ba6df0a7dbfe6ce79ef7a7a18742e56f1e0/Assignment%2010) 31 | 32 | [Language Choice](https://github.com/mbalitoh56/Hospital_Appointment_Scheduling/blob/4a69b157f26c9a4bed54a3397ab165c9f3289fcc/Assignment%2010/src/README.md) 33 | 34 | [Change Log](https://github.com/mbalitoh56/Hospital_Appointment_Scheduling/blob/70f464644a2936c7bcca347cc3009534d4af8620/Assignment%2010/CHANGELOG.md) 35 | 36 | 37 | 38 | 39 | --- 40 | 41 | # Assignment 13 42 | 43 | ### ✅ How to Run Tests Locally 44 | 45 | Providing clear instructions for running tests. For a Java Maven project, include: 46 | 47 | ````markdown 48 | ### Running Tests Locally 49 | 50 | Ensure you have Java and Maven installed. Then, execute: 51 | 52 | ```bash 53 | mvn test 54 | ```` 55 | 56 | This command runs all unit and integration tests. 57 | 58 | ```` 59 | :contentReference[oaicite:8]{index=8} 60 | 61 | ### ✅ How the CI/CD Pipeline Works 62 | 63 | :contentReference[oaicite:10]{index=10}:contentReference[oaicite:12]{index=12} 64 | 65 | 66 | ```markdown 67 | ### CI/CD Pipeline Overview 68 | 69 | Our GitHub Actions workflow performs the following: 70 | 71 | - **On Pull Requests to `master`**: 72 | - Checks out the code. 73 | - Sets up the Java environment. 74 | - Runs unit and integration tests. 75 | 76 | - **On Pushes to `master`**: 77 | - Executes all tests. 78 | - Builds the JAR artifact. 79 | - Uploads the artifact to GitHub Releases. 80 | ```` 81 | 82 | 83 | --- 84 | 85 | ## 2. Configure Pull Request (PR) Checks 86 | 87 | To ensure that tests must pass before merging: 88 | 89 | 1. Navigate to your repository on GitHub. 90 | 2. Click on **Settings** > **Branches**. 91 | 3. Under **Branch protection rules**, click **Add rule**. 92 | 4. Specify the branch name pattern, typically `main`. 93 | 5. Check **Require status checks to pass before merging**. 94 | 6. Select the specific checks (e.g., your CI workflow) that must pass. 95 | 7. Click **Create** or **Save changes**. 96 | 97 | This setup ensures that any PR failing the specified checks cannot be merged. 98 | 99 | --- 100 | 101 | ## 3. Screenshot of a PR Blocked by Failing Tests 102 | 103 | After setting up the branch protection rules, create a PR with failing tests to verify the enforcement. The PR interface will display a message indicating that merging is blocked due to failing checks. 104 | 105 | ## Screenshots 106 | 107 | ### Test Results 108 | 109 | ![1](https://github.com/user-attachments/assets/8803cc3c-8b34-4418-8271-34792a495065) 110 | 111 | ![2](https://github.com/user-attachments/assets/002b0ee9-3aae-4885-9549-01e815fe8fed) 112 | 113 | ### Artifacts failed 114 | 115 | ![4](https://github.com/user-attachments/assets/f9c33935-a54d-436e-aceb-d260bf36bbdb) 116 | 117 | 118 | 119 | ### Blocked by Failing Tests 120 | 121 | ![3](https://github.com/user-attachments/assets/9443121f-28ba-41b5-865f-53fbd3db529e) 122 | 123 | 124 | -------------------------------------------------------------------------------- /Assignment 9/Domain Model Document.md: -------------------------------------------------------------------------------- 1 | # DOMAIN MODELLING 2 | 3 | ## Domain Model 4 | 5 | | **Entity** | **Attributes** | **Methods** | **Relationships** | 6 | |------------|----------------|-------------|-------------------| 7 | | **User** *(Abstract)* | userID, username, password, role | login(), logout() | Parent of Patient, Doctor, Admin | 8 | | **Patient** | patientID, name, contactInfo, dateOfBirth | bookAppointment(), cancelAppointment(), viewAppointments() | Inherits from User; Creates Appointment(s) | 9 | | **Doctor** | doctorID, name, specialization, availabilitySchedule | viewAppointments(), updateAvailability() | Inherits from User; Receives Appointment(s) | 10 | | **Admin** | adminID, name | viewAllAppointments(), cancelAnyAppointment(), manageUsers() | Inherits from User | 11 | | **Appointment** | appointmentID, patientID, doctorID, date, time, status | confirm(), cancel(), notify() | Linked to Patient and Doctor | 12 | | **Notification** | notificationID, userID, message, timestamp | send(), scheduleReminder() | Sent to Patient and Doctor | 13 | | **SystemSession** | sessionID, userID, loginTime, logoutTime | trackSession(), endSession() | Logs system activity for Users | 14 | 15 | 16 | ### Relationships Summary 17 | 18 | - Patient books Appointment 19 | - Doctor receives Appointment 20 | - Admin manages Appointments and Users 21 | - Appointment involves Patient and Doctor 22 | - Notification sent to Patient and Doctor 23 | - User has SystemSession 24 | - User superclass inherited by Patient, Doctor, Admin 25 | 26 | 27 | ### Business Rules 28 | 29 | 1. A **doctor** cannot be booked for more than one appointment at the same time. 30 | 2. **Patients** can only view or cancel their own appointments. 31 | 3. **Admins** can cancel or create any appointment. 32 | 4. **Reminders** must be sent 24 hours before appointments. 33 | 5. **Appointment data** must be saved on system exit and available after restart. 34 | 6. A **user must select a role** when logging in. 35 | 7. **Input validation** is required for all user entries (e.g., date/time formats). 36 | 8. **Notifications** must be sent after every booking or cancellation. 37 | 38 | --- 39 | 40 | # CLASS DIAGRAM 41 | 42 | ``` mermaid 43 | classDiagram 44 | %% Abstract Base Class 45 | class User { 46 | -userID: String 47 | -username: String 48 | -password: String 49 | -role: String 50 | +login() 51 | +logout() 52 | } 53 | 54 | %% Subclasses 55 | class Patient { 56 | -patientID: String 57 | -name: String 58 | -contactInfo: String 59 | -dateOfBirth: String 60 | +bookAppointment() 61 | +cancelAppointment() 62 | +viewAppointments() 63 | } 64 | 65 | class Doctor { 66 | -doctorID: String 67 | -name: String 68 | -specialization: String 69 | -availabilitySchedule: Map 70 | +viewAppointments() 71 | +updateAvailability() 72 | } 73 | 74 | class Admin { 75 | -adminID: String 76 | -name: String 77 | +viewAllAppointments() 78 | +cancelAnyAppointment() 79 | +manageUsers() 80 | } 81 | 82 | class Appointment { 83 | -appointmentID: String 84 | -date: String 85 | -time: String 86 | -status: String 87 | +confirm() 88 | +cancel() 89 | +notify() 90 | } 91 | 92 | class Notification { 93 | -notificationID: String 94 | -message: String 95 | -timestamp: String 96 | +send() 97 | +scheduleReminder() 98 | } 99 | 100 | class SystemSession { 101 | -sessionID: String 102 | -loginTime: String 103 | -logoutTime: String 104 | +trackSession() 105 | +endSession() 106 | } 107 | 108 | %% Inheritance 109 | Patient --|> User 110 | Doctor --|> User 111 | Admin --|> User 112 | 113 | %% Relationships 114 | Patient "1" --> "0..*" Appointment : books 115 | Doctor "1" --> "0..*" Appointment : receives 116 | Admin "1" --> "0..*" Appointment : manages 117 | Appointment "1" --> "1" Doctor : assignedTo 118 | Appointment "1" --> "1" Patient : scheduledBy 119 | Notification "0..*" --> "1" User : sentTo 120 | User "1" --> "0..*" SystemSession : initiates 121 | ``` 122 | 123 | ### Key Design Decisions 124 | **Inheritance:** User is abstract and generalized into Patient, Doctor, and Admin, which reflects role-based access and behavior. 125 | 126 | **Composition:** Appointment must be linked to both a Patient and a Doctor, hence 1..1 multiplicity for both. 127 | 128 | **Multiplicity:** Each Patient and Doctor can be involved in multiple appointments (0..*), while each Appointment is always associated with exactly one of each. 129 | 130 | **Separation of Concerns:** Notification and SystemSession are independent support entities linked to User for reminders and login tracking respectively. 131 | -------------------------------------------------------------------------------- /Assignment 8/State transition.md: -------------------------------------------------------------------------------- 1 | # 8 Critical Objects 2 | ### Critical Objects: 3 | 1. Appointment 4 | 2. User Account 5 | 3. Doctor Availability 6 | 4. Notification 7 | 5. System Session 8 | 6. Booking Request 9 | 7. Patient Profile 10 | 8. Admin Action 11 | 12 | --- 13 | ## State Transition Diagram 14 | ### 1. **Appointment** 15 | 16 | ```mermaid 17 | stateDiagram-v2 18 | [*] --> Requested 19 | Requested --> Confirmed : Doctor accepts 20 | Requested --> Canceled : Patient/Admin cancels 21 | Confirmed --> Completed : Appointment time reached 22 | Confirmed --> Canceled : Patient/Admin cancels 23 | Completed --> Archived : After a period of time 24 | Canceled --> Archived : After a period of time 25 | ``` 26 | 27 | ### Explanation: 28 | - **Key States:** 29 | - `Requested`: Patient books an appointment. 30 | - `Confirmed`: Doctor confirms the appointment. 31 | - `Completed`: The appointment has taken place. 32 | - `Canceled`: Appointment is canceled before it happens. 33 | - `Archived`: Moved to history for recordkeeping. 34 | - **Transitions:** 35 | - Booking request → Requested. 36 | - Doctor accepts → Confirmed. 37 | - Time passes or user cancels → Completed or Canceled. 38 | - Both completed and canceled appointments move to `Archived`. 39 | - **Functional Requirement Mapping:** 40 | - “The ‘Canceled’ state addresses FR-003: Allow users to cancel their own appointments.” 41 | - “The ‘Completed’ state supports appointment tracking and fulfillment (FR-002 & FR-005).” 42 | 43 | --- 44 | 45 | Great! Let's create state transition diagrams and explanations in Mermaid for the following system objects: 46 | 47 | --- 48 | 49 | ### 2. **User Account** 50 | 51 | ```mermaid 52 | stateDiagram-v2 53 | [*] --> Registered 54 | Registered --> Active : User logs in 55 | Active --> Inactive : User logs out 56 | Active --> Locked : Multiple failed login attempts 57 | Locked --> Active : Admin unlocks account 58 | Active --> Deleted : User account deleted 59 | ``` 60 | 61 | **Explanation:** 62 | 63 | - **Key States:** Registered, Active, Inactive, Locked, Deleted. 64 | - **Transitions:** 65 | - `Registered → Active` when user logs in successfully. 66 | - `Active → Locked` if too many failed login attempts. 67 | - `Locked → Active` when an admin unlocks it. 68 | - `Active → Deleted` when the account is deleted. 69 | - **Functional Mapping:** Supports **FR-001 (User Authentication)** and **FR-008 (Role-Based Access Control)**. 70 | 71 | --- 72 | 73 | ### 3. **Doctor Availability** 74 | 75 | ```mermaid 76 | stateDiagram-v2 77 | [*] --> Available 78 | Available --> Unavailable : Doctor marks time off 79 | Available --> Booked : Appointment scheduled 80 | Booked --> Available : Appointment completed/cancelled 81 | Unavailable --> Available : Doctor becomes available 82 | ``` 83 | 84 | **Explanation:** 85 | 86 | - **Key States:** Available, Booked, Unavailable. 87 | - **Transitions:** 88 | - `Available → Booked` triggered by a confirmed appointment. 89 | - `Booked → Available` after the appointment is done or canceled. 90 | - **Functional Mapping:** Supports **FR-005 (Doctor Availability Check)**. 91 | 92 | --- 93 | 94 | ### 4. **Notification** 95 | 96 | ```mermaid 97 | stateDiagram-v2 98 | [*] --> Created 99 | Created --> Sent : Triggered by booking/cancellation 100 | Sent --> Read : User opens notification 101 | Read --> Archived : User chooses to archive 102 | ``` 103 | 104 | **Explanation:** 105 | 106 | - **Key States:** Created, Sent, Read, Archived. 107 | - **Transitions:** 108 | - `Created → Sent` when the event triggers notification. 109 | - `Sent → Read` when user views it. 110 | - **Functional Mapping:** Aligns with **FR-006 (Notifications & Reminders)**. 111 | 112 | --- 113 | 114 | ### 5. **System Session** 115 | 116 | ```mermaid 117 | stateDiagram-v2 118 | [*] --> NotStarted 119 | NotStarted --> Active : User logs in 120 | Active --> Idle : Inactivity timeout 121 | Idle --> Active : User resumes 122 | Active --> Terminated : User logs out or session timeout 123 | ``` 124 | 125 | **Explanation:** 126 | 127 | - **Key States:** NotStarted, Active, Idle, Terminated. 128 | - **Transitions:** 129 | - `Active → Idle` due to inactivity. 130 | - `Idle → Active` if the user returns. 131 | - **Functional Mapping:** Relates to **FR-009 (Exit & Auto-Save)** and **FR-001 (Authentication)**. 132 | 133 | --- 134 | 135 | ### 6. **Booking Request** 136 | 137 | ```mermaid 138 | stateDiagram-v2 139 | [*] --> Initiated 140 | Initiated --> Pending : Submitted by user 141 | Pending --> Confirmed : Doctor accepts 142 | Pending --> Rejected : Doctor rejects 143 | Confirmed --> Completed : Appointment occurs 144 | Confirmed --> Canceled : Canceled by patient/admin 145 | ``` 146 | 147 | **Explanation:** 148 | 149 | - **Key States:** Initiated, Pending, Confirmed, Rejected, Canceled, Completed. 150 | - **Transitions:** 151 | - Reflect real-world appointment flows. 152 | - **Functional Mapping:** Covers **FR-002 (Booking)**, **FR-003 (Cancellation)**, **FR-004 (Search)**. 153 | 154 | --- 155 | 156 | ### 7. **Patient Profile** 157 | 158 | ```mermaid 159 | stateDiagram-v2 160 | [*] --> Created 161 | Created --> Active : Profile filled completely 162 | Active --> Updated : Patient updates info 163 | Active --> Deactivated : User deletes profile 164 | ``` 165 | 166 | **Explanation:** 167 | 168 | - **Key States:** Created, Active, Updated, Deactivated. 169 | - **Transitions:** 170 | - Allow patients to manage their own info. 171 | - **Functional Mapping:** Supports user-centric access and data control. 172 | 173 | --- 174 | 175 | ### 8. **Admin Action** 176 | 177 | ```mermaid 178 | stateDiagram-v2 179 | [*] --> Idle 180 | Idle --> Reviewing : Admin checks appointment requests 181 | Reviewing --> Approved : Approves appointment or action 182 | Reviewing --> Rejected : Declines or flags 183 | Approved --> Completed : Appointment done 184 | Rejected --> Archived : Moved to history 185 | ``` 186 | 187 | **Explanation:** 188 | 189 | - **Key States:** Idle, Reviewing, Approved, Rejected, Completed, Archived. 190 | - **Transitions:** 191 | - Admin control and review flow. 192 | - **Functional Mapping:** Tied to **FR-003 (Cancellation)** and **FR-008 (Role-Based Access)**. 193 | 194 | --- 195 | -------------------------------------------------------------------------------- /Assignment 14/CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # CONTRIBUTING 2 | 3 | 4 | # 🏥 Contributing to the Hospital Appointment Scheduling System 5 | 6 | Thank you for considering contributing to our project! Your involvement helps improve the system for users and developers alike. 7 | 8 | 9 | 10 | ## 📦 Setup Instructions 11 | 12 | ### Prerequisites 13 | 14 | - **Java 17** or higher 15 | - **Maven 3.8+** 16 | - A GitHub account 17 | 18 | ### Installation 19 | 20 | 1. **Fork the Repository** 21 | Click the **Fork** button at the top right of the [repository page](https://github.com/yourusername/hospital_appointment_scheduling) to create your own copy. 22 | 23 | 2. **Clone Your Fork** 24 | Open your terminal and run: 25 | 26 | ```bash 27 | git clone https://github.com/yourusername/hospital_appointment_scheduling.git 28 | cd hospital_appointment_scheduling 29 | 30 | 31 | 3. **Build the Project** 32 | Compile the project and download dependencies: 33 | 34 | ```bash 35 | mvn clean install 36 | ``` 37 | 38 | 4. **Run the Application** 39 | Start the application using: 40 | 41 | ```bash 42 | mvn spring-boot:run 43 | ``` 44 | 45 | Access the application at `http://localhost:8080`. 46 | 47 | 48 | 49 | ## 🧹 Coding Standards 50 | 51 | To maintain code quality and consistency, please adhere to the following standards: 52 | 53 | * **Code Formatting**: Use [Google Java Format](https://github.com/google/google-java-format) for consistent code styling. You can integrate it with your IDE or run it via Maven using the [Spotless plugin](https://github.com/diffplug/spotless). 54 | 55 | * **Linting**: Utilize [Checkstyle](https://checkstyle.sourceforge.io/) to enforce coding standards. Run the following command to check for style violations: 56 | 57 | ```bash 58 | mvn checkstyle:check 59 | ``` 60 | 61 | * **Testing**: Write unit and integration tests for your code. Ensure all tests pass before submitting a pull request: 62 | 63 | ```bash 64 | mvn test 65 | ``` 66 | 67 | * **Commit Messages**: Follow the [Conventional Commits](https://www.conventionalcommits.org/) specification for clear and descriptive commit messages. 68 | 69 | 70 | 71 | ## 🛠️ How to Contribute 72 | 73 | 1. **Pick an Issue** 74 | Browse the [Issues](https://github.com/mbalitoh56/hospital_appointment_scheduling/issues) tab and look for issues labeled `good first issue` for beginner-friendly tasks. 75 | 76 | 2. **Create a Branch** 77 | Create a new branch for your work: 78 | 79 | ```bash 80 | git checkout -b feature/your-feature-name 81 | ``` 82 | 83 | 3. **Make Changes** 84 | Implement your feature or fix, adhering to the coding standards mentioned above. 85 | 86 | 4. **Commit Your Changes** 87 | Commit your changes with a descriptive message: 88 | 89 | ```bash 90 | git commit -m "feat: add appointment scheduling feature" 91 | ``` 92 | 93 | 5. **Push to Your Fork** 94 | Push your branch to your forked repository: 95 | 96 | ```bash 97 | git push origin feature/your-feature-name 98 | ``` 99 | 100 | 6. **Submit a Pull Request** 101 | Open a pull request against the `master` branch of the original repository. Provide a clear description of your changes and reference any related issues. 102 | 103 | --- 104 | 105 | ## 🔍 Need Help? 106 | 107 | If you have questions or need assistance: 108 | 109 | * Open an issue with the `question` label. 110 | 111 | We appreciate your contributions and look forward to collaborating with you! 112 | 113 | 114 | --- 115 | 116 | 117 | # TAGS ISSUES for CONTRIBUTORS 118 | 119 | 120 | 121 | 122 | ## Navigating Labeled Issues 123 | 124 | Welcome to the Hospital Appointment Scheduling System project! This guide will help you find and understand issues labeled for contribution. 125 | 126 | ## 🔍 Finding Labeled Issues 127 | 128 | To discover issues by label: 129 | 130 | 1. **Navigate to the Issues Tab**: 131 | 132 | * Go to the repository's main page. 133 | * Click on the **"Issues"** tab. 134 | 135 | 2. **Filter by Labels**: 136 | 137 | * On the right sidebar, locate the **"Labels"** section. 138 | * Click on a label (e.g., `good first issue` or `feature-request`) to filter issues accordingly. 139 | 140 | 3. **Use the Search Bar**: 141 | 142 | * At the top of the Issues page, use the search bar to input queries like: 143 | 144 | * `is:issue is:open label:"good first issue"` 145 | * `is:issue is:open label:"feature-request"` 146 | 147 | * To filter issues that have both labels: 148 | 149 | * `is:issue is:open label:"good first issue" label:"feature-request"` 150 | 151 | * To filter issues that have either label: 152 | 153 | * `is:issue is:open label:"good first issue","feature-request"` 154 | 155 | *Note*: Using a comma between labels applies a logical OR, while separating labels with spaces applies a logical AND. 156 | 157 | ## 🏁 Understanding Common Labels 158 | 159 | * **`good first issue`**: Ideal for newcomers; these issues are well-defined and don't require deep knowledge of the codebase. 160 | 161 | * **`feature-request`**: Suggestions for new features or enhancements to the project. 162 | 163 | ## 🤝 Getting Started 164 | 165 | 1. **Choose an Issue**: 166 | 167 | * Browse through the labeled issues and select one that interests you. 168 | 169 | 2. **Express Interest**: 170 | 171 | * Comment on the issue to let others know you're working on it. 172 | 173 | 3. **Fork the Repository**: 174 | 175 | * Click on the **"Fork"** button at the top-right corner of the repository page. 176 | 177 | 4. **Clone Your Fork**: 178 | 179 | * Use `git clone` to clone your forked repository to your local machine. 180 | 181 | 5. **Create a New Branch**: 182 | 183 | * Use `git checkout -b your-branch-name` to create and switch to a new branch. 184 | 185 | 6. **Make Your Changes**: 186 | 187 | * Implement the necessary changes or additions. 188 | 189 | 7. **Commit and Push**: 190 | 191 | * Commit your changes with a descriptive message and push them to your forked repository. 192 | 193 | 8. **Submit a Pull Request**: 194 | 195 | * Navigate to the original repository and click on **"New Pull Request"**. 196 | * Provide a clear description of your changes and reference the issue number. 197 | 198 | ## 📘 Additional Resources 199 | 200 | * [GitHub Docs: Managing Labels](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels) 201 | * [GitHub Docs: Filtering and Searching Issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/filtering-and-searching-issues-and-pull-requests) 202 | 203 | 204 | -------------------------------------------------------------------------------- /Capstone DesignPhase.md: -------------------------------------------------------------------------------- 1 | # Architecture 2 | 3 | ```mermaid 4 | %%{init: {"themeVariables": {"primaryColor": "#f9f9f9","edgeLabelBackground":"#ffffff","fontFamily":"Arial"}}}%% 5 | graph TB 6 | %% Presentation Layer - Light Blue 7 | PL["Presentation Layer - Frontend 8 | - Dashboard (Quotations, Invoices, Payments) 9 | - Quotation Creation Form 10 | - Invoice Generation Form 11 | - Reports & Analytics Pages 12 | Technologies: Angular, HTML, CSS, JS"] 13 | style PL fill:#d0e7ff,stroke:#4da6ff,stroke-width:2px,color:#000 14 | 15 | %% Application Layer - Light Green 16 | AL["Application Layer - Backend 17 | - User Management Service 18 | - Client Management Service 19 | - Quotation Service 20 | - Invoice Service 21 | - Notification Service (Email/SMS) 22 | - Reporting Service 23 | Technologies: Java Spring Boot / Node.js / PHP Laravel"] 24 | style AL fill:#d0ffd6,stroke:#33cc33,stroke-width:2px,color:#000 25 | 26 | %% Database Layer - Light Orange 27 | DB["Database Layer 28 | - User Table 29 | - Client Table 30 | - Quotation Table 31 | - Invoice Table 32 | - Payment Table 33 | Technologies: MySQL / PostgreSQL"] 34 | style DB fill:#ffe0b3,stroke:#ff9933,stroke-width:2px,color:#000 35 | 36 | %% Layer connections 37 | PL -->|Calls APIs| AL 38 | AL -->|Reads/Writes Data| DB 39 | 40 | ``` 41 | 42 | # Database 43 | 44 | ```mermaid 45 | erDiagram 46 | USERS { 47 | int UserID PK 48 | string Name 49 | string Email 50 | string Password 51 | string Role 52 | } 53 | 54 | CLIENTS { 55 | int ClientID PK 56 | string Name 57 | string Contact 58 | string Email 59 | string Address 60 | } 61 | 62 | QUOTATIONS { 63 | int QuoteID PK 64 | int ClientID FK 65 | date DateCreated 66 | float TotalAmount 67 | string Status 68 | } 69 | 70 | INVOICES { 71 | int InvoiceID PK 72 | int QuoteID FK 73 | int ClientID FK 74 | date InvoiceDate 75 | float AmountDue 76 | string Status 77 | } 78 | 79 | PAYMENTS { 80 | int PaymentID PK 81 | int InvoiceID FK 82 | date PaymentDate 83 | float PaymentAmount 84 | string PaymentMethod 85 | } 86 | 87 | CLIENTS ||--o{ QUOTATIONS : has 88 | QUOTATIONS ||--o{ INVOICES : generates 89 | CLIENTS ||--o{ INVOICES : receives 90 | INVOICES ||--o{ PAYMENTS : records 91 | ``` 92 | 93 | # Dataflow Diagram 94 | 95 | ```mermaid 96 | flowchart TD 97 | A[Client / User] -->|Request Quotation| B[Frontend Interface] 98 | B -->|Send Request| C[Quotation Service] 99 | C -->|Retrieve Client Info| D[Client Database] 100 | C -->|Save Quotation| E[Quotation Database] 101 | C -->|Send Quotation| A 102 | A -->|Approve Quotation| C 103 | C -->|Generate Invoice| F[Invoice Service] 104 | F -->|Save Invoice| G[Invoice Database] 105 | F -->|Send Invoice| A 106 | A -->|Make Payment| H[Payment Service] 107 | H -->|Save Payment| I[Payment Database] 108 | H -->|Update Invoice Status| G 109 | ``` 110 | 111 | # 2.2 System Interaction Diagram (SID) 112 | 113 | ```mermaid 114 | sequenceDiagram 115 | participant Client as Client/User 116 | participant Frontend as Frontend UI 117 | participant Backend as Backend Services 118 | participant DB as Database 119 | 120 | Client->>Frontend: Login / Request Quotation 121 | Frontend->>Backend: Validate User / Process Request 122 | Backend->>DB: Retrieve Client Details 123 | DB-->>Backend: Return Client Data 124 | Backend->>DB: Save Quotation 125 | Backend-->>Frontend: Send Quotation Confirmation 126 | Frontend-->>Client: Display Quotation 127 | 128 | Client->>Frontend: Approve Quotation 129 | Frontend->>Backend: Generate Invoice 130 | Backend->>DB: Save Invoice 131 | Backend-->>Frontend: Send Invoice 132 | Frontend-->>Client: Display Invoice 133 | 134 | Client->>Frontend: Make Payment 135 | Frontend->>Backend: Process Payment 136 | Backend->>DB: Save Payment & Update Invoice Status 137 | Backend-->>Frontend: Payment Confirmation 138 | Frontend-->>Client: Display Payment Status 139 | ``` 140 | 141 | # NEW 142 | 143 | ## High-Level Architecture 144 | ```mermaid 145 | flowchart TD 146 | User["End User"] --> UI["Frontend - Angular or React"] 147 | UI --> API["Backend API - Spring Boot or Node.js"] 148 | API --> DB["Database: PostgreSQL or MySQL"] 149 | API --> Reports["Reporting Service"] 150 | Reports --> Export["Export Formats: PDF, Excel, CSV"] 151 | 152 | ``` 153 | 154 | ## Entity Relationship Diagram (ERD) 155 | ```mermaid 156 | erDiagram 157 | CUSTOMER ||--o{ QUOTE : "requests" 158 | CUSTOMER ||--o{ INVOICE : "receives" 159 | CUSTOMER ||--o{ PAYMENT : "makes" 160 | 161 | QUOTE ||--o{ QUOTELINEITEM : "contains" 162 | INVOICE ||--o{ INVOICELINEITEM : "contains" 163 | 164 | INVOICE ||--o{ PAYMENT : "paid_by" 165 | INVOICE ||--o{ CREDITNOTE : "adjusted_by" 166 | 167 | TEMPLATE ||--o{ QUOTE : "applied_to" 168 | TEMPLATE ||--o{ INVOICE : "applied_to" 169 | 170 | REPORT ||--o{ CUSTOMER : "analyzes" 171 | REPORT ||--o{ INVOICE : "analyzes" 172 | REPORT ||--o{ PAYMENT : "analyzes" 173 | ``` 174 | 175 | ## Quote Workflow 176 | ```mermaid 177 | stateDiagram-v2 178 | [*] --> Draft 179 | Draft --> Review : "Submit for approval" 180 | Review --> Approved : "Manager approves" 181 | Review --> Rejected : "Manager rejects" 182 | Approved --> Sent : "Send to customer" 183 | Sent --> Converted : "Convert to Sales Order" 184 | Sent --> Expired : "Expiration date passed" 185 | Converted --> [*] 186 | Expired --> [*] 187 | ``` 188 | 189 | ## Invoice Workflow 190 | ```mermaid 191 | stateDiagram-v2 192 | [*] --> Draft 193 | Draft --> Sent : "Send to customer" 194 | Sent --> Paid : "Payment received" 195 | Sent --> Overdue : "Past due date" 196 | Overdue --> Paid : "Customer settles" 197 | Overdue --> WrittenOff : "Write-off decision" 198 | Paid --> [*] 199 | WrittenOff --> [*] 200 | ``` 201 | 202 | ## Recurring Invoice Workflow 203 | ```mermaid 204 | flowchart LR 205 | Template["Recurring Invoice Template"] --> Schedule["Billing Schedule - Monthly/Quarterly/Yearly"] 206 | Schedule --> AutoGen["Automatic Invoice Generation"] 207 | AutoGen --> Notify["Customer Notification"] 208 | AutoGen --> Invoice["Invoice Created"] 209 | Invoice --> Payment["Payment Tracking"] 210 | ``` 211 | 212 | ## Overdue Collection Workflow 213 | ```mermaid 214 | flowchart TD 215 | Overdue["Overdue Invoice"] --> Reminder1["Automated Reminder #1"] 216 | Reminder1 --> Reminder2["Automated Reminder #2"] 217 | Reminder2 --> Collection["Collection Workflow"] 218 | Collection --> Communication["Customer Communication"] 219 | Communication --> Resolution["Payment / Write-off / Legal Action"] 220 | ``` 221 | 222 | ## Reporting Dashboard 223 | ```mermaid 224 | flowchart TD 225 | Reports["Reports Module"] --> Aging["Invoice Aging Report"] 226 | Reports --> Sales["Sales Analysis"] 227 | Reports --> PaymentPerf["Payment Performance"] 228 | Reports --> Overdue["Overdue & Collections"] 229 | Reports --> Tax["Tax Reports"] 230 | Reports --> Custom["Custom Report Builder"] 231 | 232 | 233 | 234 | 235 | -------------------------------------------------------------------------------- /Documentation/SystemRequirementsDocument.md: -------------------------------------------------------------------------------- 1 | # SYSTEM REQUIREMENTS DOCUMENT (SRD) 2 | 3 | ## STAKEHOLDER ANALYSIS 4 | 5 | ### 1. Patients 6 | 7 | **Role:** Users who book appointments with doctors. 8 | 9 | **Key Concerns:** 10 | - Easy appointment booking and cancellation. 11 | - Access to doctors' availability. 12 | - Timely notifications about upcoming appointments. 13 | 14 | **Pain Points:** 15 | - Difficulty in finding available doctors. 16 | - No reminder system for scheduled appointments. 17 | - Long waiting times at the hospital due to overbooking. 18 | 19 | **Success Metrics:** 20 | - 30% reduction in missed appointments. 21 | - Faster booking process (< 3 minutes per appointment). 22 | 23 | ### 2. Doctors 24 | 25 | **Role:** Provide medical consultation based on scheduled appointments. 26 | 27 | **Key Concerns:** 28 | - Efficient scheduling to avoid double bookings. 29 | - Access to patient details before appointments. 30 | - Ability to manage availability and appointment times. 31 | 32 | **Pain Points:** 33 | - No centralized system to track daily appointments. 34 | - Patients missing appointments without prior cancellation. 35 | - Overbooked time slots causing delays. 36 | 37 | **Success Metrics:** 38 | - 40% fewer scheduling conflicts. 39 | - 25% improvement in doctor-patient consultation time. 40 | 41 | ### 3. Hospital Administrators 42 | 43 | **Role:** Manage hospital operations, ensure smooth scheduling. 44 | 45 | **Key Concerns:** 46 | - Effective monitoring of doctor schedules. 47 | - Proper record-keeping of all patient appointments. 48 | - Ensuring the system reduces manual work. 49 | 50 | **Pain Points:** 51 | - Heavy reliance on paperwork for tracking appointments. 52 | - Difficulty in managing last-minute appointment changes. 53 | - No real-time insights into doctor availability. 54 | 55 | **Success Metrics:** 56 | - 50% reduction in administrative workload. 57 | - Real-time tracking of appointments for better hospital efficiency. 58 | 59 | ### 4. Receptionists 60 | 61 | **Role:** Assist patients with booking, rescheduling, and canceling appointments. 62 | 63 | **Key Concerns:** 64 | - Fast and efficient appointment handling. 65 | - Easy access to doctor schedules. 66 | - Reducing errors in appointment scheduling. 67 | 68 | **Pain Points:** 69 | - Manual tracking of doctor availability. 70 | - High workload during peak hours. 71 | - No automated confirmation messages for patients. 72 | 73 | **Success Metrics:** 74 | - 30% decrease in appointment booking errors. 75 | - Faster processing of appointment requests. 76 | 77 | ### 5. IT Support Staff 78 | 79 | **Role:** Maintain and troubleshoot the appointment scheduling system. 80 | 81 | **Key Concerns:** 82 | - Ensuring the system runs without downtime. 83 | - Secure handling of patient data. 84 | - Regular updates and maintenance. 85 | 86 | **Pain Points:** 87 | - Frequent system crashes due to increased user load. 88 | - Lack of an automated backup system. 89 | - Security vulnerabilities in patient data storage. 90 | 91 | **Success Metrics:** 92 | - 99% system uptime. 93 | - Zero data breaches within a year. 94 | 95 | ### 6. Health Insurance Providers 96 | 97 | **Role:** Verify patient eligibility and coverage for hospital visits. 98 | 99 | **Key Concerns:** 100 | - Integration with hospital billing systems. 101 | - Quick verification of patient insurance details. 102 | - Reducing fraudulent claims. 103 | 104 | **Pain Points:** 105 | - Delayed insurance verification processes. 106 | - Patients unsure of their coverage before appointments. 107 | - Poor communication between hospitals and insurance companies. 108 | 109 | **Success Metrics:** 110 | - 50% faster insurance verification process. 111 | - Reduced number of rejected claims due to miscommunication. 112 | 113 | ## FUNCTIONAL REQUIREMENTS 114 | 115 | ### 1. User Authentication & Role Management 116 | 117 | **Requirement:** The system shall allow users to log in using a username and select a role (Admin, Doctor, or Patient). 118 | 119 | **Acceptance Criteria:** 120 | - Users must be able to select their role during login. 121 | - Incorrect logins must prompt an error message. 122 | 123 | ### 2. Appointment Booking 124 | 125 | **Requirement:** The system shall allow patients and admins to book appointments with doctors. 126 | 127 | **Acceptance Criteria:** 128 | - The system must prevent double bookings for the same doctor at the same time. 129 | - Patients should receive a confirmation message upon successful booking. 130 | 131 | ### 3. Appointment Cancellation 132 | 133 | **Requirement:** The system shall allow admins to cancel any appointment and patients to cancel their own. 134 | 135 | **Acceptance Criteria:** 136 | - Users must confirm cancellation before finalizing it. 137 | - A notification must be sent to the doctor and patient upon cancellation. 138 | 139 | ### 4. Search for Appointments 140 | 141 | **Requirement:** The system shall allow users to search for appointments by patient name, doctor name, or date. 142 | 143 | **Acceptance Criteria:** 144 | - The search results must display relevant appointment details. 145 | - The system must return results in less than 2 seconds for a typical query. 146 | 147 | ### 5. Doctor Availability Check 148 | 149 | **Requirement:** The system shall prevent booking if the doctor is already scheduled for an appointment at the requested time. 150 | 151 | **Acceptance Criteria:** 152 | - If a doctor is unavailable, the system must display an error message. 153 | - Available time slots should be visible before booking. 154 | 155 | ### 6. Notifications & Reminders 156 | 157 | **Requirement:** The system shall send notifications to patients and doctors for upcoming appointments and cancellations. 158 | 159 | **Acceptance Criteria:** 160 | - Notifications must be displayed immediately after booking or cancellation. 161 | - Reminders must be sent at least 24 hours before the appointment. 162 | 163 | ### 7. Data Storage & Persistence 164 | 165 | **Requirement:** The system shall store all appointment details in a file (appointments.txt). 166 | 167 | **Acceptance Criteria:** 168 | - Appointment data must be retrievable after system restart. 169 | - Data must be saved in a structured format (e.g., CSV). 170 | 171 | ### 8. Role-Based Access Control 172 | 173 | **Requirement:** The system shall restrict actions based on user roles. 174 | 175 | **Acceptance Criteria:** 176 | - Patients can only view their own appointments. 177 | - Doctors can only view appointments assigned to them. 178 | - Admins can view, book, and cancel all appointments. 179 | 180 | ### 9. Exit & Auto-Save 181 | 182 | **Requirement:** The system shall save all appointments before closing. 183 | 184 | **Acceptance Criteria:** 185 | - Upon clicking "Exit," the system must automatically save data. 186 | - No appointment data should be lost after restarting. 187 | 188 | ### 10. Error Handling & Validation 189 | 190 | **Requirement:** The system shall validate user inputs to prevent invalid data entry. 191 | 192 | **Acceptance Criteria:** 193 | - Users must enter dates in the format YYYY-MM-DD. 194 | - Time must be entered in HH:MM format. 195 | - If incorrect data is entered, the system must display a clear error message. 196 | 197 | 198 | ## NON-FUNCTIONAL REQUIREMENTS 199 | 200 | ### 1. Usability 201 | 202 | - **Requirement:** The system shall provide a simple and intuitive graphical user interface (GUI) for easy navigation. 203 | - **Requirement:** The system shall ensure text readability and button accessibility for all users, including those with visual impairments. 204 | - **Requirement:** Error messages shall be clear and provide guidance on how to correct input mistakes. 205 | 206 | ### 2. Deployability 207 | - **Requirement:** The system shall be deployable on Windows and Linux operating systems. 208 | - **Requirement:** The system shall require Java 11 or later for execution. 209 | - **Requirement:** The system shall run as a standalone desktop application with no external database dependencies. 210 | 211 | ### 3. Maintainability 212 | - **Requirement:** The system shall include a developer guide with instructions for future enhancements and debugging. 213 | - **Requirement:** The source code shall follow clean coding practices with proper comments and documentation. 214 | - **Requirement:** The system shall support modular architecture, making it easy to add new features such as automated reminders or patient medical history tracking. 215 | 216 | ### 4. Scalability 217 | - **Requirement:** The system shall support at least 100 concurrent users without performance degradation. 218 | - **Requirement:** The system shall handle up to 10,000 appointment records efficiently. 219 | - **Requirement:** Future enhancements should allow integration with cloud-based storage solutions for scalability. 220 | 221 | ### 5. Security 222 | - **Requirement:** All stored appointment data shall be encrypted using AES-256 encryption. 223 | - **Requirement:** User authentication must include role-based access control (RBAC) to prevent unauthorized access. 224 | - **Requirement:** The system shall implement input validation to prevent SQL injection and other security threats. 225 | 226 | ### 6. Performance 227 | - **Requirement:** Appointment searches shall return results within 2 seconds. 228 | - **Requirement:** The system shall load and display the main dashboard within 5 seconds after login. 229 | - **Requirement:** The system shall automatically save appointment data within 1 second before closing. 230 | 231 | 232 | -------------------------------------------------------------------------------- /HospitalAppointmentSystem.java: -------------------------------------------------------------------------------- 1 | /* 2 | * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license 3 | * Click nbfs://nbhost/SystemFileSystem/Templates/Classes/Main.java to edit this template 4 | */ 5 | package hospitalappointmentsystem; 6 | 7 | import java.io.*; 8 | import java.util.*; 9 | import javax.swing.*; 10 | import java.awt.*; 11 | import java.awt.event.*; 12 | import java.util.ArrayList; 13 | import java.util.List; 14 | 15 | 16 | class Appointment { 17 | String patientName; 18 | String doctorName; 19 | String date; 20 | String time; 21 | String reason; 22 | 23 | public Appointment(String patientName, String doctorName, String date, String time, String reason) { 24 | this.patientName = patientName; 25 | this.doctorName = doctorName; 26 | this.date = date; 27 | this.time = time; 28 | this.reason = reason; 29 | } 30 | 31 | @Override 32 | public String toString() { 33 | return "Patient: " + patientName + " | Doctor: " + doctorName + " | Date: " + date + " | Time: " + time + " | Reason: " + reason; 34 | } 35 | } 36 | 37 | enum UserRole { 38 | ADMIN, DOCTOR, PATIENT 39 | } 40 | 41 | class User { 42 | String username; 43 | UserRole role; 44 | 45 | public User(String username, UserRole role) { 46 | this.username = username; 47 | this.role = role; 48 | } 49 | } 50 | 51 | public class HospitalAppointmentSystem { 52 | static List appointments = new ArrayList<>(); 53 | static final String FILE_NAME = "appointments.txt"; 54 | static JFrame frame; 55 | static DefaultListModel appointmentListModel; 56 | static User currentUser; 57 | 58 | public static void main(String[] args) { 59 | login(); 60 | loadAppointments(); 61 | SwingUtilities.invokeLater(HospitalAppointmentSystem::createGUI); 62 | } 63 | 64 | public static void login() { 65 | String username = JOptionPane.showInputDialog("Enter Username:"); 66 | String[] roles = {"ADMIN", "DOCTOR", "PATIENT"}; 67 | String roleInput = (String) JOptionPane.showInputDialog(null, "Select Role:", "Login", JOptionPane.QUESTION_MESSAGE, null, roles, roles[0]); 68 | if (roleInput != null) { 69 | currentUser = new User(username, UserRole.valueOf(roleInput)); 70 | } else { 71 | System.exit(0); 72 | } 73 | } 74 | 75 | public static void createGUI() { 76 | frame = new JFrame("Hospital Appointment Scheduling System - " + currentUser.role); 77 | frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); 78 | frame.setSize(600, 400); 79 | 80 | JPanel panel = new JPanel(); 81 | panel.setLayout(new BorderLayout()); 82 | 83 | appointmentListModel = new DefaultListModel<>(); 84 | updateAppointmentList(); 85 | JList appointmentList = new JList<>(appointmentListModel); 86 | panel.add(new JScrollPane(appointmentList), BorderLayout.CENTER); 87 | 88 | JPanel buttonPanel = new JPanel(); 89 | JButton bookButton = new JButton("Book Appointment"); 90 | JButton cancelButton = new JButton("Cancel Appointment"); 91 | JButton searchButton = new JButton("Search Appointment"); 92 | JButton exitButton = new JButton("Exit"); 93 | 94 | if (currentUser.role == UserRole.ADMIN || currentUser.role == UserRole.PATIENT) { 95 | buttonPanel.add(bookButton); 96 | bookButton.addActionListener(e -> bookAppointment()); 97 | } 98 | if (currentUser.role == UserRole.ADMIN) { 99 | buttonPanel.add(cancelButton); 100 | cancelButton.addActionListener(e -> cancelAppointment(appointmentList.getSelectedIndex())); 101 | } 102 | buttonPanel.add(searchButton); 103 | searchButton.addActionListener(e -> searchAppointment()); 104 | buttonPanel.add(exitButton); 105 | exitButton.addActionListener(e -> { 106 | saveAppointments(); 107 | System.exit(0); 108 | }); 109 | 110 | panel.add(buttonPanel, BorderLayout.SOUTH); 111 | frame.add(panel); 112 | frame.setVisible(true); 113 | } 114 | 115 | public static void bookAppointment() { 116 | if (currentUser.role == UserRole.DOCTOR) { 117 | JOptionPane.showMessageDialog(frame, "Doctors cannot book appointments.", "Error", JOptionPane.ERROR_MESSAGE); 118 | return; 119 | } 120 | 121 | String patientName = currentUser.role == UserRole.PATIENT ? currentUser.username : JOptionPane.showInputDialog("Enter Patient Name:"); 122 | String doctorName = JOptionPane.showInputDialog("Enter Doctor Name:"); 123 | String date = JOptionPane.showInputDialog("Enter Date (YYYY-MM-DD):"); 124 | String time = JOptionPane.showInputDialog("Enter Time (HH:MM):"); 125 | String reason = JOptionPane.showInputDialog("Enter Reason for Appointment:"); 126 | 127 | if (isDoctorAvailable(doctorName, date, time)) { 128 | appointments.add(new Appointment(patientName, doctorName, date, time, reason)); 129 | updateAppointmentList(); 130 | sendNotification(patientName, "Your appointment with Dr. " + doctorName + " is confirmed on " + date + " at " + time); 131 | } else { 132 | JOptionPane.showMessageDialog(frame, "Doctor is not available at this time.", "Error", JOptionPane.ERROR_MESSAGE); 133 | } 134 | } 135 | 136 | public static void cancelAppointment(int index) { 137 | if (index >= 0 && index < appointments.size()) { 138 | Appointment removed = appointments.remove(index); 139 | updateAppointmentList(); 140 | sendNotification(removed.patientName, "Your appointment with Dr. " + removed.doctorName + " on " + removed.date + " at " + removed.time + " has been cancelled."); 141 | } else { 142 | JOptionPane.showMessageDialog(frame, "Invalid appointment selection.", "Error", JOptionPane.ERROR_MESSAGE); 143 | } 144 | } 145 | 146 | public static void searchAppointment() { 147 | String searchKey = JOptionPane.showInputDialog("Enter Patient or Doctor Name:"); 148 | if (searchKey == null || searchKey.trim().isEmpty()) return; 149 | 150 | List results = new ArrayList<>(); 151 | for (Appointment app : appointments) { 152 | if ((currentUser.role == UserRole.PATIENT && !app.patientName.equals(currentUser.username)) || 153 | (currentUser.role == UserRole.DOCTOR && !app.doctorName.equals(currentUser.username))) { 154 | continue; 155 | } 156 | if (app.patientName.equalsIgnoreCase(searchKey) || app.doctorName.equalsIgnoreCase(searchKey)) { 157 | results.add(app.toString()); 158 | } 159 | } 160 | 161 | JOptionPane.showMessageDialog(frame, results.isEmpty() ? "No matching appointments found." : String.join("\n", results), "Search Results", JOptionPane.INFORMATION_MESSAGE); 162 | } 163 | 164 | public static void updateAppointmentList() { 165 | appointmentListModel.clear(); 166 | for (Appointment app : appointments) { 167 | if ((currentUser.role == UserRole.PATIENT && !app.patientName.equals(currentUser.username)) || 168 | (currentUser.role == UserRole.DOCTOR && !app.doctorName.equals(currentUser.username))) { 169 | continue; 170 | } 171 | appointmentListModel.addElement(app.toString()); 172 | } 173 | } 174 | 175 | public static void loadAppointments() { 176 | appointments.clear(); 177 | try (BufferedReader reader = new BufferedReader(new FileReader(FILE_NAME))) { 178 | String line; 179 | while ((line = reader.readLine()) != null) { 180 | String[] data = line.split(","); 181 | if (data.length == 5) { 182 | appointments.add(new Appointment(data[0], data[1], data[2], data[3], data[4])); 183 | } 184 | } 185 | } catch (IOException e) { 186 | System.out.println("No existing appointments found."); 187 | } 188 | } 189 | 190 | 191 | public static void saveAppointments() { 192 | try (BufferedWriter writer = new BufferedWriter(new FileWriter(FILE_NAME))) { 193 | for (Appointment app : appointments) { 194 | writer.write(app.patientName + "," + app.doctorName + "," + app.date + "," + app.time + "," + app.reason); 195 | writer.newLine(); 196 | } 197 | } catch (IOException e) { 198 | e.printStackTrace(); 199 | } 200 | } 201 | 202 | 203 | public static boolean isDoctorAvailable(String doctorName, String date, String time) { 204 | for (Appointment app : appointments) { 205 | if (app.doctorName.equalsIgnoreCase(doctorName) && app.date.equals(date) && app.time.equals(time)) { 206 | return false; // Doctor is already booked at this time 207 | } 208 | } 209 | return true; 210 | } 211 | 212 | 213 | public static void sendNotification(String recipient, String message) { 214 | JOptionPane.showMessageDialog(frame, "Notification to " + recipient + ": " + message, "Notification", JOptionPane.INFORMATION_MESSAGE); 215 | } 216 | 217 | } 218 | -------------------------------------------------------------------------------- /Documentation/Specification.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | ## Project Title: 4 | Hospital Appointment System 5 | 6 | ## Domain: 7 | Healthcare 8 | 9 | The **Hospital Appointment System** is part of the **Healthcare** field, which focuses on providing medical services and managing things like patient visits, doctor appointments, and hospital operations. This system is designed to help patients book appointments with doctors, let admins manage and cancel appointments, and make sure doctors can see their own schedules. It makes the process of managing appointments smoother and more organized, which helps improve the patient experience and hospital efficiency. 10 | 11 | ## Problem Statement: 12 | The goal of this **Hospital Appointment System** is to solve problems that hospitals face with scheduling and managing appointments. In many hospitals, it's easy to have double-booked appointments, missed appointments, or patients struggling to find available doctors. This system helps by allowing patients to book appointments directly with doctors, giving admins the ability to manage and cancel appointments, and allowing doctors to view their own appointments. The system also stores appointment data so that information is saved even after closing the program. By making appointments more organized, the system helps hospitals run more smoothly and makes it easier for patients to access care. 13 | 14 | ## System Overview 15 | The Hospital Appointment System allows patients, doctors, administrators, receptionists, IT support staff, and health insurance providers to manage appointments efficiently. It includes features for booking, canceling, and searching appointments while ensuring that doctors are not double-booked. The system also sends notifications and integrates with health insurance verification to ensure smooth operations. 16 | 17 | ## Functional Requirements 18 | 19 | ### User Management 20 | **Login:** Users must log in with a valid username and select a role from the following options: 21 | 22 | **ADMIN:** Full access to manage appointments. 23 | 24 | **DOCTOR:** Limited access to view appointments and manage availability. 25 | 26 | **PATIENT:** Access to book and view their own appointments. 27 | 28 | **RECEPTIONIST:** Assist patients with appointment booking, rescheduling, and cancellations. 29 | 30 | **IT SUPPORT STAFF:** Maintain the system and ensure it runs smoothly. 31 | 32 | **HEALTH INSURANCE PROVIDERS:** Verify patient eligibility and insurance coverage. 33 | 34 | ### Appointment Management 35 | **Book Appointment:** A patient can book an appointment by providing: 36 | - Patient name (auto-filled for the logged-in patient). 37 | - Doctor’s name. 38 | - Date and time of the appointment. 39 | - Reason for the appointment. 40 | 41 | The system checks if the doctor is available. 42 | 43 | **Cancel Appointment:** Only admins and receptionists can cancel appointments. 44 | 45 | Users can cancel appointments if they are selected from the list. 46 | 47 | **Search Appointment:** Users can search for appointments by either patient or doctor name. The search results will be filtered based on the user's role (patients can only see their appointments, and doctors can only see their appointments). 48 | 49 | ### Appointment Storage 50 | 51 | Appointments are stored in a text file (appointments.txt) in the following format: 52 | 53 | patientName, doctorName, date, time, reason 54 | 55 | ### Notifications 56 | 57 | After each booking or cancellation, a notification is sent to the respective patient, indicating the appointment status (booked or canceled). 58 | 59 | ### UI and Interaction 60 | 61 | The user interface includes: 62 | - A list displaying the appointments for the logged-in user. 63 | - Buttons to book, cancel, search appointments, and exit the system. 64 | 65 | The UI is responsive and updates to reflect the current state of appointments. 66 | 67 | ## System Architecture 68 | ### Classes 69 | 70 | **Appointment:** Represents an appointment with details such as patient name, doctor name, date, time, and reason for the appointment. 71 | 72 | **User:** Represents a user with a username and role (Admin, Doctor, Patient, Receptionist, IT Support Staff, Health Insurance Provider). 73 | 74 | **HospitalAppointmentSystem:** Main class that runs the system, handles user login, appointment management, UI creation, and file I/O operations. 75 | 76 | #### User Roles 77 | 78 | **Admin:** Can book, cancel, and search any appointment. 79 | 80 | **Doctor:** Can only view and search appointments for themselves. 81 | 82 | **Patient:** Can only book and view their own appointments. 83 | 84 | **Receptionist:** Can assist with booking and canceling appointments. 85 | 86 | **IT Support Staff:** Ensures the system functions without downtime and handles technical issues. 87 | 88 | **Health Insurance Providers:** Can verify the eligibility and coverage of patients for their visits. 89 | 90 | ## Non-Functional Requirements 91 | **Performance** 92 | The system should load appointments efficiently, even with a large number of records. 93 | 94 | The appointment booking process should complete in under 3 seconds. 95 | 96 | **Usability** 97 | The system should have an intuitive user interface with minimal steps for booking, searching, and canceling appointments. 98 | 99 | **Reliability** 100 | The system should maintain appointments reliably across sessions using file storage. 101 | 102 | Appointment data should persist even if the application is closed and reopened. 103 | 104 | **Security** 105 | The system should ensure only authorized users (Admin, Doctor, Patient, Receptionist, IT Support Staff, Health Insurance Provider) can perform their respective actions. 106 | 107 | User credentials (username) are not stored; only the role selection is used for access control. 108 | 109 | ### System Constraints 110 | **Storage** 111 | 112 | The system relies on a text file (appointments.txt) for storing appointments. This file should not exceed a size of 100MB. 113 | 114 | **Dependencies** 115 | 116 | The system is built using Java Swing for the user interface, Java IO for file operations, and standard Java libraries for other functionalities. 117 | 118 | ### Data Flow 119 | **Login:** The user provides a username and selects a role. 120 | 121 | **Appointment Management:** 122 | 123 | - **Book Appointment:** Checks doctor availability, adds the appointment, and sends notifications. 124 | - **Cancel Appointment:** Removes the selected appointment and sends notifications. 125 | - **Search Appointment:** Filters and displays appointments based on search criteria (patient or doctor name). 126 | - **Exit:** Saves the appointments to the file before exiting the system. 127 | 128 | ### Stakeholder Analysis 129 | **Patients** 130 | 131 | Role: Users who book appointments with doctors. 132 | 133 | Key Concerns: 134 | - Easy appointment booking and cancellation. 135 | - Access to doctors' availability. 136 | - Timely notifications about upcoming appointments. 137 | 138 | Pain Points: 139 | - Difficulty in finding available doctors. 140 | - No reminder system for scheduled appointments. 141 | - Long waiting times at the hospital due to overbooking. 142 | 143 | Success Metrics: 144 | - 30% reduction in missed appointments. 145 | - Faster booking process (< 3 minutes per appointment). 146 | 147 | **Doctors** 148 | 149 | Role: Provide medical consultation based on scheduled appointments. 150 | 151 | Key Concerns: 152 | - Efficient scheduling to avoid double bookings. 153 | - Access to patient details before appointments. 154 | - Ability to manage availability and appointment times. 155 | 156 | Pain Points: 157 | - No centralized system to track daily appointments. 158 | - Patients missing appointments without prior cancellation. 159 | - Overbooked time slots causing delays. 160 | 161 | Success Metrics: 162 | - 40% fewer scheduling conflicts. 163 | - 25% improvement in doctor-patient consultation time. 164 | 165 | **Hospital Administrators** 166 | 167 | Role: Manage hospital operations and ensure smooth scheduling. 168 | 169 | Key Concerns: 170 | - Effective monitoring of doctor schedules. 171 | - Proper record-keeping of all patient appointments. 172 | - Ensuring the system reduces manual work. 173 | 174 | Pain Points: 175 | - Heavy reliance on paperwork for tracking appointments. 176 | - Difficulty in managing last-minute appointment changes. 177 | - No real-time insights into doctor availability. 178 | 179 | Success Metrics: 180 | - 50% reduction in administrative workload. 181 | - Real-time tracking of appointments for better hospital efficiency. 182 | 183 | **Receptionists** 184 | 185 | Role: Assist patients with booking, rescheduling, and canceling appointments. 186 | 187 | Key Concerns: 188 | - Fast and efficient appointment handling. 189 | - Easy access to doctor schedules. 190 | - Reducing errors in appointment scheduling. 191 | 192 | Pain Points: 193 | - Manual tracking of doctor availability. 194 | - High workload during peak hours. 195 | - No automated confirmation messages for patients. 196 | 197 | Success Metrics: 198 | - 30% decrease in appointment booking errors. 199 | - Faster processing of appointment requests. 200 | 201 | **IT Support Staff** 202 | 203 | Role: Maintain and troubleshoot the appointment scheduling system. 204 | 205 | Key Concerns: 206 | - Ensuring the system runs without downtime. 207 | - Secure handling of patient data. 208 | - Regular updates and maintenance. 209 | 210 | Pain Points: 211 | - Frequent system crashes due to increased user load. 212 | - Lack of an automated backup system. 213 | - Security vulnerabilities in patient data storage. 214 | 215 | Success Metrics: 216 | - 99% system uptime. 217 | - Zero data breaches within a year. 218 | 219 | **Health Insurance Providers** 220 | 221 | Role: Verify patient eligibility and coverage for hospital visits. 222 | 223 | Key Concerns: 224 | - Integration with hospital billing systems. 225 | - Quick verification of patient insurance details. 226 | - Reducing fraudulent claims. 227 | 228 | Pain Points: 229 | - Delayed insurance verification processes. 230 | - Patients unsure of their coverage before appointments. 231 | - Poor communication between hospitals and insurance companies. 232 | 233 | Success Metrics: 234 | - 50% faster insurance verification process. 235 | - Reduced number of rejected claims due to miscommunication. 236 | 237 | ### File Format 238 | Appointments are stored in a comma-separated format: 239 | 240 | patientName,doctorName,date,time,reason 241 | -------------------------------------------------------------------------------- /Documentation/Agile Planning.md: -------------------------------------------------------------------------------- 1 | # USER STORY TABLE 2 | 3 | 4 | | **User Story ID** | **User Story** | **Acceptance Criteria** | **Priority** | 5 | |-------------------|----------------|--------------------------|-------------| 6 | | **US-001** | As a patient, I want to register for an account so I can book and manage appointments. | Registration is confirmed via email, and the patient can log in immediately | **High** | 7 | | **US-002** | As a patient, I want to log in to the system so I can access my appointments. | Patient logs in using username and password, with access to the appointment dashboard | **High** | 8 | | **US-003** | As a patient, I want to book an appointment with a doctor so I can receive medical attention. | Appointment is successfully booked, and patient receives confirmation | **High** | 9 | | **US-004** | As a patient, I want to cancel my appointment so I can free up a slot for someone else. | Appointment cancellation is confirmed and the slot is released | **High** | 10 | | **US-005** | As a doctor, I want to set my availability so patients can book appointments only when I am free. | Doctor’s availability is updated, and unavailable slots are blocked for booking | **High** | 11 | | **US-006** | As a doctor, I want to view my appointment schedule so I can prepare for patient visits. | Doctor’s schedule displays all upcoming appointments in a clear, organized manner | **High** | 12 | | **US-007** | As an admin, I want to manage doctor and patient accounts so I can ensure correct access control. | Admin can add, edit, or delete doctor and patient profiles with role-based permissions | **High** | 13 | | **US-008** | As an admin, I want to view system usage stats so I can monitor activity and performance. | Admin can generate reports on system usage, including appointments, cancellations, and errors | **Medium** | 14 | | **US-009** | As a system, I want to notify patients and doctors about appointment changes so they stay informed. | Notifications (email/SMS) are sent to both patients and doctors for appointment changes | **High** | 15 | | **US-010** | As a system, I want to check for doctor availability before booking an appointment so I avoid double booking. | System checks real-time doctor availability before finalizing a booking | **High** | 16 | | **US-011** | As a system, I want to store appointment data securely so that all sensitive information is protected. | Appointment data is encrypted and stored in compliance with privacy standards | **High** | 17 | | **US-012** | As a system, I want to allow users to reset their passwords so they can regain access if they forget it. | Password reset process via email works correctly, allowing users to set a new password | **Medium** | 18 | 19 | ### Non-Functional User Story 20 | 21 | | **User Story ID** | **User Story** | **Acceptance Criteria** | **Priority** | 22 | |-------------------|----------------|--------------------------|-------------| 23 | | **US-013** | As a system admin, I want to ensure user data is encrypted with AES-256 so that security compliance standards are met. | All user data is encrypted with AES-256 encryption | **High** | 24 | 25 | --- 26 | 27 | # PRODUCT BACKLOG 28 | 29 | | **Story ID** | **User Story** | **Priority (MoSCoW)** | **Effort Estimate** | **Dependencies** | 30 | |--------------|----------------|-----------------------|---------------------|------------------| 31 | | **US-001** | As a patient, I want to register for an account so I can book and manage appointments. | Must-have | 5 | None | 32 | | **US-002** | As a patient, I want to log in to the system so I can access my appointments. | Must-have | 3 | US-001 | 33 | | **US-003** | As a patient, I want to book an appointment with a doctor so I can receive medical attention. | Must-have | 5 | US-002, US-005 | 34 | | **US-004** | As a patient, I want to cancel my appointment so I can free up a slot for someone else. | Must-have | 4 | US-003 | 35 | | **US-005** | As a doctor, I want to set my availability so patients can book appointments only when I am free. | Must-have | 4 | None | 36 | | **US-006** | As a doctor, I want to view my appointment schedule so I can prepare for patient visits. | Should-have | 3 | US-003 | 37 | | **US-007** | As an admin, I want to manage doctor and patient accounts so I can ensure correct access control. | Must-have | 4 | None | 38 | | **US-008** | As an admin, I want to view system usage stats so I can monitor activity and performance. | Should-have | 3 | US-007 | 39 | | **US-009** | As a system, I want to notify patients and doctors about appointment changes so they stay informed. | Must-have | 4 | US-003, US-006 | 40 | | **US-010** | As a system, I want to check for doctor availability before booking an appointment so I avoid double booking. | Must-have | 5 | US-005 | 41 | | **US-011** | As a system, I want to store appointment data securely so that all sensitive information is protected. | Must-have | 5 | None | 42 | | **US-012** | As a system, I want to allow users to reset their passwords so they can regain access if they forget it. | Should-have | 3 | US-002 | 43 | | **US-013** | As a system admin, I want to ensure user data is encrypted with AES-256 so that security compliance standards are met. | Must-have | 4 | None | 44 | 45 | ### Justification for Prioritization: 46 | 47 | **Must-have**: These user stories are essential for the hospital appointment system to work. They affect the main functions of the system, like creating accounts, booking appointments, managing availability, and ensuring data security. Without them, the system wouldn't meet user needs. For example, **US-001** (patient registration) and **US-003** (appointment booking) are necessary for the system to operate properly. 48 | 49 | **Should-have**: These stories improve the system and make it more convenient for users, but they aren’t absolutely required for the first launch. For instance, **US-006** (doctor's appointment schedule view) is helpful but not essential for the system to work in the beginning; a simpler version could be used at first. 50 | 51 | **Could-have**: These stories are additional features that would make the system better but aren't necessary for the first release. They can be added in later updates. 52 | 53 | **Won't-have**: These stories aren't in this backlog because all tasks focus on important features or improvements needed for the first release. 54 | 55 | --- 56 | 57 | # SPRINT PLAN 58 | 59 | **Sprint Goal**: 60 | *"Implement core patient registration, appointment booking, and doctor availability management functionalities."* 61 | 62 | 63 | ## **Sprint Backlog Table**: 64 | 65 | | **Task ID** | **Task Description** | **Assigned To** | **Estimated Hours** | **Status** | 66 | |-------------|----------------------------------------------------------|------------------|---------------------|-------------------| 67 | | **T-001** | Develop user registration endpoint | Dev Team | 8 | Done | 68 | | **T-002** | Design and implement patient registration UI | UI/UX Team | 10 | Done | 69 | | **T-003** | Implement login system for patients | Dev Team | 6 | In Progress | 70 | | **T-004** | Develop appointment booking functionality | Dev Team | 12 | To Do | 71 | | **T-005** | Create doctor availability management feature | Dev Team | 10 | To Do | 72 | | **T-006** | Integrate appointment booking with doctor's schedule | Dev Team | 8 | To Do | 73 | | **T-007** | Write unit tests for appointment booking feature | QA Team | 5 | To Do | 74 | 75 | --- 76 | 77 | This sprint is focused on implementing the core functionality needed for the hospital appointment system. By the end of the sprint, the following will be achieved: 78 | - **Patient Registration**: Patients will be able to create an account and log in. 79 | - **Appointment Booking**: Patients will be able to book appointments based on available slots. 80 | - **Doctor Availability**: Doctors will be able to set their availability for appointments, ensuring no double bookings. 81 | 82 | These features are critical for the MVP, allowing the system to perform its primary function of managing appointments and ensuring accessibility for both patients and doctors. 83 | 84 | --- 85 | 86 | # REFLECTION 87 | 88 | Being the only stakeholder in this project has made the whole process of prioritizing tasks, estimating time, and aligning Agile with my needs pretty tough. It’s been hard to decide what features are most important, what tasks to focus on first, and how to make sure the work stays on track. 89 | 90 | **1. Prioritization Challenges:** 91 | One of the hardest parts was deciding which tasks should come first. It was easy to pick the must-have tasks, like patient registration and booking appointments, because they’re crucial for the system to work. But when it came to other tasks, like adding extra features or improving things that are not urgently needed, it was tricky. Sometimes, I wanted to include lots of cool features, but I had to remind myself that they could be added later. This constant battle between wanting everything now and needing to stick to the basics made it hard to prioritize the tasks properly. 92 | 93 | **2. Estimation Problems:** 94 | Another challenge was figuring out how long each task would take. Even though Agile gives room for change, you still need to plan the work, and this is where I had trouble. Sometimes, I thought a task would be quick, but it took me longer than expected, or the other way around. For example, making the login system secure seemed simple at first, but it ended up being a more complex job. It’s hard to estimate accurately when you’re doing everything on your own, and this made me feel uncertain about how long things would actually take. 95 | 96 | **3. Aligning Agile with My Needs:** 97 | The biggest challenge was that Agile usually works best with more than one person. Normally, with Agile, you get feedback from others regularly, but since I was the only one involved, I had to make all the decisions on my own. This made me question whether I was choosing the right things for the system or if I was just focusing on what I wanted. Without any other opinions to guide me, I sometimes felt unsure if I was working on the right features and if the product would meet future users' needs. 98 | 99 | **Conclusion:** 100 | Overall, these challenges helped me learn a lot about how Agile works and how hard it can be to manage a project on your own. It’s much easier to work with others and get their feedback to help make decisions. Even though it was tough to make these choices alone, the experience taught me valuable lessons about prioritizing, estimating, and sticking to a clear goal. In the future, I would definitely prefer to work with a team and get feedback from more people. 101 | -------------------------------------------------------------------------------- /Documentation/UseCase Specification.md: -------------------------------------------------------------------------------- 1 | # Hospital Appointment System - Use Case Specifications 2 | 3 | ## **1. Book Appointment** 4 | **Actor:** Patient, Receptionist, Admin 5 | **Description:** Allows a patient to schedule an appointment with an available doctor. 6 | ### **Preconditions** 7 | - Patient must be registered in the system. 8 | - Doctor must have available time slots. 9 | 10 | ### **Postconditions** 11 | - Appointment is successfully saved in the system. 12 | - Patient and doctor receive a confirmation notification. 13 | 14 | ### **Basic Flow** 15 | 1. Patient selects a doctor and available time slot. 16 | 2. System checks for availability. 17 | 3. System saves the appointment. 18 | 4. Patient and doctor receive a confirmation message. 19 | 20 | ### **Alternative Flows** 21 | - **Doctor unavailable** → System displays an error and suggests alternative time slots. 22 | - **Patient not registered** → System prompts for registration before proceeding. 23 | 24 | --- 25 | 26 | ## **2. Cancel Appointment** 27 | **Actor:** Patient, Admin 28 | **Description:** Allows a patient or admin to cancel an existing appointment. 29 | 30 | ### **Preconditions** 31 | - The appointment must exist in the system. 32 | 33 | ### **Postconditions** 34 | - The appointment is removed from the schedule. 35 | - A cancellation notification is sent to the doctor and patient. 36 | 37 | ### **Basic Flow** 38 | 1. Patient selects the appointment. 39 | 2. System confirms the cancellation request. 40 | 3. System removes the appointment from the schedule. 41 | 4. System sends a notification to relevant parties. 42 | 43 | ### **Alternative Flows** 44 | - **Appointment does not exist** → System displays an error message. 45 | - **Late cancellation** → System notifies patient of possible penalties. 46 | 47 | --- 48 | 49 | ## **3. Search Appointment** 50 | **Actor:** Patient, Doctor, Receptionist, Admin 51 | **Description:** Enables users to search for appointments by doctor, patient, or date. 52 | 53 | ### **Preconditions** 54 | - User must be logged in. 55 | 56 | ### **Postconditions** 57 | - Search results are displayed based on filters. 58 | 59 | ### **Basic Flow** 60 | 1. User enters search criteria. 61 | 2. System retrieves matching appointments. 62 | 3. Results are displayed. 63 | 64 | ### **Alternative Flows** 65 | - **No matches found** → System displays a "No results found" message. 66 | 67 | --- 68 | 69 | ## **4. Manage Doctor Availability** 70 | **Actor:** Doctor, Admin 71 | **Description:** Doctors can update their availability for scheduling appointments. 72 | 73 | ### **Preconditions** 74 | - The doctor must be logged into the system. 75 | 76 | ### **Postconditions** 77 | - Availability is updated and reflected in the booking system. 78 | 79 | ### **Basic Flow** 80 | 1. Doctor logs in and selects "Manage Availability." 81 | 2. Doctor updates available time slots. 82 | 3. System saves the changes. 83 | 84 | ### **Alternative Flows** 85 | - **System error** → Doctor receives an error message and must retry. 86 | 87 | --- 88 | 89 | ## **5. Receive Notifications** 90 | **Actor:** Patient, Doctor 91 | **Description:** Sends notifications for upcoming appointments and cancellations. 92 | 93 | ### **Preconditions** 94 | - The user has a scheduled appointment. 95 | 96 | ### **Postconditions** 97 | - Notifications are delivered via email/SMS. 98 | 99 | ### **Basic Flow** 100 | 1. System checks appointment schedule. 101 | 2. System sends reminders 24 hours before the appointment. 102 | 3. Users receive and acknowledge notifications. 103 | 104 | ### **Alternative Flows** 105 | - **Notification delivery failure** → System retries or provides an alternative notification method. 106 | 107 | --- 108 | 109 | ## **6. User Authentication** 110 | **Actor:** Patient, Doctor, Admin, Receptionist, IT Support 111 | **Description:** Allows users to log in with role-based access. 112 | 113 | ### **Preconditions** 114 | - User must have valid login credentials. 115 | 116 | ### **Postconditions** 117 | - User is granted access based on their role. 118 | 119 | ### **Basic Flow** 120 | 1. User enters username and password. 121 | 2. System verifies credentials. 122 | 3. System grants access based on the role. 123 | 124 | ### **Alternative Flows** 125 | - **Invalid credentials** → System denies access and prompts for re-entry. 126 | 127 | --- 128 | 129 | ## **7. Verify Insurance** 130 | **Actor:** Health Insurance Provider 131 | **Description:** Verifies a patient’s insurance coverage before an appointment. 132 | 133 | ### **Preconditions** 134 | - Patient’s insurance details must be entered in the system. 135 | 136 | ### **Postconditions** 137 | - Insurance coverage is confirmed, or alternative payment is required. 138 | 139 | ### **Basic Flow** 140 | 1. Patient provides insurance details. 141 | 2. System checks the insurance provider’s database. 142 | 3. System confirms or denies coverage. 143 | 144 | ### **Alternative Flows** 145 | - **Invalid insurance details** → System prompts for correction or alternative payment. 146 | 147 | --- 148 | 149 | ## **8. System Maintenance** 150 | **Actor:** IT Support 151 | **Description:** Ensures system uptime, security, and troubleshooting. 152 | 153 | ### **Preconditions** 154 | - IT staff must have administrative access. 155 | 156 | ### **Postconditions** 157 | - System remains operational without downtime. 158 | 159 | ### **Basic Flow** 160 | 1. IT staff logs into the admin panel. 161 | 2. System diagnostics are run. 162 | 3. Issues are resolved if detected. 163 | 164 | ### **Alternative Flows** 165 | - **System failure** → IT staff escalates issue for further resolution. 166 | 167 | --- 168 | 169 | # Test Case Development 170 | 171 | ## **Functional Test Cases** 172 | | Test Case ID | Requirement ID | Description | Steps | Expected Result | Actual Result | Status (Pass/Fail) | 173 | |-------------|---------------|-------------|-------|-----------------|---------------|----------------| 174 | | TC-001 | FR-002 | Book an appointment | 1. Patient selects doctor & time slot 2. Clicks "Book" 3. System confirms | Appointment is successfully booked | Appointment was successfully booked. | Pass | 175 | | TC-002 | FR-003 | Cancel an appointment | 1. Patient selects an existing appointment 2. Clicks "Cancel" 3. Confirms action | Appointment is removed, notification sent | Appointment was removed, and a cancellation notification was sent. | Pass | 176 | | TC-003 | FR-004 | Search for appointments | 1. Enter doctor/patient name or date 2. Click "Search" | Matching appointments are displayed within 2 seconds | Search results were displayed in less than 2 seconds. | Pass | 177 | | TC-004 | FR-005 | Check doctor availability | 1. Select doctor 2. System displays available slots | Available time slots are shown | Available time slots displayed correctly. | Pass | 178 | | TC-005 | FR-006 | Receive appointment notification | 1. Book appointment 2. Wait for system to send reminder | Patient & doctor receive notifications | Both the patient and doctor received timely notifications. | Pass | 179 | | TC-006 | FR-001 | User authentication | 1. Enter valid username & password 2. Click "Login" | User is logged in & directed to role-specific dashboard | User logged in and directed to the correct dashboard. | Pass | 180 | | TC-007 | FR-007 | Verify patient insurance | 1. Enter insurance details 2. Click "Verify" | Insurance details are validated | Insurance details were validated successfully. | Pass | 181 | | TC-008 | FR-010 | Validate input fields | 1. Enter invalid date format (e.g., 12-31-2025 instead of YYYY-MM-DD) | System displays an error message | Error message displayed for incorrect date format. | Pass | 182 | 183 | --- 184 | 185 | ## **Non-Functional Test Cases** 186 | | Test Case ID | Requirement ID | Test Scenario | Steps | Expected Result | Actual Result | Status (Pass/Fail) | 187 | |-------------|---------------|--------------|-------|-----------------|---------------|----------------| 188 | | TC-NF-001 | NFR-006 | **Performance Test**: System should handle 1000 concurrent users | Simulate 1000 concurrent users booking/searching appointments | Response time ≤ 2 seconds | Response time was under 2 seconds for all users. | Pass | 189 | | TC-NF-002 | NFR-005 | **Security Test**: Prevent unauthorized access | Attempt login with invalid credentials multiple times | System locks account after 5 failed attempts | System locked account after 5 failed login attempts. | Pass | 190 | 191 | --- 192 | 193 | # Reflection 194 | 195 | ### 1. **Unclear Requirements** 196 | One of my biggest challenges is when the requirements are not clear enough. Sometimes, the instructions about what the system should do are vague, which can make it hard to understand how the system should behave. For example, if the requirement says "Users should be able to book appointments easily," it doesn’t explain what "easily" really means. It’s important to clarify things like how users should choose doctors, what happens if a time slot is already taken, and what should happen if an error happens. Without this clarity, translating the requirement into a detailed use case or test case can be difficult and may need to be changed multiple times. 197 | 198 | ### 2. **Different Needs of Different Users** 199 | A hospital appointment system is meant for many different types of users, like patients, doctors, receptionists, admins, and IT support staff. Each type of user has different needs. For example, doctors want to set their available times for appointments, while patients need to book those appointments. When writing use cases, you need to make sure each type of user can do what they need to do without causing problems for other users. Balancing all these different needs can be challenging, especially when making sure everyone can easily use the system. 200 | 201 | ### 3. **Edge Cases and Alternative Scenarios** 202 | Sometimes, unusual or unexpected situations are missed when writing use cases. For example, what should happen if a patient tries to cancel an appointment at the last minute? Or what if a doctor changes their availability while a patient is trying to book an appointment? Thinking about all the possible situations is difficult but important. Use cases need to cover these unusual situations, which are sometimes left out in the early stages of planning. 203 | 204 | ### 4. **Working with Other Systems** 205 | The hospital system may need to work with other external systems, like insurance providers. For example, checking a patient’s insurance coverage means sending information to another system. If that system doesn’t respond or takes too long, the hospital system needs to handle the situation properly. Writing use cases for these situations is difficult because it’s hard to predict how the system will react when something goes wrong with another system. You need to plan for how the system will handle errors or delays. 206 | 207 | ### 5. **User Login and Security** 208 | Since the system deals with sensitive patient information, it’s very important to make sure only the right people can access the system. Different users (patients, doctors, admins) should only be able to access the parts of the system that are relevant to them. Writing tests to make sure this happens can be tricky because you have to check that unauthorized users can’t get in, and that the system knows what to do if someone keeps entering the wrong password. 209 | 210 | ### 6. **Performance and Stress Testing** 211 | The system needs to be able to handle many people using it at the same time, especially during busy times. For example, many people might try to book or search for appointments at once, and the system needs to stay fast and work well. Testing this is difficult because you need to test how the system works under heavy use, and it’s hard to know how it will behave when many users are logged in at once. 212 | 213 | ### 7. **Legal and Privacy Rules** 214 | In healthcare, there are strict laws to protect patient information. Making sure the system follows these rules can make writing use cases and tests more complicated. Features like keeping data secure, encryption, and tracking who has accessed the system need to be carefully planned and tested to make sure the system follows the law. 215 | 216 | In conclusion, turning requirements into use cases and tests for a hospital appointment system is hard because of unclear instructions, different user needs, and the need to handle unexpected situations. It also requires making sure the system works well with other systems, keeps patient data safe, and can handle lots of users at once. Careful planning and testing are necessary to overcome these challenges. 217 | 218 | 219 | 220 | -------------------------------------------------------------------------------- /Assignment 8/Activity Diagram.md: -------------------------------------------------------------------------------- 1 | 2 | # complex workflows 3 | 4 | ### Workflows 5 | - User Registration 6 | 7 | - Patient Books Appointment 8 | 9 | - Doctor Updates Availability 10 | 11 | - Admin Cancels Appointment 12 | 13 | - Appointment Reminder Notification 14 | 15 | - Patient Views Appointment History 16 | 17 | - Insurance Eligibility Verification 18 | 19 | - System Exit with Auto-Save 20 | 21 | # Activity Diagrams 22 | 23 | ### 1. User Authentication & Role Management Workflow 24 | ```mermaid 25 | flowchart TD 26 | %% Swimlanes: User and System 27 | subgraph User 28 | A[Start: Initiate Login] 29 | B[Enter Credentials] 30 | end 31 | subgraph System 32 | C[Validate Credentials] 33 | D{Are credentials valid?} 34 | E[Prompt for Role Selection] 35 | F[Display Dashboard] 36 | G[Show Error Message] 37 | end 38 | A --> B 39 | B --> C 40 | C --> D 41 | D -- Yes --> E 42 | D -- No --> G 43 | E --> F 44 | F --> H[End] 45 | 46 | ``` 47 | 48 | ### Explanation: 49 | 50 | **Key Actions & Decisions:** 51 | 52 | The user starts by entering credentials. 53 | 54 | The system validates the credentials and checks their validity. 55 | 56 | If valid, the system prompts the user to select a role (Patient, Doctor, or Admin) and then displays the appropriate dashboard. 57 | 58 | If not valid, an error message is shown. 59 | 60 | **Stakeholder Concerns Addressed:** 61 | 62 | Patients and Doctors: Ensure secure access to personalized features, meeting usability and security requirements. 63 | 64 | IT Support: Easy identification and handling of invalid login attempts. 65 | 66 | ### 2. Appointment Booking Workflow 67 | ```mermaid 68 | flowchart TD 69 | %% Swimlanes: Patient and System 70 | subgraph Patient 71 | A[Start: Initiate Appointment Booking] 72 | B[Select Doctor & Preferred Time Slot] 73 | end 74 | subgraph System 75 | C[Receive Booking Request] 76 | D[Check Doctor Availability] 77 | E{Is Doctor Available?} 78 | F[Confirm Appointment] 79 | G[Send Confirmation Notification] 80 | H[Display Unavailability/Error Message] 81 | end 82 | A --> B 83 | B --> C 84 | C --> D 85 | D --> E 86 | E -- Yes --> F 87 | E -- No --> H 88 | F --> G 89 | G --> I[End] 90 | ``` 91 | ### Explanation: 92 | 93 | **Key Actions & Decisions:** 94 | 95 | The patient selects a doctor and a time slot. 96 | 97 | The system receives the booking request and checks the doctor’s availability. 98 | 99 | A decision node determines if the doctor is available: 100 | 101 | If yes, the appointment is confirmed and a notification is sent. 102 | 103 | If no, an error or unavailability message is displayed. 104 | 105 | **Stakeholder Concerns Addressed:** 106 | 107 | Patients: Quick and error-free appointment booking (< 3 minutes per appointment). 108 | 109 | Doctors & Administrators: Prevents double bookings and scheduling conflicts. 110 | 111 | ### 3. Appointment Cancellation Workflow 112 | ```mermaid 113 | flowchart TD 114 | %% Swimlanes: Patient and System 115 | subgraph Patient 116 | A[Start: Request Cancellation] 117 | end 118 | subgraph System 119 | B[Receive Cancellation Request] 120 | C[Confirm Cancellation Intent] 121 | D[Update Appointment Status to 'Canceled'] 122 | E[Send Cancellation Notifications to Doctor & Patient] 123 | end 124 | A --> B 125 | B --> C 126 | C -- Yes --> D 127 | C -- No --> F[Abort Cancellation] 128 | D --> E 129 | E --> G[End] 130 | ``` 131 | ### Explanation: 132 | 133 | **Key Actions & Decisions:** 134 | 135 | The patient initiates a cancellation request. 136 | 137 | The system confirms the cancellation intent with the user. 138 | 139 | If confirmed, the appointment status is updated to “Canceled” and notifications are sent to both the doctor and patient. 140 | 141 | **Stakeholder Concerns Addressed:** 142 | 143 | Patients and Doctors: Allows cancellations as per their need (addressing FR-003 and associated pain points). 144 | 145 | Administrators: Ensures up-to-date scheduling records to reduce manual tracking efforts. 146 | 147 | ### 4. Doctor's Confirmation Workflow 148 | ```mermaid 149 | flowchart TD 150 | %% Swimlanes: Doctor and System 151 | subgraph Doctor 152 | A[Start: View Pending Appointments] 153 | B[Select Appointment for Action] 154 | C{Confirm Appointment?} 155 | end 156 | subgraph System 157 | D[Receive Doctor’s Decision] 158 | E[Update Appointment Status 'Confirm/Reject'] 159 | F[Notify Patient of Decision] 160 | end 161 | A --> B 162 | B --> C 163 | C -- Confirm --> D 164 | C -- Reject --> D 165 | D --> E 166 | E --> F 167 | F --> G[End] 168 | ``` 169 | ### Explanation: 170 | 171 | **Key Actions & Decisions:** 172 | 173 | The doctor reviews pending appointments and selects one to act upon. 174 | 175 | A decision is made: confirm or reject the appointment. 176 | 177 | The system updates the appointment’s status accordingly and notifies the patient. 178 | 179 | **Stakeholder Concerns Addressed:** 180 | 181 | Doctors: Streamlined process to manage appointments and prevent overbooking. 182 | 183 | Patients: Receive timely updates on their appointment status, improving satisfaction. 184 | 185 | ### 5. Appointment Search Workflow 186 | ```mermaid 187 | flowchart TD 188 | %% Swimlanes: User and System 189 | subgraph User 190 | A[Start: Initiate Appointment Search] 191 | B[Enter Search Criteria] 192 | end 193 | subgraph System 194 | C[Validate Search Input] 195 | D[Query Appointment Records] 196 | E[Display Search Results] 197 | F[Display 'No Results Found' Message] 198 | end 199 | A --> B 200 | B --> C 201 | C --> D 202 | D -- Results Found --> E 203 | D -- No Results --> F 204 | E --> G[End] 205 | F --> G 206 | ``` 207 | ### Explanation: 208 | 209 | **Key Actions & Decisions:** 210 | 211 | The user starts a search by entering criteria such as patient name, doctor name, or date. 212 | 213 | The system validates the input and queries the appointment records. 214 | 215 | Depending on the query results, either matching appointments are displayed or a "No Results Found" message is shown. 216 | 217 | **Stakeholder Concerns Addressed:** 218 | 219 | Receptionists and Administrators: Quickly retrieve appointment details, supporting efficient scheduling and reducing manual errors. 220 | 221 | Patients: Easy access to personal appointment information. 222 | 223 | ### 6. Notification & Reminder Dispatch Workflow 224 | ```mermaid 225 | flowchart TD 226 | %% Swimlanes: System and Notification Service 227 | subgraph System 228 | A[Start: Trigger Appointment Reminder] 229 | B[Identify Appointments within 24 Hours] 230 | end 231 | subgraph NotificationService 232 | C[Prepare Email Notification] 233 | D[Prepare SMS Notification] 234 | E[Send Email Notification] 235 | F[Send SMS Notification] 236 | end 237 | A --> B 238 | B --> C 239 | B --> D 240 | C --> E 241 | D --> F 242 | E --> G[End] 243 | F --> G 244 | ``` 245 | ### Explanation: 246 | 247 | **Key Actions & Decisions:** 248 | 249 | The system triggers a reminder process for appointments scheduled within the next 24 hours. 250 | 251 | It identifies the relevant appointments and then, in parallel, prepares both email and SMS notifications. 252 | 253 | Both notifications are sent concurrently. 254 | 255 | **Stakeholder Concerns Addressed:** 256 | 257 | Patients and Doctors: Receive timely reminders to reduce no-shows, addressing concerns related to missed appointments. 258 | 259 | Administrators: Automated notifications reduce manual communication efforts. 260 | 261 | ### 7. Admin Appointment Management Workflow 262 | ```mermaid 263 | flowchart TD 264 | %% Swimlanes: Admin and System 265 | subgraph Admin 266 | A[Start: Access Appointment Management Interface] 267 | B[Select an Appointment] 268 | C[Choose Action: Cancel or Reschedule] 269 | end 270 | subgraph System 271 | D[Process Admin Request] 272 | E[Update Appointment Record] 273 | F[Send Notifications to Patient & Doctor] 274 | end 275 | A --> B 276 | B --> C 277 | C --> D 278 | D --> E 279 | E --> F 280 | F --> G[End] 281 | ``` 282 | ### Explanation: 283 | 284 | **Key Actions & Decisions:** 285 | 286 | The admin accesses the management interface, selects a specific appointment, and chooses whether to cancel or reschedule it. 287 | 288 | The system processes this request, updates the appointment record accordingly, and sends notifications to both the patient and doctor. 289 | 290 | **Stakeholder Concerns Addressed:** 291 | 292 | Hospital Administrators: Improve operational efficiency and reduce the workload associated with manual scheduling. 293 | 294 | Receptionists: Support smoother handling of last-minute changes and reduce scheduling conflicts. 295 | 296 | ### 8. System Exit & Auto-Save Workflow 297 | ```mermaid 298 | flowchart TD 299 | %% Single Swimlane: System 300 | subgraph System 301 | A[Start: User Initiates Exit] 302 | B[Trigger Auto-Save Process] 303 | C[Save Appointment Data to File] 304 | D[Confirm Successful Save] 305 | E[Terminate Session] 306 | end 307 | A --> B 308 | B --> C 309 | C --> D 310 | D --> E 311 | E --> F[End] 312 | ``` 313 | ### Explanation: 314 | 315 | **Key Actions & Decisions:** 316 | 317 | When a user chooses to exit the system, an auto-save process is immediately triggered. 318 | 319 | The system saves all current appointment data to a file (e.g., appointments.txt) in a structured format, confirms that the save was successful, and then terminates the session. 320 | 321 | **Stakeholder Concerns Addressed:** 322 | 323 | Patients, Doctors, and Administrators: Ensures that no data is lost during system shutdown, supporting the non-functional requirement for data persistence and reliability. 324 | 325 | IT Support: Minimizes risk of data corruption and maintains system integrity. 326 | 327 | Each diagram maps directly to specific functional requirements and stakeholder pain points mentioned in your System Requirements Document. These workflows help ensure that the system is both user-friendly and robust in handling various scenarios from authentication to data persistence. 328 | 329 | 330 | 331 | --- 332 | 333 | ### ✅ Step-by-Step Plan: 334 | 335 | --- 336 | 337 | #### **1. Traceability Table Format** 338 | Create a simple table in your markdown file or README like this: 339 | 340 | ```markdown 341 | ### 🔗 Traceability Matrix 342 | 343 | | Diagram Name | Functional Requirement(s) | User Story / Sprint Task | 344 | |----------------------------------|--------------------------------|----------------------------------| 345 | | Appointment State Diagram | FR-002, FR-003, FR-006 | US-5: Book appointment, US-7: Cancel appointment | 346 | | User Registration Activity | NFR-1 (Usability), FR-001 | US-1: Register as a new user | 347 | | Doctor Availability State | FR-005 | US-9: Update availability | 348 | | Admin Cancel Activity | FR-003, FR-004 | US-8: Admin cancels appointment | 349 | | Appointment Reminder Activity | FR-006 | US-10: Receive appointment reminders | 350 | | Insurance Verification Activity | FR-008 | US-12: Check insurance | 351 | ``` 352 | 353 | --- 354 | 355 | #### **2. Add to `README.md` on GitHub** 356 | 357 | Here’s a sample block you can include in your README file: 358 | 359 | ```markdown 360 | ## 📊 UML Diagrams for Hospital Appointment Scheduling System 361 | 362 | This repository contains the UML models for our Java-based Hospital Appointment Scheduling System. 363 | 364 | ### 🔗 Diagram Index 365 | 366 | | Type | Name | Link | 367 | |--------------------|----------------------------------|--------------------------------| 368 | | State Diagram | Appointment | [View](./diagrams/appointment_state.md) | 369 | | Activity Diagram | User Registration | [View](./diagrams/user_registration_activity.md) | 370 | | Activity Diagram | Admin Cancels Appointment | [View](./diagrams/admin_cancel_activity.md) | 371 | 372 | ### 🔄 Traceability to Requirements 373 | 374 | See [Traceability Matrix](./docs/traceability_matrix.md) for how diagrams map to functional requirements and user stories from previous assignments. 375 | ``` 376 | 377 | --- 378 | 379 | Would you like me to help **generate a full traceability matrix** based on the state/activity diagrams you've done so far — and draft the README markdown structure for GitHub? 380 | 381 | 382 | 383 | Awesome! Let's do it step by step. Here's a complete **Traceability Matrix** and a **GitHub `README.md` section** that maps your **UML diagrams** to: 384 | 385 | - **Functional Requirements (Assignment 4)** 386 | - **User Stories & Sprint Tasks (Assignment 6)** 387 | 388 | --- 389 | 390 | ## ✅ Traceability Matrix (Markdown Table) 391 | 392 | ```markdown 393 | ### 🔄 Traceability Matrix 394 | 395 | | Diagram Name | Diagram Type | Functional Requirement(s) | User Story / Sprint Task | 396 | |------------------------------------|--------------------|-----------------------------------|----------------------------------------------------| 397 | | Appointment | State Diagram | FR-002, FR-003, FR-006 | US-5: Book Appointment, US-7: Cancel Appointment | 398 | | User Account | State Diagram | FR-001, FR-008 | US-1: Register/Login, US-2: Role-based Access | 399 | | Doctor Availability | State Diagram | FR-005 | US-9: Doctor Updates Availability | 400 | | Notification | State Diagram | FR-006 | US-10: Send Appointment Reminders | 401 | | System Session | State Diagram | FR-009 | US-15: Exit System with Auto-save | 402 | | Booking Request | State Diagram | FR-002, FR-004 | US-5: Book Appointment, US-8: Admin Cancels | 403 | | Patient Profile | State Diagram | NFR-1, FR-001 | US-13: View/Edit Profile | 404 | | Admin Action | State Diagram | FR-004, FR-008 | US-11: Admin Manages Appointments | 405 | | User Registration | Activity Diagram | FR-001, NFR-1 | US-1: Register New User | 406 | | Patient Books Appointment | Activity Diagram | FR-002, FR-005 | US-5: Book Appointment | 407 | | Doctor Updates Availability | Activity Diagram | FR-005 | US-9: Doctor Updates Availability | 408 | | Admin Cancels Appointment | Activity Diagram | FR-003, FR-004 | US-8: Admin Cancels Appointment | 409 | | Appointment Reminder Notification | Activity Diagram | FR-006 | US-10: Notification Sent to Users | 410 | | Patient Views Appointment History | Activity Diagram | FR-007 | US-14: Patient Views Appointment History | 411 | | Insurance Eligibility Verification | Activity Diagram | FR-008 | US-12: Check Insurance Coverage | 412 | | System Exit with Auto-Save | Activity Diagram | FR-009 | US-15: Exit System with Auto-save | 413 | ``` 414 | 415 | --- 416 | 417 | ## 📝 GitHub `README.md` Section 418 | 419 | ```markdown 420 | # 🏥 Hospital Appointment Scheduling System - UML Models 421 | 422 | This repository includes UML diagrams created to support the development and design of the Hospital Appointment Scheduling System, aligning with the functional and non-functional requirements from Assignment 4 and user stories from Assignment 6. 423 | 424 | --- 425 | 426 | ## 📁 UML Diagram Index 427 | 428 | | Type | Diagram Name | File Link | 429 | |------------------|--------------------------------------|------------------------------------------------| 430 | | State Diagram | Appointment | [/diagrams/appointment_state.md](./diagrams/appointment_state.md) | 431 | | State Diagram | User Account | [/diagrams/user_account_state.md](./diagrams/user_account_state.md) | 432 | | State Diagram | Doctor Availability | [/diagrams/doctor_availability_state.md](./diagrams/doctor_availability_state.md) | 433 | | Activity Diagram | User Registration | [/diagrams/user_registration_activity.md](./diagrams/user_registration_activity.md) | 434 | | Activity Diagram | Patient Books Appointment | [/diagrams/book_appointment_activity.md](./diagrams/book_appointment_activity.md) | 435 | | Activity Diagram | Admin Cancels Appointment | [/diagrams/admin_cancel_activity.md](./diagrams/admin_cancel_activity.md) | 436 | 437 | --- 438 | 439 | ## 🔄 Requirements Traceability 440 | 441 | The [Traceability Matrix](./docs/traceability_matrix.md) maps each diagram to relevant system requirements and sprint user stories, ensuring end-to-end alignment between design artifacts and implementation goals. 442 | 443 | ``` 444 | 445 | --- 446 | 447 | ✅ **Next Steps (Optional Help I Can Offer):** 448 | - Help you generate `.md` files with the actual Mermaid diagrams. 449 | - Create a folder structure for your GitHub repo (`/diagrams`, `/docs`, etc.). 450 | - Suggest filenames and commit message structure for pushing to GitHub. 451 | 452 | Want me to help set up those diagram `.md` files next? 453 | 454 | --------------------------------------------------------------------------------