├── API Documentation (OpenAPI └── Swagger).md ├── Storage-Abstraction Mechanism.md ├── Class Implementation.md ├── CD Pipeline Release Artifact.md ├── Reflection.md ├── Non-Functional Requirements.md ├── GitHub Integration.md ├── CI Pipeline.md ├── In-Memory Implementation.md ├── SPECIFICATION.md ├── Branch Protection Setup.md ├── Sprint Plan.md ├── Product Backlog.md ├── ARCHITECTURE.md ├── Template Analysis.md ├── Repository Interface Design.md ├── Intergration.md ├── Documentation &PR workflow.md ├── FunctionalRequirements.md ├── Stakeholder Analysis.md ├── REST API Development.md ├── User Stories.md ├── Class Diagram in Mermaid.md ├── Service Layer Implementation.md ├── Kanban Board Explanation.md ├── Domain Model.md ├── Future-Proofing.md ├── Test Case Development.md ├── Documentation & Clarity.md ├── Use Case Diagram.md ├── Reflection Assignment 9 .md ├── Reflection Assignment 13.md ├── Creational Justification.md ├── Reflection for Assign 8.md ├── Agile Reflection.md ├── Reflectionkanban.md ├── Use Case Specifications.md ├── Agile Planning Document.md ├── Class Implementation details.md ├── Reflection and Challenges.md ├── Object State Modeling.md ├── Activity Workflow Modeling.md └── README.md /API Documentation (OpenAPI/Swagger).md: -------------------------------------------------------------------------------- 1 | ## 3. API Documentation (OpenAPI/Swagger) 2 | 3 | ### FastAPI Auto-Generated Docs 4 | 5 | Visit: 6 | 7 | ``` 8 | http://127.0.0.1:8000/docs 9 | ``` 10 | 11 | ### Documented Endpoints 12 | 13 | * `GET /api/patients` 14 | * `POST /api/patients` 15 | * `GET /api/patients/{id}` 16 | * Additional endpoints under `/api/doctors` and `/api/appointments` 17 | 18 | > Screenshot of Swagger UI included in `/docs/swagger-ui.png` 19 | 20 | --- 21 | 22 | 23 | -------------------------------------------------------------------------------- /Storage-Abstraction Mechanism.md: -------------------------------------------------------------------------------- 1 | 2 | --- 3 | 4 | ## 3. Abstraction Layer (Factory Pattern) 5 | 6 | ### `/factories/repository_factory.py` 7 | 8 | ```python 9 | from repositories.inmemory.patient_repository import InMemoryPatientRepository 10 | 11 | def get_patient_repository(storage_type: str = "MEMORY"): 12 | if storage_type == "MEMORY": 13 | return InMemoryPatientRepository() 14 | elif storage_type == "DATABASE": 15 | raise NotImplementedError("Database backend not implemented yet") 16 | else: 17 | raise ValueError("Invalid storage type") 18 | ``` 19 | 20 | > **Justification**: Chose **Factory Pattern** for simple backend switching and future extensibility. 21 | 22 | 23 | -------------------------------------------------------------------------------- /Class Implementation.md: -------------------------------------------------------------------------------- 1 | ## Assingment 10 2 | ## 🔧 Language Choice & Design Decisions 3 | 4 | ### 💬 Why Python? 5 | Python was chosen for implementing the Smart Health Care Monitoring System because: 6 | - It is concise and easy to read. 7 | - It supports rapid prototyping. 8 | - It has strong community support for testing and object-oriented design. 9 | 10 | ### ⚙️ Design Choices 11 | - **Encapsulation**: Sensitive fields are marked private with double underscores. 12 | - **Composition**: `Patient` aggregates `Device`, `Alert`, and `HealthRecord`. 13 | - **Association**: Doctors monitor multiple patients via indirect references. 14 | - **Responsibility Allocation**: Each class owns only relevant logic (e.g., `Alert.escalate()`, `Device.send_data()`). 15 | -------------------------------------------------------------------------------- /CD Pipeline Release Artifact.md: -------------------------------------------------------------------------------- 1 | 2 | ## 3.CD Pipeline: Release Artifact 3 | 4 | ### Artifact Deployment (to `dist/` folder) 5 | 6 | Extend `ci.yml` with: 7 | 8 | ```yaml 9 | deploy: 10 | if: github.ref == 'refs/heads/main' 11 | needs: test 12 | runs-on: ubuntu-latest 13 | 14 | steps: 15 | - name: Checkout code 16 | uses: actions/checkout@v3 17 | 18 | - name: Build package 19 | run: | 20 | python setup.py sdist bdist_wheel || echo "No setup.py" 21 | 22 | - name: Upload artifact 23 | uses: actions/upload-artifact@v3 24 | with: 25 | name: smart-healthcare-dist 26 | path: dist/ 27 | ``` 28 | 29 | * Runs **only** on main 30 | * Stores distributable wheel/archive 31 | 32 | --- 33 | 34 | 35 | -------------------------------------------------------------------------------- /Reflection.md: -------------------------------------------------------------------------------- 1 | ## 4. Reflection: Challenges Faced 2 | 3 | 1. **Balancing Real-Time Monitoring and System Load** 4 | - Ensuring real-time data processing without overloading servers required careful API rate limiting. 5 | 6 | 2. **Security vs. Accessibility** 7 | - Encrypting patient data while allowing authorized personnel seamless access was challenging. 8 | 9 | 3. **Integration with Existing Hospital Systems** 10 | - Compatibility with legacy systems required developing flexible APIs. 11 | 12 | 4. **Regulatory Compliance** 13 | - Ensuring compliance with healthcare standards (e.g., HIPAA) meant rigorous validation and logging. 14 | 15 | 5. **Stakeholder Needs Conflict** 16 | - Patients wanted access to their vitals, but hospitals were concerned about data privacy. 17 | -------------------------------------------------------------------------------- /Non-Functional Requirements.md: -------------------------------------------------------------------------------- 1 | ## 3. Non-Functional Requirements 2 | 3 | | Category | Requirement | 4 | |----------|------------| 5 | | **Usability** | The system interface shall comply with WCAG 2.1 accessibility standards | 6 | | **Deployability** | The system shall be deployable on Windows and Linux servers | 7 | | **Maintainability** | The documentation shall include API guides for integration | 8 | | **Scalability** | The system shall support up to 10,000 concurrent users | 9 | | **Security** | All patient data shall be encrypted using AES-256 | 10 | | **Performance** | Alerts shall be processed and sent within 2 seconds | 11 | | **Reliability** | The system shall maintain 99.9% uptime | 12 | | **Compliance** | The system shall comply with HIPAA and other healthcare data regulations | 13 | -------------------------------------------------------------------------------- /GitHub Integration.md: -------------------------------------------------------------------------------- 1 | 2 | ## 4.GitHub Integration 3 | 4 | ### Project Updates: 5 | 6 | * Issues closed: 7 | 8 | * `#22`: Implement patient service 9 | * `#23`: Create doctor routes 10 | * `#24`: Write appointment tests 11 | 12 | ### `CHANGELOG.md` Entry 13 | 14 | ```markdown 15 | ## [v1.0.0] - API & Service Release 16 | ### Added 17 | - Patient, Doctor, Appointment services 18 | - REST API routes using FastAPI 19 | - Swagger UI auto-docs 20 | - Basic unit & integration tests 21 | ``` 22 | 23 | > Screenshot of GitHub board saved in `/docs/github-board.png` 24 | 25 | --- 26 | 27 | ## Summary 28 | 29 | * Functional service layer using repositories 30 | * REST API routes for 3 entities 31 | * Swagger UI available 32 | * GitHub Issues, Changelog, and documentation tracked 33 | 34 | Let me know if you'd like help exporting this to code, PDF, or preparing your project folder for upload to GitHub! 35 | -------------------------------------------------------------------------------- /CI Pipeline.md: -------------------------------------------------------------------------------- 1 | 2 | ## 2. CI Pipeline: Test Automation 3 | 4 | ### File: `.github/workflows/ci.yml` 5 | 6 | ```yaml 7 | name: CI Pipeline 8 | 9 | on: 10 | push: 11 | branches: ["*"] 12 | pull_request: 13 | branches: [main] 14 | 15 | jobs: 16 | test: 17 | runs-on: ubuntu-latest 18 | 19 | steps: 20 | - name: Checkout code 21 | uses: actions/checkout@v3 22 | 23 | - name: Set up Python 24 | uses: actions/setup-python@v4 25 | with: 26 | python-version: '3.10' 27 | 28 | - name: Install dependencies 29 | run: | 30 | python -m pip install --upgrade pip 31 | pip install -r requirements.txt || echo "no requirements file" 32 | 33 | - name: Run tests 34 | run: | 35 | pytest --maxfail=1 --disable-warnings -q 36 | ``` 37 | 38 | * Triggers on all pushes and pull requests 39 | * Blocks PRs if tests fail 40 | 41 | --- 42 | 43 | -------------------------------------------------------------------------------- /In-Memory Implementation.md: -------------------------------------------------------------------------------- 1 | 2 | --- 3 | 4 | ## 2. In-Memory Implementation 5 | 6 | ### `/repositories/inmemory/patient_repository.py` 7 | 8 | ```python 9 | from typing import Dict, Optional, List 10 | from src.patient import Patient 11 | from repositories.patient_repository import PatientRepository 12 | 13 | class InMemoryPatientRepository(PatientRepository): 14 | def __init__(self): 15 | self._storage: Dict[str, Patient] = {} 16 | 17 | def save(self, entity: Patient) -> None: 18 | self._storage[entity.patient_id] = entity 19 | 20 | def find_by_id(self, id: str) -> Optional[Patient]: 21 | return self._storage.get(id) 22 | 23 | def find_all(self) -> List[Patient]: 24 | return list(self._storage.values()) 25 | 26 | def delete(self, id: str) -> None: 27 | self._storage.pop(id, None) 28 | ``` 29 | 30 | > Includes similar implementations for Doctor, Device, Alert, etc. 31 | 32 | -------------------------------------------------------------------------------- /SPECIFICATION.md: -------------------------------------------------------------------------------- 1 | # SPECIFICATION.md 2 | 3 | ## Project Title: Smart Healthcare Monitoring System 4 | 5 | ### Domain 6 | **Healthcare** – This system is designed for hospitals and healthcare institutions to monitor patients' vital signs in real time, ensuring rapid intervention during critical situations. 7 | 8 | ### Problem Statement 9 | Hospitals require a reliable and real-time monitoring system to track patient health conditions continuously. The lack of automated monitoring increases response time, potentially leading to critical delays in treatment. This project aims to develop a smart monitoring system using IoT and AI for predictive alerts. 10 | 11 | ### Individual Scope 12 | The project will be feasible as it utilizes widely available IoT devices and cloud-based processing. Python-based backend services will manage data flow and AI-driven alert systems. The system will be scalable for integration with existing hospital management systems. 13 | 14 | --- 15 | -------------------------------------------------------------------------------- /Branch Protection Setup.md: -------------------------------------------------------------------------------- 1 | # Assignment 13: Implementing CI/CD with GitHub Actions 2 | 3 | ## Objective 4 | 5 | Establish a CI/CD pipeline for the Smart Health Care Monitoring System using GitHub Actions. This ensures automated testing, artifact creation, and branch protection to prevent errors from reaching the `main` branch. 6 | 7 | --- 8 | 9 | ## 1. Branch Protection Setup 10 | 11 | ### GitHub Steps: 12 | 13 | 1. Navigate to **Settings > Branches > Add Rule** 14 | 2. Apply to `main` branch. 15 | 3. Enable the following: 16 | 17 | * Require pull request reviews before merging (min. 1 approval) 18 | * Require status checks to pass (CI must succeed) 19 | * Block direct pushes to `main` 20 | 21 | ### Why It Matters 22 | 23 | * **Avoids Breaking Production:** Prevents merging untested or unauthorized changes. 24 | * **Enforces Quality:** Requires code reviews and passing CI builds. 25 | * **Industry Practice:** Aligns with secure software delivery standards. 26 | 27 | Documented in: [`PROTECTION.md`](PROTECTION.md) 28 | 29 | --- 30 | 31 | 32 | -------------------------------------------------------------------------------- /Sprint Plan.md: -------------------------------------------------------------------------------- 1 | ## 3. Sprint Planning 2 | 3 | ### **Sprint Goal:** 4 | *“Implement real-time vitals monitoring, alert handling, and secure data storage.”* 5 | 6 | ### **Sprint Backlog** 7 | 8 | | Task ID | Task Description | Assigned To | Estimated Hours | Status | 9 | |---------|-----------------|-------------|----------------|--------| 10 | | T-001 | Develop real-time vitals streaming | Backend Team | 8 | To Do | 11 | | T-002 | Implement alert handling system | Backend Team | 6 | To Do | 12 | | T-003 | Encrypt patient vitals storage | Security Team | 5 | To Do | 13 | | T-004 | Develop role-based access control | DevOps | 6 | To Do | 14 | | T-005 | Design dashboard UI for vitals monitoring | Frontend Team | 7 | To Do | 15 | | T-006 | Develop API endpoint for fetching vitals | Backend Team | 6 | To Do | 16 | 17 | ### **Sprint Justification:** 18 | This sprint focuses on **core functionality** required for **patient monitoring**, ensuring **real-time data availability, security, and user access management**—all critical for the system’s Minimum Viable Product (MVP). 19 | -------------------------------------------------------------------------------- /Product Backlog.md: -------------------------------------------------------------------------------- 1 | 2 | ## 2. Product Backlog Creation(Assignment 6) 3 | 4 | | Story ID | User Story | Priority (MoSCoW) | Effort Estimate | Dependencies | 5 | |----------|-----------|------------------|----------------|--------------| 6 | | US-001 | View real-time patient vitals | Must-have | 5 | IoT data streaming | 7 | | US-002 | Acknowledge and dismiss alerts | Must-have | 3 | US-001 | 8 | | US-003 | Store vitals securely | Must-have | 4 | Database encryption module | 9 | | US-004 | Integrate system with hospital database | Should-have | 5 | US-003 | 10 | | US-005 | Manage user roles | Must-have | 3 | Authentication system | 11 | | US-006 | Request patient updates | Could-have | 2 | US-005 | 12 | | US-007 | Generate compliance reports | Should-have | 4 | Data storage system | 13 | | US-008 | Maintain user activity logs | Must-have | 4 | Authentication & database | 14 | ### **Prioritization Justification:** 15 | - **Must-have** stories align with **critical medical workflows** (e.g., real-time vitals, security, alerts, role management). 16 | - **Should-have** stories improve **efficiency** and **compliance** but are not immediate blockers. 17 | - **Could-have** stories enhance **usability** but are **not essential for MVP**. 18 | 19 | --- 20 | -------------------------------------------------------------------------------- /ARCHITECTURE.md: -------------------------------------------------------------------------------- 1 | # ARCHITECTURE.md 2 | 3 | ## Project Title: Smart Healthcare Monitoring System 4 | 5 | ### Domain 6 | **Healthcare** – A cloud-based real-time monitoring system for patient care. 7 | 8 | ### Problem Statement 9 | There is a growing need for real-time, automated patient monitoring in hospitals to improve response time and patient care. This system integrates IoT sensors, cloud computing, and AI for predictive alerts. 10 | 11 | ### Individual Scope 12 | The project will include the following architectural components: 13 | - **Sensors and IoT Devices:** Collect real-time vital signs 14 | - **Backend Processing:** Python-based data processing 15 | - **Database & Cloud Services:** Store and analyze patient data 16 | - **Web & Mobile Application:** Interface for medical staff 17 | 18 | ### C4 Model Diagrams 19 | ```mermaid 20 | graph TD 21 | subgraph "Patient Monitoring System" 22 | Patient["🧑 Patient"] -->|Vital Signs| IoT_Device["📟 IoT Sensors"] 23 | IoT_Device -->|Transmits Data| Backend["🖥️ Python Backend"] 24 | Backend -->|Stores Data| Database["🗄️ SQLite Database"] 25 | Backend -->|Processes Data| AI_Alerts["🤖 AI Alert System"] 26 | AI_Alerts -->|Notifies| Medical_Staff["👨‍⚕️ Medical Staff"] 27 | Medical_Staff -->|Views Data| Web_App["📱 Web & Mobile App"] 28 | end 29 | ``` 30 | -------------------------------------------------------------------------------- /Template Analysis.md: -------------------------------------------------------------------------------- 1 | # 🔍 GitHub Project Templates Comparison 2 | 3 | | Template Name | Columns & Workflows | Automation Features | Suitability for Agile | 4 | | -------------------- | ---------------------------------------- | ------------------------------------------- | ---------------------------------------- | 5 | | **Basic Kanban** | To Do, In Progress, Done | No automation | Suitable for simple projects | 6 | | **Automated Kanban** | Backlog, In Progress, In Review, Done | Auto-moves issues based on status changes | Ideal for sprint tracking and CI/CD | 7 | | **Team Planning** | Icebox, Ready, In Progress, Review, Done | Advanced issue tracking, multiple assignees | Best for large teams with multiple roles | 8 | 9 | ## ✅ Selected Template: **Automated Kanban** 10 | 11 | ### 🎯 Justification 12 | 13 | - **Sprint-Friendly:** Automatically moves issues based on development progress, making sprint tracking efficient. 14 | - **Workflow Automation:** Reduces manual task tracking by auto-updating issue statuses. 15 | - **Ideal for Agile Development:** Supports backlog management, sprint planning, and continuous integration. 16 | - **Improves Visibility:** Offers a clear view of task progress from backlog to completion. 17 | 18 | --- 19 | -------------------------------------------------------------------------------- /Repository Interface Design.md: -------------------------------------------------------------------------------- 1 | # Assignment 11: Repository Pattern for Smart Health Care Monitoring System 2 | 3 | ## Objective 4 | 5 | This assignment implements a **repository layer** that abstracts persistence logic for domain model objects in the Smart Health Care Monitoring System. The design supports CRUD operations, encourages separation of concerns, and can easily switch to other backends (e.g., file, SQL, NoSQL). 6 | 7 | --- 8 | 9 | ## 1. Repository Interface Design 10 | 11 | ### Generic Interface Definition 12 | 13 | ```python 14 | from typing import TypeVar, Generic, Optional, List 15 | 16 | T = TypeVar("T") 17 | ID = TypeVar("ID") 18 | 19 | class Repository(Generic[T, ID]): 20 | def save(self, entity: T) -> None: 21 | raise NotImplementedError 22 | 23 | def find_by_id(self, id: ID) -> Optional[T]: 24 | raise NotImplementedError 25 | 26 | def find_all(self) -> List[T]: 27 | raise NotImplementedError 28 | 29 | def delete(self, id: ID) -> None: 30 | raise NotImplementedError 31 | ``` 32 | 33 | ### Entity-Specific Interfaces 34 | 35 | ```python 36 | from src.patient import Patient 37 | 38 | class PatientRepository(Repository[Patient, str]): 39 | pass 40 | ``` 41 | 42 | > **Justification**: Used generics to avoid duplication across entity repositories and support polymorphism. 43 | 44 | --- 45 | 46 | 47 | 48 | -------------------------------------------------------------------------------- /Intergration.md: -------------------------------------------------------------------------------- 1 | 2 | --- 3 | 4 | ## Integration with Prior Work 5 | 6 | ### Traceability Matrix 7 | 8 | This table shows how diagrams created in Assignment 8 trace back to earlier functional requirements, user stories, and sprint tasks. 9 | 10 | | Diagram/Model | Functional Requirement ID | Related User Story ID | Sprint Task ID | 11 | |--------------------------------------|---------------------------|------------------------|----------------| 12 | | **State: Patient Monitor** | FR-001 | US-001 | T-001 | 13 | | **State: Alert Notification** | FR-004 | US-005 | T-003 | 14 | | **State: Medical Staff Dashboard** | FR-006 | US-006 | T-005 | 15 | | **State: Appointment** | FR-007 | US-004 | T-007 | 16 | | **Activity: Register Patient** | FR-001, FR-002 | US-001, US-002 | T-002 | 17 | | **Activity: Send Alert Notification**| FR-004, FR-008 | US-005, US-007 | T-004 | 18 | | **Activity: Monitor Vital Signs** | FR-003 | US-003 | T-006 | 19 | | **Activity: Doctor Reviews Alerts** | FR-006 | US-006 | T-008 | 20 | 21 | 22 | -------------------------------------------------------------------------------- /Documentation &PR workflow.md: -------------------------------------------------------------------------------- 1 | 2 | ## 4.Documentation & PR Workflow 3 | 4 | ### README Update Snippet: 5 | 6 | ```markdown 7 | ## How to Run Tests Locally 8 | 1. Clone the repo 9 | 2. Install pytest: `pip install pytest` 10 | 3. Run: `pytest` 11 | 12 | ## ⚙️ How CI/CD Works 13 | - All pushes/PRs run tests via GitHub Actions 14 | - PRs to `main` require passing checks 15 | - On merge to `main`, release artifacts are created under `/dist` 16 | ``` 17 | 18 | --- 19 | 20 | ## Deliverables Summary 21 | 22 | | Component | File/Screenshot | Description | 23 | | -------------- | ---------------------------- | -------------------- | 24 | | Branch Rules | `PROTECTION.md` | Why rules matter | 25 | | CI/CD Logic | `.github/workflows/ci.yml` | YAML workflow setup | 26 | | Artifact Proof | `dist/` folder or screenshot | Wheel/tar.gz release | 27 | | Docs | `README.md` | Test/CI instructions | 28 | 29 | --- 30 | 31 | ## Why This Matters 32 | 33 | * **Quality Control:** Block broken code 34 | * **Automation:** Save time and reduce errors 35 | * **Best Practices:** Adopt real-world deployment standards 36 | 37 | --- 38 | 39 | Let me know if you'd like help generating: 40 | 41 | * `PROTECTION.md` 42 | * `.github/workflows/ci.yml` 43 | * Updated `README.md` with CI/CD details 44 | * Screenshot placeholders for test & artifact validation 45 | -------------------------------------------------------------------------------- /FunctionalRequirements.md: -------------------------------------------------------------------------------- 1 | ## 2. Functional Requirements 2 | 3 | | ID | Requirement | Acceptance Criteria | 4 | |----|------------|--------------------| 5 | | FR1 | The system shall collect patient vitals from IoT devices | Data is received and stored in the database without loss | 6 | | FR2 | The system shall process vitals in real-time | Latency for processing must be <1 second | 7 | | FR3 | The system shall trigger alerts when abnormal vitals are detected | Alerts must be sent within 2 seconds of detection | 8 | | FR4 | The system shall provide a dashboard for medical staff to view patient vitals | Data should be accessible via a web and mobile app | 9 | | FR5 | The system shall allow doctors to acknowledge and dismiss alerts | Status updates should reflect in real-time | 10 | | FR6 | The system shall store patient vitals securely in a database | Data encryption must follow AES-256 standards | 11 | | FR7 | The system shall integrate with existing hospital management systems | API endpoints should be available for data sharing | 12 | | FR8 | The system shall support access control based on user roles | Unauthorized users should not be able to access patient data | 13 | | FR9 | The system shall provide historical data for analysis | Medical staff can access patient history for trends | 14 | | FR10 | The system shall generate automated reports on patient health trends | Reports should be downloadable in PDF/CSV formats | 15 | -------------------------------------------------------------------------------- /Stakeholder Analysis.md: -------------------------------------------------------------------------------- 1 | ## 1. Stakeholder Analysis 2 | 3 | | Stakeholder | Role | Key Concerns | Pain Points | Success Metrics | 4 | |------------|------|--------------|------------|----------------| 5 | | **Patients** | Individuals whose vitals are monitored | Real-time monitoring of health, quick response in emergencies | Lack of automated alerts, delays in medical response | Faster medical response time, improved health tracking | 6 | | **Doctors/Nurses** | Medical staff who respond to alerts and monitor patients | Accurate and real-time patient data | Overload of patient data, difficulty in accessing relevant information | 30% reduction in response time to critical cases | 7 | | **Hospital IT Staff** | Maintain the system and ensure uptime | System reliability, security, and integration with existing hospital systems | System crashes, data breaches, poor maintenance documentation | 99.9% uptime, secure data encryption | 8 | | **Hospital Administrators** | Oversee hospital operations and compliance | Compliance with healthcare regulations, cost-effectiveness | High implementation cost, difficulty in training staff | Cost reduction by 20%, seamless regulatory compliance | 9 | | **Family Members** | Relatives of patients who want updates on their loved ones | Ability to track patient condition remotely | Lack of access to real-time updates | Patient vitals accessible in real-time with proper authorization | 10 | | **Government/Regulatory Bodies** | Ensure patient safety and system compliance | Data security, adherence to medical standards | Non-compliance with regulations | 100% compliance with healthcare data protection laws | 11 | -------------------------------------------------------------------------------- /REST API Development.md: -------------------------------------------------------------------------------- 1 | 2 | ## 2. REST API Development 3 | 4 | ### Structure 5 | 6 | ``` 7 | /api 8 | ├── patient_api.py 9 | ├── doctor_api.py 10 | └── appointment_api.py 11 | ``` 12 | 13 | ### Example: `patient_api.py` 14 | 15 | ```python 16 | from fastapi import APIRouter, HTTPException 17 | from services.patient_service import PatientService 18 | 19 | router = APIRouter() 20 | service = PatientService() 21 | 22 | @router.post("/api/patients") 23 | def create_patient(patient_id: str, name: str, age: int, gender: str, contact_info: str): 24 | try: 25 | return service.create_patient(patient_id, name, age, gender, contact_info) 26 | except ValueError as e: 27 | raise HTTPException(status_code=400, detail=str(e)) 28 | 29 | @router.get("/api/patients/{patient_id}") 30 | def get_patient(patient_id: str): 31 | patient = service.get_patient(patient_id) 32 | if not patient: 33 | raise HTTPException(status_code=404, detail="Patient not found") 34 | return patient 35 | ``` 36 | 37 | > FastAPI auto-generates `/docs` with Swagger UI. 38 | 39 | ### Integration Tests: `/tests/api/test_patient_api.py` 40 | 41 | ```python 42 | from fastapi.testclient import TestClient 43 | from main import app 44 | 45 | client = TestClient(app) 46 | 47 | def test_create_and_fetch_patient(): 48 | response = client.post("/api/patients", params={ 49 | "patient_id": "P002", "name": "Sam", "age": 31, "gender": "M", "contact_info": "sam@mail.com" 50 | }) 51 | assert response.status_code == 200 52 | patient = client.get("/api/patients/P002") 53 | assert patient.status_code == 200 54 | ``` 55 | 56 | --- 57 | 58 | 59 | 60 | -------------------------------------------------------------------------------- /User Stories.md: -------------------------------------------------------------------------------- 1 | # User Stories, Product Backlog & Sprint Planning(Assingment 6) 2 | 3 | ## 1. User Story Creation 4 | 5 | | Story ID | User Story | Acceptance Criteria | Priority | 6 | |----------|-----------|---------------------|----------| 7 | | US-001 | As a doctor, I want to view real-time patient vitals so that I can make quick medical decisions. | Vitals should update every second; display clear alerts for abnormal values. | High | 8 | | US-002 | As a nurse, I want to acknowledge and dismiss alerts so that I can manage patient care efficiently. | Alerts should be marked as "Acknowledged" and removed from active queue. | High | 9 | | US-003 | As a patient, I want my vitals securely stored so that my medical data remains private. | Data should be encrypted using AES-256. | High | 10 | | US-004 | As an IT staff member, I want to integrate the system with hospital databases so that we can maintain data consistency. | API should return patient vitals in JSON format. | Medium | 11 | | US-005 | As a hospital administrator, I want to manage user roles so that only authorized personnel can access patient data. | Access control should be role-based. | High | 12 | | US-006 | As a family member, I want to request patient updates so that I can stay informed about my relative’s condition. | Access should require patient consent. | Medium | 13 | | US-007 | As a regulatory officer, I want to generate compliance reports so that we can meet healthcare regulations. | Reports should be available in PDF format. | Medium | 14 | | US-008 | As a system admin, I want user activity logs so that security incidents can be audited. | Logs should capture timestamps and user actions. | High | 15 | 16 | --- 17 | 18 | -------------------------------------------------------------------------------- /Class Diagram in Mermaid.md: -------------------------------------------------------------------------------- 1 | 2 | ## Class Diagram in Mermaid.js 3 | 4 | ```mermaid 5 | classDiagram 6 | class Patient { 7 | -patientId: String 8 | -name: String 9 | -age: int 10 | -gender: String 11 | -contactInfo: String 12 | +register() 13 | +updateProfile() 14 | } 15 | 16 | class Device { 17 | -deviceId: String 18 | -type: String 19 | -status: String 20 | -batteryLevel: int 21 | +sendData() 22 | +checkStatus() 23 | } 24 | 25 | class Alert { 26 | -alertId: String 27 | -type: String 28 | -timestamp: DateTime 29 | -status: String 30 | +acknowledge() 31 | +escalate() 32 | } 33 | 34 | class Doctor { 35 | -doctorId: String 36 | -name: String 37 | -specialty: String 38 | -contactInfo: String 39 | +reviewData() 40 | +respondToAlert() 41 | } 42 | 43 | class HealthRecord { 44 | -recordId: String 45 | -timestamp: DateTime 46 | -dataType: String 47 | -dataValue: String 48 | +addEntry() 49 | +viewHistory() 50 | } 51 | 52 | class Appointment { 53 | -appointmentId: String 54 | -dateTime: DateTime 55 | -status: String 56 | +schedule() 57 | +cancel() 58 | +complete() 59 | } 60 | 61 | class Admin { 62 | -adminId: String 63 | -name: String 64 | -role: String 65 | +manageUsers() 66 | +viewReports() 67 | } 68 | 69 | Patient "1" -- "0..*" Device : owns 70 | Patient "1" -- "0..*" Alert : receives 71 | Patient "1" -- "1" HealthRecord : maintains 72 | Patient "1" -- "0..*" Appointment : schedules 73 | Doctor "1" -- "0..*" Appointment : attends 74 | Doctor "1" -- "0..*" Patient : monitors 75 | Alert "1" -- "1" Device : generatedBy 76 | Admin "1" -- "0..*" Doctor : assigns 77 | ``` 78 | 79 | 80 | 81 | -------------------------------------------------------------------------------- /Service Layer Implementation.md: -------------------------------------------------------------------------------- 1 | # Assignment 12: Service Layer and REST API for Smart Health Care Monitoring System 2 | 3 | ## 🔍 Objective 4 | 5 | Build a service layer to encapsulate business logic and expose it via a REST API using FastAPI. The solution will cover three core entities: 6 | 7 | * `Patient` 8 | * `Doctor` 9 | * `Appointment` 10 | 11 | This solution builds on: 12 | 13 | * Repository Layer (Assignment 11) 14 | * Domain and Class Models (Assignments 9–10) 15 | 16 | --- 17 | 18 | ## 1.Service Layer Implementation 19 | 20 | ### Structure 21 | 22 | ``` 23 | /services 24 | ├── patient_service.py 25 | ├── doctor_service.py 26 | └── appointment_service.py 27 | ``` 28 | 29 | ### Example: `patient_service.py` 30 | 31 | ```python 32 | from repositories.inmemory.patient_repository import InMemoryPatientRepository 33 | from src.patient import Patient 34 | 35 | class PatientService: 36 | def __init__(self): 37 | self.repo = InMemoryPatientRepository() 38 | 39 | def create_patient(self, patient_id, name, age, gender, contact_info): 40 | if self.repo.find_by_id(patient_id): 41 | raise ValueError("Patient already exists") 42 | patient = Patient(patient_id, name, age, gender, contact_info) 43 | self.repo.save(patient) 44 | return patient 45 | 46 | def get_patient(self, patient_id): 47 | return self.repo.find_by_id(patient_id) 48 | 49 | def delete_patient(self, patient_id): 50 | self.repo.delete(patient_id) 51 | ``` 52 | 53 | > Similar services exist for `DoctorService` and `AppointmentService`. 54 | 55 | ### ✅ Unit Tests: `/tests/services/test_patient_service.py` 56 | 57 | ```python 58 | from services.patient_service import PatientService 59 | 60 | service = PatientService() 61 | patient = service.create_patient("P001", "Jane", 29, "F", "jane@mail.com") 62 | assert service.get_patient("P001") == patient 63 | service.delete_patient("P001") 64 | assert service.get_patient("P001") is None 65 | ``` 66 | 67 | --- 68 | 69 | -------------------------------------------------------------------------------- /Kanban Board Explanation.md: -------------------------------------------------------------------------------- 1 | Kanban Board Explanation 2 | 3 | What is a Kanban Board? 4 | A **Kanban board** is a visual tool used in Agile project management to track work progress and optimize workflow efficiency. It consists of columns representing different stages of a task's lifecycle, helping teams manage workloads effectively. 5 | 6 | --- 7 | 8 | How Our Kanban Board Works 9 | 10 | 1. **Visualizing Workflow** 11 | - The board consists of multiple columns, each representing a **stage in task progress**: 12 | - **Backlog** → Tasks that need prioritization. 13 | - **To Do** → Tasks selected for the sprint. 14 | - **Development** → Tasks actively being worked on. 15 | - **Testing** → Tasks undergoing quality assurance. 16 | - **Blocked** → Tasks that cannot progress due to issues. 17 | - **Done** → Completed and deployed tasks. 18 | - **Automation Rules** help move tasks between columns as they progress. 19 | 20 | 2. Limiting Work-In-Progress (WIP) 21 | - To prevent **bottlenecks**, the board limits the number of tasks in key columns: 22 | - **Development:** Max 3 tasks per developer. 23 | - **Testing:** Only 5 tasks at a time to maintain QA focus. 24 | - **Blocked Column:** Flags dependencies or unresolved issues to prevent overloading developers. 25 | 26 | 3.Supporting Agile Principles 27 | - Continuous Delivery:** The board enables real-time tracking of features, ensuring a steady workflow for releases. 28 | - Adaptability:Tasks can be reprioritized based on stakeholder feedback or emerging issues. 29 | - Collaboration: Developers, testers, and product managers can easily see task progress and dependencies. 30 | - Efficiency: Automation reduces manual tracking, allowing teams to focus on coding and testing. 31 | 32 | --- 33 | Why This Matters 34 | By implementing this **Kanban board**, the **Smart Healthcare Monitoring System** ensures a **clear, structured, and Agile-driven workflow**, allowing for **faster iterations, better task visibility, and higher product quality**. 35 | 36 | --- 37 | 38 | -------------------------------------------------------------------------------- /Domain Model.md: -------------------------------------------------------------------------------- 1 | # Assignment 9: Domain Modeling and Class Diagram Development 2 | 3 | ##Domain Model Documentation 4 | 5 | The following table outlines key domain entities, their attributes, methods, relationships, and applicable business rules for the Smart Health Care Monitoring System. 6 | 7 | | Entity | Attributes | Methods | Relationships | Business Rules | 8 | |----------------|----------------------------------------------------|-----------------------------------------|------------------------------------------|----------------| 9 | | Patient | patientId, name, age, gender, contactInfo | register(), updateProfile() | Assigned to Device, linked to Alerts | A patient can have multiple devices. | 10 | | Device | deviceId, type, status, batteryLevel | sendData(), checkStatus() | Belongs to Patient | Devices must be assigned to patients. | 11 | | Alert | alertId, type, timestamp, status | acknowledge(), escalate() | Linked to Patient and Device | Alerts must be acknowledged within 5 min. | 12 | | Doctor | doctorId, name, specialty, contactInfo | reviewData(), respondToAlert() | Monitors Patients | A doctor monitors multiple patients. | 13 | | HealthRecord | recordId, timestamp, dataType, dataValue | addEntry(), viewHistory() | Belongs to Patient | Each patient has a single health record. | 14 | | Appointment | appointmentId, dateTime, status | schedule(), cancel(), complete() | Between Patient and Doctor | A patient can book multiple appointments. | 15 | | Admin | adminId, name, role | manageUsers(), viewReports() | Manages System | Only admin can assign doctors. | 16 | 17 | --- 18 | 19 | 20 | 21 | 22 | -------------------------------------------------------------------------------- /Future-Proofing.md: -------------------------------------------------------------------------------- 1 | 2 | --- 3 | 4 | ## 4. Future-Proofing 5 | 6 | ### Stub: `/repositories/filesystem/patient_file_repository.py` 7 | 8 | ```python 9 | import json 10 | from src.patient import Patient 11 | 12 | class FileSystemPatientRepository: 13 | def __init__(self, file_path: str): 14 | self.file_path = file_path 15 | 16 | def save(self, entity: Patient) -> None: 17 | raise NotImplementedError 18 | 19 | def find_by_id(self, id: str): 20 | raise NotImplementedError 21 | ``` 22 | 23 | > Stub created to enable future JSON/XML-based storage. 24 | 25 | ### Updated Class Diagram (Conceptual) 26 | 27 | ``` 28 | Repository 29 | | 30 | --> PatientRepository 31 | | 32 | --> InMemoryPatientRepository 33 | --> FileSystemPatientRepository (stub) 34 | ``` 35 | 36 | --- 37 | 38 | ## 5. Unit Tests 39 | 40 | ### `/tests/test_patient_repository.py` 41 | 42 | ```python 43 | from repositories.inmemory.patient_repository import InMemoryPatientRepository 44 | from src.patient import Patient 45 | 46 | repo = InMemoryPatientRepository() 47 | 48 | p1 = Patient("P001", "John Doe", 32, "Male", "john@example.com") 49 | repo.save(p1) 50 | assert repo.find_by_id("P001") == p1 51 | 52 | repo.delete("P001") 53 | assert repo.find_by_id("P001") is None 54 | ``` 55 | 56 | --- 57 | 58 | ## README Update Snippet 59 | 60 | ```markdown 61 | ### Repository Layer 62 | - Abstracted CRUD logic via generic repository interface. 63 | - Used Factory Pattern to switch storage types. 64 | - Added `/repositories` for interfaces and `/inmemory` for in-memory stores. 65 | - Future-proof: `/filesystem` folder contains JSON stub implementations. 66 | ``` 67 | 68 | --- 69 | 70 | ## Summary 71 | 72 | - Used generic base interfaces for reuse 73 | - Implemented working in-memory repositories 74 | - Abstracted storage via Factory Pattern 75 | - Prepared JSON-based storage for future 76 | - Passed unit tests for CRUD operations 77 | 78 | > This makes the system scalable, testable, and decoupled from backend-specific code. 79 | 80 | -------------------------------------------------------------------------------- /Test Case Development.md: -------------------------------------------------------------------------------- 1 | # Test Case Development for Smart Healthcare Monitoring System 2 | 3 | ## Functional Test Cases 4 | 5 | | Test Case ID | Requirement ID | Description | Steps | Expected Result | Actual Result | Status | 6 | |-------------|---------------|-------------|-------|----------------|--------------|--------| 7 | | TC-001 | FR-001 | Collect patient vitals from IoT sensors | 1. Connect IoT device. 2. Start data collection. | System receives vitals and stores them in the database. | TBD | TBD | 8 | | TC-002 | FR-002 | Process vitals in real-time | 1. Send vitals from IoT device. 2. System processes data. | Processing time <1 second. | TBD | TBD | 9 | | TC-003 | FR-003 | Trigger alert for abnormal vitals | 1. Enter abnormal vitals. 2. System analyzes data. | Alert is generated within 2 seconds. | TBD | TBD | 10 | | TC-004 | FR-004 | View patient dashboard | 1. Doctor logs in. 2. Selects patient. | Dashboard displays latest vitals. | TBD | TBD | 11 | | TC-005 | FR-005 | Acknowledge and dismiss alerts | 1. Doctor views alert. 2. Clicks acknowledge. | Alert is marked as resolved. | TBD | TBD | 12 | | TC-006 | FR-006 | Store patient vitals securely | 1. Capture vitals. 2. Store in database. | Data stored with AES-256 encryption. | TBD | TBD | 13 | | TC-007 | FR-007 | Integrate with hospital systems | 1. Request patient data via API. | API responds with correct data format. | TBD | TBD | 14 | | TC-008 | FR-010 | Generate patient health reports | 1. Doctor requests report. 2. System compiles data. | Downloadable PDF/CSV report is generated. | TBD | TBD | 15 | 16 | ## Non-Functional Test Cases 17 | 18 | | Test Case ID | Requirement ID | Description | Test Scenario | Expected Result | Actual Result | Status | 19 | |-------------|---------------|-------------|--------------|----------------|--------------|--------| 20 | | TC-009 | NFR-001 | System Performance | Monitor system response time for 10,000 concurrent users. | System remains stable and responsive. | TBD | TBD | 21 | | TC-010 | NFR-002 | Data Security | Attempt unauthorized access. | System denies access and logs attempt. | TBD | TBD | 22 | 23 | 24 | -------------------------------------------------------------------------------- /Documentation & Clarity.md: -------------------------------------------------------------------------------- 1 | # Smart Healthcare Monitoring System 2 | ## Test and Use Case Document 3 | 4 | ## Introduction 5 | This document consolidates the **use case specifications** and **test case development** for the **Smart Healthcare Monitoring System**, ensuring alignment with stakeholder needs and system requirements. 6 | 7 | --- 8 | 9 | ## Use Case Specifications 10 | 11 | Collect Patient Vitals 12 | Description: The system collects real-time patient vitals from IoT sensors. 13 | Preconditions: 14 | - Patient is connected to the IoT device. 15 | Postconditions: 16 | - Vitals are stored in the database. 17 | 18 | Basic Flow: 19 | 1. IoT device collects heart rate, blood pressure, and oxygen levels. 20 | 2. Data is transmitted to the backend. 21 | 3. Backend stores the data securely. 22 | 23 | Alternative Flows: 24 | - IoT device fails to send data → Retry mechanism is triggered. 25 | ### Monitor Patient Data 26 | Description: Doctors and nurses view patient vitals in real-time. 27 | 28 | Preconditions: 29 | - Patient data is available in the system. 30 | 31 | Postconditions: 32 | - Medical staff can analyze patient vitals. 33 | Basic Flow: 34 | 1. Doctor logs into the system. 35 | 2. Doctor selects a patient. 36 | 3. System displays the latest vitals. 37 | 38 | Alternative Flows: 39 | - No data available → System shows “No vitals recorded.” 40 | 41 | --- 42 | 43 | ## Test Case Development 44 | 45 | | Test Case ID | Requirement ID | Description | Steps | Expected Result | Actual Result | Status | 46 | |-------------|---------------|-------------|-------|----------------|--------------|--------| 47 | | TC-001 | FR-001 | Collect patient vitals from IoT sensors | 1. Connect IoT device. 2. Start data collection. | System receives vitals and stores them in the database. | TBD | TBD | 48 | | TC-002 | FR-002 | Process vitals in real-time | 1. Send vitals from IoT device. 2. System processes data. | Processing time <1 second. | TBD | TBD | 49 | | TC-003 | FR-003 | Trigger alert for abnormal vitals | 1. Enter abnormal vitals. 2. System analyzes data. | Alert is generated within 2 seconds. | TBD | TBD | 50 | | TC-004 | FR-004 | View patient dashboard | 1. Doctor logs in. 2. Selects patient. | Dashboard displays latest vitals. | TBD | TBD | 51 | 52 | 53 | --- 54 | 55 | ## Alignment with Stakeholder Needs 56 | This document ensures: 57 | -Stakeholder concerns** are addressed with clear use cases. 58 | -Functional & non-functional requirements** are validated through structured test cases. 59 | -Consistency** with previously defined requirements and architecture. 60 | 61 | -------------------------------------------------------------------------------- /Use Case Diagram.md: -------------------------------------------------------------------------------- 1 | # Key Actors & Roles 2 | 1. Patient – Provides real-time health data through IoT devices. 3 | 2. Doctor/Nurse – Monitors patient vitals, acknowledges alerts, and makes medical decisions. 4 | 3. IoT Sensors – Collect patient vitals and send data to the backend. 5 | 4. Hospital IT Staff – Ensures system functionality, performs maintenance, and secures data. 6 | 5. Hospital Administrator – Manages staff access and oversees compliance. 7 | 6. Family Members – Requests patient condition updates with authorized access. 8 | 7. Regulatory Bodies – Ensures compliance with healthcare data standards and audits system reports. 9 | 10 | # Relationships & Use Case Descriptions 11 | - Generalization: The Doctor/Nurse and Family Member both interact with View Patient Dashboard, but Family Members have limited access. 12 | - Inclusion: 13 | - Acknowledge Alerts includes View Patient Dashboard since doctors must check data before responding. 14 | - Generate Compliance Reports includes View Patient History to track medical trends. 15 | 16 | # Addressing Stakeholder Concerns 17 | This diagram aligns with Assignment 4 stakeholder needs: 18 | - Patients – Ensures real-time health tracking. 19 | - Doctors/Nurses – Provides quick access to patient vitals and AI alerts. 20 | - Hospital IT Staff – Maintains system uptime and data security. 21 | - Hospital Administrators – Manages user roles and access. 22 | - Family Members – Can access patient information securely. 23 | - Regulators – Can audit system compliance and generate reports. 24 | 25 | ```mermaid 26 | graph TD 27 | subgraph "Smart Healthcare Monitoring System" 28 | Patient["🧑 Patient"] --|Provides Vital Signs|--> IoT_Device["📟 IoT Sensors"] 29 | Doctor["👨‍⚕️ Doctor/Nurse"] --|Monitors Patient Data|--> Dashboard["📊 View Patient Dashboard"] 30 | Doctor --|Acknowledges Alerts|--> Alert_System["🚨 AI Alert System"] 31 | IT_Staff["💻 Hospital IT Staff"] --|Maintains System|--> System_Admin["⚙️ System Configuration"] 32 | Admin["🏥 Hospital Administrator"] --|Manages User Roles|--> System_Admin 33 | Family["👨‍👩‍👧 Family Member"] --|Requests Patient Updates|--> Patient_Info["📄 View Patient History"] 34 | Regulator["🏛️ Government/Regulatory Body"] --|Audits System Compliance|--> Compliance_Report["📜 Generate Compliance Reports"] 35 | 36 | IoT_Device --|Sends Data|--> Backend["🖥️ Python Backend"] 37 | Backend --|Stores & Processes|--> Database["🗄️ Secure Database"] 38 | Alert_System --|Triggers Notifications|--> Doctor 39 | System_Admin --|Manages Access|--> Dashboard 40 | end 41 | 42 | -------------------------------------------------------------------------------- /Reflection Assignment 9 .md: -------------------------------------------------------------------------------- 1 | 2 | ## Reflection Assignment 9 3 | 4 | Designing the domain model and class diagram for the Smart Health Care Monitoring System was both a rewarding and challenging experience. One of the primary challenges I encountered was deciding the level of abstraction to apply. It was tempting to model everything in detail, but I had to strike a balance between precision and readability. For example, splitting out roles like `Nurse` or `Technician` was an option, but I opted to keep only `Doctor` and `Admin` to reduce complexity. 5 | 6 | Relationships between classes were another tricky area. Initially, I debated whether `HealthRecord` should be a composition within `Patient` or a separate class. By keeping it separate, I maintained flexibility for future updates, such as integration with hospital databases or other systems. 7 | 8 | Defining methods was also complex. Deciding what actions belong to each class required me to revisit my use cases (Assignment 5) and user stories (Assignment 6). For instance, `schedule()` and `cancel()` clearly fit within the `Appointment` class, but where should actions like `sendData()` belong? I assigned them to `Device` after aligning them with earlier behavioral models (Assignment 8). 9 | 10 | Comparing this approach to other tools like Trello or Jira, GitHub offers a more code-focused environment. Trello is excellent for quick visualization, but lacks the deeper integration with development artifacts. Jira excels in task tracking and reporting but can be overwhelming for smaller projects. GitHub, while simpler, aligns naturally with markdown and Mermaid.js, making it ideal for modeling alongside the repository. 11 | 12 | Another key insight came from comparing the state diagrams (Assignment 8) to the class diagram. State diagrams help visualize the life cycle of a single object, like how an `Alert` moves from `New` to `Acknowledged` or `Escalated`. In contrast, class diagrams reveal structural relationships between all entities. Both are essential: state diagrams show behavior over time, while class diagrams highlight static relationships and data structures. 13 | 14 | I also learned that Agile alignment doesn't mean skipping documentation; rather, it means generating **just enough** design to support development. My domain model directly ties into user stories, and the class diagram supports sprint planning and task decomposition. 15 | 16 | In conclusion, this assignment reinforced core object-oriented principles like encapsulation, abstraction, and clear responsibility allocation. It also improved my ability to model systems both visually and logically. I now appreciate the balance needed between simplicity and completeness, especially when diagrams serve as both design and communication tools. 17 | 18 | 19 | -------------------------------------------------------------------------------- /Reflection Assignment 13.md: -------------------------------------------------------------------------------- 1 | # Reflection – Assignment 13: CI/CD Implementation 2 | 3 | Implementing Continuous Integration and Continuous Deployment (CI/CD) through GitHub Actions for the Smart Health Care Monitoring System presented both learning opportunities and technical challenges. 4 | 5 | ## Initial Setup & Branch Protection 6 | 7 | Setting up branch protection rules was straightforward through GitHub's web interface. Defining constraints such as requiring pull request reviews and blocking direct pushes to `main` helped reinforce industry-level standards. This setup made me more disciplined about using feature branches and following a proper review cycle. It added a layer of accountability and stability to the project. 8 | 9 | ## CI Workflow: Writing and Running Tests 10 | 11 | Creating the GitHub Actions workflow (`ci.yml`) was a bit more challenging. While the YAML syntax was easy to read, getting the test runner (`pytest`) working reliably across the repository structure required troubleshooting. Some tests failed due to missing fixtures and import errors—especially in modules that depended on incomplete service implementations or mock data. 12 | 13 | These failing tests exposed gaps in earlier assumptions about repository structure and test data. It forced me to revisit my unit test files and ensure they were truly independent and isolated, which is crucial for automated testing environments. I also had to learn how to use `--disable-warnings` and `--maxfail` to control output and prevent unnecessary noise in the pipeline. 14 | 15 | ## CD Workflow & Artifact Creation 16 | 17 | Setting up the release artifact step was relatively smoother, although it became evident that I needed a valid `setup.py` or packaging script to generate a proper `dist/` folder. Since my project wasn't yet structured as a Python package, the artifact creation had to be handled with placeholder logic for now. Still, this highlighted what would be needed to package the system for actual distribution later. 18 | 19 | ## Lessons Learned 20 | 21 | * **Automated testing reveals weak points:** Some failing tests were valuable red flags that helped improve the test design. 22 | * **CI/CD is iterative:** You don’t get it perfect in the first attempt—it evolves as the codebase grows. 23 | * **Artifact pipelines require clean structure:** For packaging to work, your project must follow conventions (like having a `setup.py`). 24 | * **Branch protection makes a big difference:** It enforces discipline and prevents accidental code breaks. 25 | 26 | ## Moving Forward 27 | 28 | I now understand that CI/CD is more than a tool—it’s a mindset of continuous validation and improvement. The issues I encountered (such as failed tests and incomplete deployments) are stepping stones that made my process more robust. Future enhancements will include Docker-based testing environments and conditional workflows per environment. 29 | 30 | Despite the hiccups, this assignment added real-world practices to my workflow and boosted the overall reliability of the Smart Health Care Monitoring System. 31 | -------------------------------------------------------------------------------- /Creational Justification.md: -------------------------------------------------------------------------------- 1 | ## Creational Patterns Justification - Smart Health Care Monitoring System 2 | 3 | This project applies six creational design patterns to enhance the flexibility and scalability of the Smart Health Care Monitoring System. Each pattern addresses specific challenges in object creation while keeping the system modular and extensible. 4 | 5 | --- 6 | 7 | ### 1. 🏢 Simple Factory 8 | 9 | **Purpose**: Centralizes object creation without exposing instantiation logic. 10 | 11 | **Use Case**: Create different types of `Device` objects (e.g., HeartRateMonitor, BloodPressureMonitor). 12 | 13 | **Justification**: 14 | - Reduces tight coupling between client code and object creation. 15 | - Simplifies the addition of new device types. 16 | - Provides a single entry point for device creation logic. 17 | 18 | --- 19 | 20 | ### 2. 🧱 Factory Method 21 | 22 | **Purpose**: Allows subclasses to determine which object to instantiate. 23 | 24 | **Use Case**: Create `Notification` objects for different channels like SMS, Email, or In-App based on alert type. 25 | 26 | **Justification**: 27 | - Encourages adherence to Open/Closed Principle. 28 | - Supports pluggable extensions for communication channels. 29 | 30 | --- 31 | 32 | ### 3. 🧪 Abstract Factory 33 | 34 | **Purpose**: Creates families of related objects without specifying concrete classes. 35 | 36 | **Use Case**: Construct families of UI components or alert handlers that work together (e.g., alert generators + responders). 37 | 38 | **Justification**: 39 | - Ensures consistency across related components. 40 | - Facilitates theme or role-specific UI/service generation. 41 | 42 | --- 43 | 44 | ### 4. 🧰 Builder 45 | 46 | **Purpose**: Constructs complex objects step-by-step. 47 | 48 | **Use Case**: Build a `HealthRecord` with optional fields like comments, vitals, and diagnostic reports using `HealthRecordBuilder`. 49 | 50 | **Justification**: 51 | - Improves readability and maintainability of object creation. 52 | - Avoids constructor overload. 53 | - Enables safe object construction with validation steps. 54 | 55 | --- 56 | 57 | ### 5. 🧜️ Prototype 58 | 59 | **Purpose**: Clone existing objects instead of building from scratch. 60 | 61 | **Use Case**: Clone standard `Alert` templates (e.g., for emergency, warning, reminder) and customize fields like `timestamp`, `recipient`, etc. 62 | 63 | **Justification**: 64 | - Enables reuse of predefined templates. 65 | - Reduces time and cost of object creation. 66 | - Useful for alerts with common configurations. 67 | 68 | --- 69 | 70 | ### 6. 🔐 Singleton 71 | 72 | **Purpose**: Ensures one and only one instance of a class exists. 73 | 74 | **Use Case**: Central management of `AlertDispatcher` or `SystemLogger`. 75 | 76 | **Justification**: 77 | - Maintains global access point for logging or alert distribution. 78 | - Prevents inconsistency or duplication. 79 | - Useful for managing shared system-wide services. 80 | 81 | --- 82 | 83 | These design patterns not only streamline object creation but also align with the system's needs for reliability, extensibility, and maintainability in a healthcare context. 84 | -------------------------------------------------------------------------------- /Reflection for Assign 8.md: -------------------------------------------------------------------------------- 1 | Here's the **Reflection** section in markdown format, based on the Assignment 8 instructions: 2 | 3 | --- 4 | 5 | ## Reflection for Assignment 8 6 | 7 | ### Choosing Granularity for States and Actions 8 | 9 | One of the main challenges in developing the state and activity diagrams was finding the right level of granularity. Initially, I struggled with whether to break down actions into micro-level tasks or keep them broad and high-level. Too much detail made the diagrams cluttered and hard to follow, while too little left out essential behaviors and transitions. 10 | 11 | For example, in the *Patient Monitoring* state diagram, I initially included transitions like "sensor initializes," "connection check," and "data integrity check"—which overwhelmed the diagram. Eventually, I grouped those under a single state like “Monitoring Initialized,” which struck a better balance between completeness and readability. 12 | 13 | ### Aligning Diagrams with Agile User Stories 14 | 15 | Mapping diagrams to Agile user stories required thoughtful translation of narrative-based requirements into visual flows. User stories are typically abstract (“As a doctor, I want to view patient vitals…”), while diagrams require specific, actionable states or steps. 16 | 17 | I had to revisit the acceptance criteria and decompose them into smaller transitions or activities. This back-and-forth helped improve consistency and traceability but was time-consuming. Ensuring each transition in the diagrams corresponded to a real action or event in a user story deepened my understanding of how visual modeling supports Agile development. 18 | 19 | ### Comparing State vs. Activity Diagrams 20 | 21 | State diagrams and activity diagrams serve very different but complementary purposes: 22 | 23 | | Aspect | State Diagrams | Activity Diagrams | 24 | |------------------------|--------------------------------------------------|------------------------------------------------| 25 | | Focus | Object behavior over time | Workflow or process logic | 26 | | Perspective | "What can happen to this object?" | "What is the sequence of steps in this task?" | 27 | | Use Case | Tracking states like *Active*, *Disconnected* | Mapping user flows like *Register Patient* | 28 | | Granularity | Better for lifecycle modeling | Better for high-level decision and task flows | 29 | | Agile Linkage | Good for system-level requirements | Great for user stories and sprint planning | 30 | 31 | Using both types gave me a broader perspective: state diagrams clarified system constraints and object behavior, while activity diagrams revealed the human-centric interactions and system workflows. Together, they helped validate functional requirements, refine sprint tasks, and visualize user needs more concretely. 32 | 33 | ### Lesson Learned 34 | 35 | Visual modeling is a powerful way to validate, communicate, and iterate on system design—but only when applied with clear intent. I learned that aligning models with Agile artifacts like user stories, and continuously adjusting for clarity and traceability, is key to successful documentation in software development. 36 | 37 | --- 38 | 39 | Would you like this added to your canvas or README as well? 40 | -------------------------------------------------------------------------------- /Agile Reflection.md: -------------------------------------------------------------------------------- 1 | # Reflection: Challenges in Prioritization, Estimation, and Aligning Agile with Stakeholder Needs(Assignment 6) 2 | 3 | ## Introduction 4 | Developing the **Smart Healthcare Monitoring System** as a solo stakeholder presented unique challenges in **prioritization, estimation, and aligning Agile methodology** with evolving needs. Without external stakeholders, I had to navigate internal resistance, shifting expectations, and self-imposed constraints. This reflection explores these difficulties and the strategies used to address them. 5 | 6 | ## 1. Challenges in Prioritization 7 | 8 | ### **Balancing Core Functionality vs. Additional Features** 9 | One of the biggest struggles was determining which features were **“Must-have”** versus **“Should-have”** or **“Could-have.”** Initially, everything seemed important—real-time vitals, alert systems, security, compliance, role-based access, and integrations. However, implementing all at once was unrealistic. 10 | 11 | **Internal Conflict:** 12 | - Should I prioritize **real-time vitals monitoring** or **role-based access first**? 13 | - Security is critical, but does **compliance reporting** need to be in the first release? 14 | 15 | **Resolution:** 16 | I used **MoSCoW prioritization** and mapped features against immediate **MVP needs.** If a feature didn’t contribute directly to **patient monitoring, alerts, or security**, it was **postponed to later sprints.** This structured approach reduced overwhelm and made development manageable. 17 | 18 | ## 2. Challenges in Estimation 19 | 20 | ### **Overestimating vs. Underestimating Effort** 21 | Estimating development time without external feedback was another major hurdle. Some tasks, like **encrypting patient data**, took longer due to unforeseen complexities, while others, like **building the dashboard UI**, were faster than expected. 22 | 23 | **Internal Conflict:** 24 | - How do I determine effort without a team to validate estimates? 25 | - Am I overestimating security concerns at the expense of UI/UX? 26 | 27 | **Resolution:** 28 | I applied **relative estimation using story points (1-5 scale)** instead of fixed hours. Comparing tasks helped balance complexity—for example, **“real-time vitals streaming” (5 points) vs. “simple patient info retrieval” (2 points).** This method prevented over-committing to unrealistic sprint goals. 29 | 30 | ## 3. Challenges in Aligning Agile with My Own Stakeholder Needs 31 | 32 | ### **Shifting Expectations and Scope Creep** 33 | As the only stakeholder, my **own expectations shifted constantly.** Every time I thought the system was well-defined, new ideas surfaced—like **adding AI-driven predictive alerts.** This created scope creep, making Agile iteration difficult. 34 | 35 | **Internal Conflict:** 36 | - Am I building an MVP or an overly complex system? 37 | - Do I need all features now, or can they evolve through iterations? 38 | 39 | **Resolution:** 40 | I **limited sprints to two-week cycles,** forcing myself to complete core features before adding extras. Additionally, I set a strict **definition of done** for each sprint, ensuring each increment was usable even if future iterations were needed. 41 | 42 | ## Conclusion 43 | Prioritization, estimation, and aligning Agile to self-imposed expectations proved to be a **mental challenge** as much as a technical one. However, by using **MoSCoW prioritization, story point estimation, and controlled sprints**, I was able to **overcome internal resistance** and develop a structured, sustainable workflow. This experience reinforced the importance of **discipline, self-awareness, and structured decision-making in Agile development.** 44 | -------------------------------------------------------------------------------- /Reflectionkanban.md: -------------------------------------------------------------------------------- 1 | # Reflection: Lessons Learned from Kanban Board Implementation 2 | 3 | ##Challenges in Selecting and Customizing the Template 4 | 5 | 1. **Choosing the Right Template:** 6 | - The selection process involved evaluating various GitHub templates, each with distinct strengths and weaknesses. 7 | - The **Basic Kanban** lacked automation, making it less efficient for tracking Agile workflows. 8 | - The **Team Planning** template was overly complex for a single-developer or small-team setup. 9 | - Ultimately, **Automated Kanban** was chosen due to its workflow automation and seamless tracking features. 10 | 11 | 2. **Customization Difficulties:** 12 | - Adjusting the predefined columns to match the project workflow required careful planning. 13 | - Adding a **Testing** column to reflect QA requirements meant modifying default automation rules. 14 | - Balancing Work-In-Progress (WIP) limits across stages to prevent bottlenecks was a crucial challenge. 15 | 16 | 3. **Workflow Adaptation Issues:** 17 | - Aligning the **Smart Healthcare Monitoring System** requirements with GitHub’s predefined automation rules required additional manual configuration. 18 | - Customizing labels and issue tracking to reflect user stories was necessary but time-consuming. 19 | 20 | --- 21 | 22 | ##Comparison: GitHub Kanban vs. Other Tools 23 | 24 | | Feature | GitHub Projects | Trello | Jira | 25 | |---------------|----------------|---------------|---------------| 26 | | **Automation** | Built-in issue automation | Requires Power-Ups | Advanced workflow rules | 27 | | **Integration** | Directly integrates with GitHub Issues | Limited GitHub integration | Best suited for enterprise DevOps | 28 | | **Ease of Use** | Simple, but requires setup | Very user-friendly | Complex but powerful | 29 | | **Customization** | Moderate (columns, labels, automation) | High (custom fields, boards) | Extensive (Scrum, Kanban, custom workflows) | 30 | | **Best For** | Developers working with GitHub | General task management | Large teams & enterprise Agile workflows | 31 | 32 | ### Key Takeaways: 33 | - **GitHub Projects** is ideal for software developers who want **seamless integration with repositories and issue tracking**. 34 | - **Trello** is more intuitive but lacks deep automation features for CI/CD workflows. 35 | - **Jira** is the most powerful but has a steep learning curve and is often overkill for small projects. 36 | 37 | --- 38 | 39 | ##Lessons Learned 40 | 41 | 1. **Template Selection Matters:** 42 | - The right template significantly affects workflow efficiency and task tracking. 43 | - Pre-built automation saves time but may require tweaking to match project needs. 44 | 45 | 2. **Customization is Key:** 46 | - A well-structured **Kanban board** improves team productivity and sprint planning. 47 | - Adding necessary columns (e.g., **Testing**) ensures a better representation of real-world software development cycles. 48 | 49 | 3. **Tool Comparison is Essential:** 50 | - While GitHub Projects is useful for **developer-centric workflows**, Trello and Jira offer alternative strengths. 51 | - Matching the tool to the project’s size and complexity is critical. 52 | 53 | 4. **Work-In-Progress Limits Prevent Bottlenecks:** 54 | - Setting WIP limits ensures tasks flow smoothly, preventing overloading of specific development phases. 55 | - Enforcing **strict review and testing phases** ensures better quality control. 56 | 57 | --- 58 | 59 | ### Final Thoughts 60 | The implementation of an **Automated Kanban Board** in GitHub Projects has enhanced visibility, efficiency, and Agile alignment for the **Smart Healthcare Monitoring System**. While some customization challenges arose, the overall experience reinforced the importance of selecting the right workflow management tool for the project’s needs. 61 | 62 | -------------------------------------------------------------------------------- /Use Case Specifications.md: -------------------------------------------------------------------------------- 1 | # Use Case Specifications for Smart Healthcare Monitoring System 2 | 3 | ## 1. Collect Patient Vitals 4 | **Description:** The system collects real-time patient vitals from IoT sensors. 5 | **Preconditions:** Patient is connected to the IoT device. 6 | **Postconditions:** Vitals are stored in the database. 7 | **Basic Flow:** 8 | 1. IoT device collects heart rate, blood pressure, and oxygen levels. 9 | 2. Data is transmitted to the backend. 10 | 3. Backend stores the data in the secure database. 11 | **Alternative Flows:** 12 | - IoT device fails to send data → Retry mechanism is triggered. 13 | 14 | --- 15 | 16 | ## 2. Monitor Patient Data 17 | **Description:** Doctors and nurses view patient vitals in real-time. 18 | **Preconditions:** Patient data is available in the system. 19 | **Postconditions:** Medical staff can analyze patient vitals. 20 | **Basic Flow:** 21 | 1. Doctor logs into the system. 22 | 2. Doctor selects a patient. 23 | 3. System displays the latest vitals. 24 | **Alternative Flows:** 25 | - No data available → System shows “No vitals recorded.” 26 | 27 | --- 28 | 29 | ## 3. Trigger Alerts for Abnormal Vitals 30 | **Description:** The AI system triggers alerts when vitals are outside safe thresholds. 31 | **Preconditions:** Vitals must be processed and analyzed. 32 | **Postconditions:** Medical staff is notified. 33 | **Basic Flow:** 34 | 1. System analyzes vitals. 35 | 2. AI detects abnormal patterns. 36 | 3. System sends an alert to the doctor. 37 | **Alternative Flows:** 38 | - False positive alert → Doctor dismisses the alert. 39 | 40 | --- 41 | 42 | ## 4. Acknowledge and Dismiss Alerts 43 | **Description:** Doctors acknowledge and dismiss alerts once reviewed. 44 | **Preconditions:** An alert must be generated. 45 | **Postconditions:** Alert is marked as resolved. 46 | **Basic Flow:** 47 | 1. Doctor logs into the system. 48 | 2. Doctor views pending alerts. 49 | 3. Doctor acknowledges the alert. 50 | **Alternative Flows:** 51 | - Doctor does not respond → System escalates the alert. 52 | 53 | --- 54 | 55 | ## 5. View Patient History 56 | **Description:** Medical staff accesses historical patient data. 57 | **Preconditions:** Patient must have previous vitals recorded. 58 | **Postconditions:** Doctor can analyze trends. 59 | **Basic Flow:** 60 | 1. Doctor logs in. 61 | 2. Doctor selects a patient. 62 | 3. System retrieves and displays past vitals. 63 | **Alternative Flows:** 64 | - No history found → System notifies doctor. 65 | 66 | --- 67 | 68 | ## 6. Manage User Access 69 | **Description:** Administrators manage roles and permissions. 70 | **Preconditions:** Admin has login credentials. 71 | **Postconditions:** Users have correct access levels. 72 | **Basic Flow:** 73 | 1. Admin logs in. 74 | 2. Admin selects a user. 75 | 3. Admin assigns or modifies roles. 76 | **Alternative Flows:** 77 | - Unauthorized modification attempt → System denies access. 78 | 79 | --- 80 | 81 | ## 7. Generate Compliance Reports 82 | **Description:** Regulatory bodies generate system compliance reports. 83 | **Preconditions:** System has stored patient data and logs. 84 | **Postconditions:** Reports are available for review. 85 | **Basic Flow:** 86 | 1. Regulator logs in. 87 | 2. Regulator selects “Generate Report.” 88 | 3. System compiles and exports data. 89 | **Alternative Flows:** 90 | - No data available → System notifies regulator. 91 | 92 | --- 93 | 94 | ## 8. Request Patient Updates (Family Members) 95 | **Description:** Family members request patient health updates. 96 | **Preconditions:** The patient must grant access. 97 | **Postconditions:** Family receives authorized updates. 98 | **Basic Flow:** 99 | 1. Family member logs in. 100 | 2. System verifies access rights. 101 | 3. System displays latest patient vitals. 102 | **Alternative Flows:** 103 | - Access denied → System notifies family member. 104 | 105 | --- 106 | -------------------------------------------------------------------------------- /Agile Planning Document.md: -------------------------------------------------------------------------------- 1 | # Agile Planning Document for Smart Healthcare Monitoring System(Assignment 6) 2 | 3 | ## 1. Introduction 4 | This document consolidates all **Agile planning artifacts** for the **Smart Healthcare Monitoring System**, ensuring traceability between **requirements, user stories, backlog prioritization, and sprint planning**. 5 | 6 | --- 7 | 8 | ## 2. Traceability Matrix (User Stories to Requirements) 9 | 10 | | User Story ID | User Story | Requirement ID | Requirement Description | 11 | |--------------|-----------|---------------|--------------------------| 12 | | US-001 | As a doctor, I want to view real-time patient vitals so that I can make quick medical decisions. | FR-001 | The system shall collect patient vitals from IoT devices. | 13 | | US-002 | As a nurse, I want to acknowledge and dismiss alerts so that I can manage patient care efficiently. | FR-003 | The system shall trigger alerts when abnormal vitals are detected. | 14 | | US-003 | As a patient, I want my vitals securely stored so that my medical data remains private. | FR-006 | The system shall store patient vitals securely in a database. | 15 | | US-004 | As an IT staff member, I want to integrate the system with hospital databases so that we can maintain data consistency. | FR-007 | The system shall integrate with existing hospital management systems. | 16 | | US-005 | As a hospital administrator, I want to manage user roles so that only authorized personnel can access patient data. | FR-008 | The system shall support access control based on user roles. | 17 | | US-006 | As a family member, I want to request patient updates so that I can stay informed about my relative’s condition. | FR-009 | The system shall provide historical data for analysis. | 18 | | US-007 | As a regulatory officer, I want to generate compliance reports so that we can meet healthcare regulations. | FR-010 | The system shall generate automated reports on patient health trends. | 19 | | US-008 | As a system admin, I want user activity logs so that security incidents can be audited. | NFR-002 | The system shall log all access attempts for auditing. | 20 | 21 | --- 22 | 23 | ## 3. Product Backlog 24 | 25 | | Story ID | User Story | Priority (MoSCoW) | Effort Estimate | Dependencies | 26 | |----------|-----------|------------------|----------------|--------------| 27 | | US-001 | View real-time patient vitals | Must-have | 5 | IoT data streaming | 28 | | US-002 | Acknowledge and dismiss alerts | Must-have | 3 | US-001 | 29 | | US-003 | Store vitals securely | Must-have | 4 | Database encryption module | 30 | | US-004 | Integrate system with hospital database | Should-have | 5 | US-003 | 31 | | US-005 | Manage user roles | Must-have | 3 | Authentication system | 32 | | US-006 | Request patient updates | Could-have | 2 | US-005 | 33 | | US-007 | Generate compliance reports | Should-have | 4 | Data storage system | 34 | | US-008 | Maintain user activity logs | Must-have | 4 | Authentication & database | 35 | 36 | --- 37 | 38 | ## 4. Sprint Planning 39 | 40 | ### **Sprint Goal:** 41 | *“Implement real-time vitals monitoring, alert handling, and secure data storage.”* 42 | 43 | ### **Sprint Backlog** 44 | 45 | | Task ID | Task Description | Assigned To | Estimated Hours | Status | 46 | |---------|-----------------|-------------|----------------|--------| 47 | | T-001 | Develop real-time vitals streaming | Backend Team | 8 | To Do | 48 | | T-002 | Implement alert handling system | Backend Team | 6 | To Do | 49 | | T-003 | Encrypt patient vitals storage | Security Team | 5 | To Do | 50 | | T-004 | Develop role-based access control | DevOps | 6 | To Do | 51 | | T-005 | Design dashboard UI for vitals monitoring | Frontend Team | 7 | To Do | 52 | | T-006 | Develop API endpoint for fetching vitals | Backend Team | 6 | To Do | 53 | 54 | --- 55 | 56 | ## 5. Conclusion 57 | This document ensures **traceability, clarity, and alignment** with Agile best practices. It links **user stories to system requirements**, prioritizes backlog items, and structures **sprint execution** effectively. 58 | -------------------------------------------------------------------------------- /Class Implementation details.md: -------------------------------------------------------------------------------- 1 | # Programming Language and Key Design Decisions 2 | 3 | ## Programming Language: Python 4 | 5 | The programming language chosen for this assignment is **Python**. This decision was based on several key factors: 6 | 7 | - **Object-Oriented Programming (OOP) Capabilities:** Python fully supports OOP principles, allowing for the creation of classes, objects, inheritance, polymorphism, and encapsulation. This paradigm is well-suited for modeling real-world entities like patients, devices, alerts, and appointments—making the codebase more organized and maintainable. 8 | 9 | - **Readability and Simplicity:** Python's syntax is known for its clarity and conciseness. This makes the code easier to write, understand, and debug, which is particularly beneficial for a project involving multiple classes and their interactions. 10 | 11 | - **Extensive Standard Library:** Python's rich standard library provides a wide range of built-in modules that can simplify various tasks, although for this core class implementation, we primarily focused on fundamental OOP features. 12 | 13 | - **Large and Active Community:** The vast Python community provides ample resources, documentation, and support, making it easier to find solutions to potential issues and learn best practices. 14 | 15 | - **Rapid Development:** Python's high-level nature allows for quicker development cycles, enabling a faster translation of the design into functional code. 16 | 17 | --- 18 | 19 | ## Key Design Decisions in Class Implementation 20 | 21 | The design of the classes within the `src` directory was guided by the following key decisions: 22 | 23 | ### 1. Encapsulation and Information Hiding 24 | 25 | - **Attributes:** Where appropriate, attributes were treated as private or protected (using Python’s convention of a single or double underscore prefix, e.g., `_name`, `__patient_id`). This encapsulates the internal state of objects and protects them from unauthorized modification. 26 | 27 | - **Getters and Setters:** Getter and setter methods (e.g., `get_name()`, `set_name(new_name)`) were used when validation or encapsulated access was required. These were applied selectively, not universally, to reduce code bloat. 28 | 29 | ### 2. Modeling Real-World Entities 30 | 31 | - Each class (`Patient`, `Doctor`, `Device`, `Alert`, `HealthRecord`, `Appointment`, `Admin`) was designed to mirror its real-world counterpart in a healthcare environment. 32 | 33 | - Attributes represent essential properties of these entities, while methods define their behaviors and responsibilities (e.g., `send_data()` for `Device`, `acknowledge()` for `Alert`). 34 | 35 | ### 3. Relationships Between Classes 36 | 37 | - **Associations:** Associations were used where objects reference others (e.g., a `Doctor` monitors multiple `Patients`). 38 | 39 | - **Composition:** `Patient` objects include `HealthRecord`, `Device`, and `Alert` as part of their definition, reflecting ownership and lifecycle dependency. 40 | 41 | - **Aggregation:** `Appointment` aggregates both `Patient` and `Doctor`, showing a shared relationship for a specific timeframe. 42 | 43 | ### 4. Method Design and Behavior 44 | 45 | - Methods were designed around core responsibilities. For example, the `Appointment` class includes methods such as `schedule()`, `cancel()`, and `complete()`. 46 | 47 | - Each method was made as modular and specific as possible, often using parameters to maintain clarity and flexibility. 48 | 49 | ### 5. Modularity and Organization 50 | 51 | - All class implementations were placed in the `/src` directory for clarity and maintainability. 52 | 53 | - Classes are kept in separate files (e.g., `patient.py`, `doctor.py`) to follow Python's single-responsibility principle. 54 | 55 | - This layout allows for clean import paths and supports future scalability (e.g., integration with UI modules, REST APIs). 56 | 57 | --- 58 | 59 | These design decisions ensured the class structure was **logical, modular, testable, and aligned with the object-oriented principles** critical to building an effective and scalable health monitoring system in Python. 60 | -------------------------------------------------------------------------------- /Reflection and Challenges.md: -------------------------------------------------------------------------------- 1 | # Reflection: Challenges in Translating Requirements to Use Cases and Tests 2 | 3 | ## Introduction 4 | Translating system requirements into detailed use cases and test cases for the **Smart Healthcare Monitoring System** presented several challenges. Ensuring alignment between stakeholder needs, functional specifications, and testability required careful planning. This reflection highlights key obstacles encountered and how they were addressed. 5 | 6 | ## 1. Ensuring Completeness and Clarity in Requirements 7 | One of the major challenges was ensuring that all functional and non-functional requirements were accurately reflected in use cases. Stakeholders, such as **doctors, patients, hospital IT staff, and administrators**, have varying concerns. For instance, **doctors prioritize real-time vitals monitoring**, whereas **IT staff focus on system security and uptime**. 8 | 9 | **Challenge:** Some requirements were ambiguous, making it difficult to define precise actions in a use case. For example, “The system should provide real-time vitals” was too broad—should it refresh every second? Every five seconds? How does an alert work in an emergency? 10 | 11 | **Solution:** Requirements were broken down into more detailed statements, specifying refresh rates, alert triggers, and response times. This ensured that use cases like **“Monitor Patient Data”** and **“Trigger Alerts for Abnormal Vitals”** were well-defined. 12 | 13 | ## 2. Handling Edge Cases and Alternative Flows 14 | Another challenge was anticipating edge cases and exceptions. While basic flows are straightforward, real-world usage introduces complications. 15 | 16 | **Example:** In the **“View Patient History”** use case, what happens if a doctor searches for a patient but no vitals are found? Does the system display an error? Allow the doctor to input missing data? 17 | 18 | **Solution:** Each use case was expanded to include **alternative flows**. If no data is available, the system notifies the doctor and suggests checking IoT connectivity or reviewing past records. 19 | 20 | ## 3. Balancing Functional and Non-Functional Testing 21 | Defining **test cases** for functional requirements was relatively straightforward. However, non-functional aspects like **scalability, performance, and security** were more complex. 22 | 23 | **Challenge:** How do we test if the system can handle 10,000 concurrent users? Or whether **AES-256 encryption** is correctly applied to patient data? 24 | 25 | **Solution:** For performance testing, a **load-testing framework** was considered to simulate multiple users. For security, tests focused on **access control validation** by attempting unauthorized logins. 26 | 27 | ## 4. Managing Conflicts Between Stakeholder Needs 28 | Different stakeholders sometimes have **conflicting expectations**. For example: 29 | - **Doctors want fast alerts,** but **IT staff want strict data encryption**—which can slow down processing time. 30 | - **Family members want access to patient data,** but **regulators require strict patient confidentiality.** 31 | 32 | **Solution:** Compromises were made by implementing **role-based access control (RBAC)**, ensuring family members can view **limited** patient information with permission while ensuring compliance with data privacy laws. 33 | 34 | ## 5. Maintaining Traceability from Requirements to Tests 35 | Ensuring that every test case directly mapped to a functional requirement was crucial. If a requirement changed, the corresponding test cases also needed updating. 36 | 37 | **Solution:** A **traceability matrix** was maintained, linking **each test case (e.g., TC-003)** to its corresponding requirement (e.g., FR-003: Trigger Alerts). This ensured consistency across all documentation. 38 | 39 | ## Conclusion 40 | The process of translating system requirements into detailed **use cases and test cases** was both challenging and rewarding. By refining requirements, handling alternative flows, balancing stakeholder needs, and ensuring full traceability, I created a **robust, testable system design** that meets **functional, non-functional, and security** expectations. 41 | -------------------------------------------------------------------------------- /Object State Modeling.md: -------------------------------------------------------------------------------- 1 | # 📦 Object State Modeling - Smart Health Care Monitoring System 2 | 3 | This section outlines 8 critical system objects with their respective UML state transition diagrams using Mermaid, along with an explanation of key states and how each diagram aligns with functional requirements. 4 | 5 | --- 6 | 7 | ## 1. 👤 Patient 8 | ```mermaid 9 | stateDiagram-v2 10 | [*] --> Registered 11 | Registered --> Active : Patient Verified 12 | Active --> Discharged : Treatment Complete 13 | Active --> Inactive : No Activity for 30 Days 14 | Inactive --> Active : Reactivation 15 | Discharged --> [*] 16 | ``` 17 | **Explanation:** 18 | - **Key States:** Registered, Active, Inactive, Discharged 19 | - **Transitions:** Based on verification, inactivity, or treatment completion. 20 | - **Mapping:** Aligns with FR-001: Register and manage patient profiles. 21 | 22 | --- 23 | 24 | ## 2. 📶 SensorDevice 25 | ```mermaid 26 | stateDiagram-v2 27 | [*] --> Initialized 28 | Initialized --> Monitoring : Connection Established 29 | Monitoring --> Faulty : Data Error Detected 30 | Faulty --> Maintenance : Diagnosis Initiated 31 | Maintenance --> Monitoring : Restored 32 | Monitoring --> [*] : Device Shutdown 33 | ``` 34 | **Explanation:** 35 | - **Key States:** Initialized, Monitoring, Faulty, Maintenance 36 | - **Mapping:** Addresses FR-004: Monitor patient vitals in real-time. 37 | 38 | --- 39 | 40 | ## 3. 🧪 SensorData 41 | ```mermaid 42 | stateDiagram-v2 43 | [*] --> Captured 44 | Captured --> Validated : Format Verified 45 | Validated --> Stored : Added to Database 46 | Captured --> Discarded : Invalid Format 47 | ``` 48 | **Explanation:** 49 | - **Key States:** Captured, Validated, Stored, Discarded 50 | - **Mapping:** FR-006: Validate and store patient data securely. 51 | 52 | --- 53 | 54 | ## 4. 🚨 Alert 55 | ```mermaid 56 | stateDiagram-v2 57 | [*] --> Idle 58 | Idle --> Triggered : Abnormal Vitals Detected 59 | Triggered --> Notified : Notify Medical Staff 60 | Notified --> Acknowledged : Staff Response Received 61 | Acknowledged --> Resolved : Patient Stabilized 62 | Resolved --> Idle 63 | ``` 64 | **Explanation:** 65 | - **Key States:** Idle, Triggered, Notified, Acknowledged, Resolved 66 | - **Mapping:** FR-008: Send alerts based on health thresholds. 67 | 68 | --- 69 | 70 | ## 5. 💬 Message 71 | ```mermaid 72 | stateDiagram-v2 73 | [*] --> Composed 74 | Composed --> Sent : Submit 75 | Sent --> Delivered : Recipient Available 76 | Delivered --> Read : Opened by User 77 | Delivered --> Failed : Timeout/Error 78 | ``` 79 | **Explanation:** 80 | - **Key States:** Composed, Sent, Delivered, Read, Failed 81 | - **Mapping:** FR-007: Support messaging between staff and patients. 82 | 83 | --- 84 | 85 | ## 6. 🩺 Appointment 86 | ```mermaid 87 | stateDiagram-v2 88 | [*] --> Requested 89 | Requested --> Confirmed : Approved by Staff 90 | Confirmed --> Completed : Session Held 91 | Requested --> Canceled : User Cancels 92 | Confirmed --> NoShow : Patient Missed 93 | ``` 94 | **Explanation:** 95 | - **Key States:** Requested, Confirmed, Completed, Canceled, NoShow 96 | - **Mapping:** FR-005: Allow users to book and cancel appointments. 97 | 98 | --- 99 | 100 | ## 7. 🧑‍⚕️ Medical Staff Account 101 | ```mermaid 102 | stateDiagram-v2 103 | [*] --> Created 104 | Created --> Verified : Email Confirmed 105 | Verified --> Active : Admin Approval 106 | Active --> Suspended : Policy Violation 107 | Suspended --> Reactivated : Review Passed 108 | ``` 109 | **Explanation:** 110 | - **Key States:** Created, Verified, Active, Suspended, Reactivated 111 | - **Mapping:** FR-002: Manage staff credentials securely. 112 | 113 | --- 114 | 115 | ## 8. 🔒 User Session 116 | ```mermaid 117 | stateDiagram-v2 118 | [*] --> Initiated 119 | Initiated --> Authenticated : Valid Credentials 120 | Authenticated --> Expired : Timeout 121 | Expired --> Terminated : Auto-Logout 122 | Authenticated --> Terminated : Manual Logout 123 | ``` 124 | **Explanation:** 125 | - **Key States:** Initiated, Authenticated, Expired, Terminated 126 | - **Mapping:** FR-009: Maintain secure user session. 127 | 128 | --- 129 | 130 | 131 | -------------------------------------------------------------------------------- /Activity Workflow Modeling.md: -------------------------------------------------------------------------------- 1 | # Activity Workflow Modeling for Smart Health Care Monitoring System 2 | 3 | ## Overview 4 | This section presents **8 UML Activity Diagrams** for complex workflows within the Smart Health Care Monitoring System. Each diagram is followed by a brief explanation covering: 5 | - **Start/End Nodes** 6 | - **Actions & Decisions** 7 | - **Parallel Activities** 8 | - **Swimlanes for Roles/Actors** 9 | - **Stakeholder Relevance** 10 | 11 | --- 12 | 13 | ### 1. Patient Registration 14 | ```mermaid 15 | flowchart TD 16 | Start([Start]) --> U[User enters registration details] 17 | U --> V{Are details valid?} 18 | V -- Yes --> C[Create patient account] 19 | V -- No --> E1[Show error message] 20 | C --> End([End]) 21 | E1 --> End 22 | ``` 23 | **Explanation:** 24 | - Ensures valid patient data entry. 25 | - Stakeholder Need: Enables secure onboarding aligned with FR-001. 26 | 27 | --- 28 | 29 | ### 2. Monitor Vital Signs 30 | ```mermaid 31 | flowchart TD 32 | Start([Start]) --> I[IoT device collects data] 33 | I --> T[Transmit to backend server] 34 | T --> S[Store in database] 35 | S --> A[Analyze for anomalies] 36 | A --> End([End]) 37 | ``` 38 | **Explanation:** 39 | - Continuous data pipeline supports real-time tracking. 40 | - Addresses stakeholder concerns for proactive care (FR-002). 41 | 42 | --- 43 | 44 | ### 3. Alert Medical Staff 45 | ```mermaid 46 | flowchart TD 47 | Start([Start]) --> D[Detect anomaly in data] 48 | D --> V{Is alert threshold reached?} 49 | V -- Yes --> N[Notify medical staff] 50 | V -- No --> End([End]) 51 | N --> End 52 | ``` 53 | **Explanation:** 54 | - Ensures safety via real-time alerts. 55 | - Supports critical response workflows (FR-003). 56 | 57 | --- 58 | 59 | ### 4. Schedule Appointment 60 | ```mermaid 61 | flowchart TD 62 | Start([Start]) --> U[User requests appointment] 63 | U --> A[System checks availability] 64 | A --> D{Is slot available?} 65 | D -- Yes --> C[Confirm appointment] 66 | D -- No --> R[Show alternative slots] 67 | C --> End([End]) 68 | R --> End 69 | ``` 70 | **Explanation:** 71 | - Enhances efficiency in healthcare scheduling. 72 | - Aligns with usability and access priorities. 73 | 74 | --- 75 | 76 | ### 5. Prescription Fulfillment 77 | ```mermaid 78 | flowchart TD 79 | Start([Start]) --> D[Doctor creates prescription] 80 | D --> U[Upload to system] 81 | U --> P[Pharmacy receives request] 82 | P --> C[Check medication availability] 83 | C --> End([End]) 84 | ``` 85 | **Explanation:** 86 | - Streamlines the treatment process. 87 | - Ensures medication workflow integrity (FR-005). 88 | 89 | --- 90 | 91 | ### 6. Emergency Alert Handling 92 | ```mermaid 93 | flowchart TD 94 | Start([Start]) --> T[Trigger from wearable device] 95 | T --> A[Analyze severity level] 96 | A --> D{Is it a critical case?} 97 | D -- Yes --> S[Send SMS/Email to emergency contact & staff] 98 | D -- No --> M[Monitor silently] 99 | S --> End([End]) 100 | M --> End 101 | ``` 102 | **Explanation:** 103 | - Responds to emergencies with parallel actions. 104 | - Critical for life-saving interventions (FR-006). 105 | 106 | --- 107 | 108 | ### 7. Medical Staff Login Workflow 109 | ```mermaid 110 | flowchart TD 111 | Start([Start]) --> E[Enter credentials] 112 | E --> V{Are credentials valid?} 113 | V -- Yes --> D[Dashboard access granted] 114 | V -- No --> M[Show login error] 115 | D --> End([End]) 116 | M --> End 117 | ``` 118 | **Explanation:** 119 | - Secure access to medical data. 120 | - Complies with role-based access controls (NFR-Security). 121 | 122 | --- 123 | 124 | ### 8. System Backup Procedure 125 | ```mermaid 126 | flowchart TD 127 | Start([Start]) --> S[Schedule periodic backups] 128 | S --> C[Copy to secure cloud storage] 129 | C --> V[Verify integrity of backup] 130 | V --> End([End]) 131 | ``` 132 | **Explanation:** 133 | - Protects data integrity. 134 | - Supports stakeholder requirement for system resilience (NFR-Backup). 135 | 136 | --- 137 | 138 | ## Summary 139 | These activity diagrams ensure workflows are clearly mapped, stakeholders’ safety and efficiency concerns are addressed, and Agile principles are upheld through parallelism and decision logic. 140 | 141 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # README.md 2 | 3 | ## Project Title: Smart Healthcare Monitoring System 4 | 5 | ### Description 6 | A real-time patient monitoring system designed for hospitals and healthcare facilities. This system will collect, process, and display vital signs and patient data, alerting medical staff when intervention is needed. It aims to improve patient care efficiency and reduce response time in emergency situations. 7 | 8 | ### Links 9 | ### Links 10 | - [System Specification](SPECIFICATION.md) 11 | - [C4 Architecture](ARCHITECTURE.md) 12 | - [Stakeholder Analysis Table](STAKEHOLDERANALYSIS.md) 13 | - [FunctionalRequirements](FUNCTIONALREQUIREMENTS.md) 14 | - [Non-Functional Requirements](NON_FUNCTIONALREQUIREMENTS.md) 15 | - [Reflection and Challenges](ReflectionandChallenges.md) 16 | 17 | # Smart Healthcare Monitoring System – Kanban Board Customization 18 | 19 | ## Overview 20 | This project uses an **Automated Kanban** board in GitHub Projects to track Agile development tasks for the **Smart Healthcare Monitoring System**. The board has been customized to align with the system’s workflow, quality assurance (QA) requirements, and sprint planning. 21 | 22 | --- 23 | 24 | #Customization Choices 25 | 26 | ###1. **Added ‘Testing’ Column** 27 | **Reason:** Ensures that all completed tasks undergo thorough **Quality Assurance (QA)** before deployment. 28 | **Impact:** 29 | - Enhances system reliability by enforcing testing before marking tasks as "Done". 30 | - QA engineers can verify issues before merging them into the final product. 31 | 32 | ### 2. **Renamed ‘In Progress’ to ‘Development’** 33 | **Reason:** To clearly differentiate active coding tasks from non-coding work. 34 | **Impact:** 35 | - Avoids confusion between ongoing development and non-technical work like documentation. 36 | 37 | ### 3. **Created ‘Blocked’ Column** 38 | **Reason:** Provides visibility into tasks that cannot progress due to dependencies or issues. 39 | **Impact:** 40 | - Helps identify roadblocks early, ensuring smooth sprint execution. 41 | - Encourages quick resolution of blockers to maintain workflow efficiency. 42 | 43 | ### 4. **Automated Issue Movement** 44 | **Reason:** Reduces manual tracking and enhances Agile workflow. 45 | **Impact:** 46 | - Newly created issues automatically move to the **Backlog**. 47 | - Assigned tasks transition to **Development** when a developer starts working. 48 | - Issues move to **Testing** when a pull request is opened. 49 | - Completed tasks shift to **Done** after approval. 50 | 51 | --- 52 | 53 | ## 📋 Kanban Board Structure 54 | 55 | | Column Name | Purpose & Workflow | 56 | | --------------- | ---------------------------------------------------------------- | 57 | | **Backlog** | Contains new issues and user stories awaiting prioritization. | 58 | | **To Do** | Selected tasks for the current sprint. | 59 | | **Development** | Active coding tasks currently in progress. | 60 | | **Testing** | Tasks under QA verification before deployment. | 61 | | **Blocked** | Tasks that cannot proceed due to dependencies or issues. | 62 | | **Done** | Completed and approved tasks. | 63 | 64 | --- 65 | 66 | Benefits of Customization 67 | - **Better QA Integration:** Ensures **thorough testing** before deployment. 68 | - **Increased Transparency:** Highlights blockers and dependencies. 69 | - **Efficient Workflow:** Reduces manual tracking via **automated movement**. 70 | - **Improved Sprint Planning:** Organizes tasks based on priority and development progress. 71 | 72 | --- 73 | 74 | Conclusion 75 | These customizations ensure a structured and **Agile-friendly** workflow, improving task management, quality assurance, and project tracking in the **Smart Healthcare Monitoring System**. 76 | 77 | These are the screenshort of the Issues and Table 78 | ![Screenshot (1)](https://github.com/user-attachments/assets/20f9a7dc-0b41-4e74-b3b3-c12f315cf4ae) 79 | 80 | ![Screenshot (3)](https://github.com/user-attachments/assets/40a1d1ab-3be3-493a-9771-b1ded9259571) 81 | 82 | ### README Links to Diagrams & Explanations 83 | 84 | | Artifact | Link | 85 | |---------------------------------------|------| 86 | | State Diagrams (Assignment 8) | [View State Diagrams](./docs/assignment8_state_diagrams.md) | 87 | | Activity Diagrams (Assignment 8) | [View Activity Diagrams](./docs/assignment8_activity_diagrams.md) | 88 | | Functional Requirements (Assignment 4)| [View Functional Requirements](./docs/assignment4_requirements.md) | 89 | | User Stories (Assignment 6) | [View User Stories](./docs/assignment6_user_stories.md) | 90 | | Sprint Tasks (Assignment 6) | [View Sprint Plan](./docs/assignment6_sprint_plan.md) | 91 | 92 | Assignment 9: Domain Modeling 93 | 94 | Domain Model 95 | 96 | Class Diagram in Mermaid 97 | 98 | Reflection on Domain Modeling 99 | 100 | Assignment 10: Class Implementation & Design Patterns 101 | 102 | Class Implementations in Python (/src) 103 | 104 | Programming Language & Design Decisions 105 | 106 | Creational Patterns Justification.md 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | --------------------------------------------------------------------------------