Views - SENG-350-2024-fall/Team-1 GitHub Wiki

USE THIS

This component diagram provides a high-level graphical representation of MisterED's system architecture, emphasizing its core components and interactions. This diagram is designed to convey an overview of the system's structure and functionality at first glance.

1. Frontend: Contains the patient interface used by users for symptom input and triage updates.
2. Backend: Includes the Flask API, Triage Engine, Patient Queue (Singleton), and CSV Database Manager, managing all core logic and data processing.
3. DataStorage: Acts as the system's persistence layer for queue and patient data.
4. External Systems: The BC Services Card for user authentication is clearly marked as external.
5. Actors: Patients and medical professionals interact with the system at different touchpoints. Information Priority:

The diagram starts with user interactions, flowing logically through the system (frontend → backend → data storage). It highlights the central role of the Flask API in orchestrating system operations and how it connects to other components.

External entities like the BC Services Card are clearly identified as out of scope by marking them as separate actors.

While the external scope is adequately defined in this diagram, a supplemental context diagram could further delineate boundaries for any additional external dependencies or services.

Element	Properties
Frontend Module	Component: Patient Interface Purpose: Provides a user-friendly interface for patients to interact with the MisterED system. Key Features: - Allows patients to log symptoms and receive triage status updates. - Facilitates user authentication via integration with the backend. Relation: Communicates directly with the backend Flask API for sending data and receiving updates.
Backend Module	Component: Flask API Purpose: Acts as the central orchestrator of the system, coordinating interactions between the frontend, backend modules, and external systems. Key Features: - Handles incoming requests from the Patient Interface. - Routes data to relevant backend components like the Triage Engine and Patient Queue. Relation: - Processes symptoms from the frontend and forwards them to the Triage Engine. - Integrates with the BC Services Card system for user authentication. Component: Triage Engine Purpose: Determines the priority level of patients based on submitted symptoms. Key Features: - Applies triage algorithms to assess and categorize patient needs. - Updates the Patient Queue with priority levels. Relation: - Takes input from the Flask API and passes results to the Patient Queue. Component: Patient Queue (Singleton) Purpose: Maintains a single, centralized list of patients awaiting triage or medical assistance. Key Features: - Implements the Singleton design pattern to ensure only one instance is active system-wide. - Manages patient data for real-time updates. Relation: - Receives updates from the Triage Engine and stores them in the database via the CSV Database Manager. Component: CSV Database Manager Purpose: Acts as an intermediary for managing interactions with the data storage layer. Key Features: - Reads and writes patient data to the storage. - Ensures data persistence and retrieval consistency. Relation: - Interfaces with the Patient Queue and DataStorage.
Data Storage	Component: DataStorage Purpose: Provides persistent storage for all system data, including patient records and queue information. Key Features: - Ensures durability and accessibility of critical system data. Relation: - Receives data from the CSV Database Manager.
External Systems	Component: BC Services Card System Purpose: Provides secure authentication services for users accessing the MisterED system. Key Features: - Verifies user identities during login processes. Relation: - Communicates with the Flask API to authenticate users.
Actors	Patient/User: Purpose: Interacts with the Patient Interface to access system services. Relation: Submits symptoms and retrieves triage updates via the frontend. Medical Professional: Purpose: Accesses patient information and provides medical assistance. Relation: Communicates with the Flask API to retrieve patient data and triage statuses.>

Data Storage Adaptability: The current CSV implementation can be replaced with a more scalable solution (e.g., SQL or NoSQL databases) for higher volumes. Frontend Customization: The UI can be extended to include additional features like video consultations. Backend Extensibility: New modules or APIs (e.g., integration with provincial health records and BC Service Card authentication) can be added without disrupting the core system.

• Singleton Design Pattern:

• Ensures a single instance of the Patient Queue is shared across the system.
• Provides centralized access to the patient list, ensuring consistency.

• Observer Design Pattern:

• Enables real-time updates between components, such as notifying users of changes in triage status or new messages from medical professionals.

• Template Design Pattern:

• Defines a structured algorithm template for repeated operations, such as triage processing, while allowing some customization in specific steps.

• Role-Based Conditional Rendering Design Pattern:

• Dynamically adjusts the system’s user interface based on the user’s role (e.g., patient, nurse, or system administrator).
• Simplifies the frontend logic by encapsulating rendering conditions.

• Strategy Design Pattern:

• Facilitates the implementation of interchangeable algorithms, such as different methods of calculating triage priorities.
• Adds flexibility for future enhancements in medical assessment logic.

• Facade Design Pattern:

• Provides a unified interface to the system’s backend, simplifying interactions with complex subsystems like the Patient Queue and Triage Engine.
• Enhances usability for the frontend.

• Heartbeat Availability Tactic:

• Regular health checks between system components to detect failures and ensure uptime.
• For example, monitoring connections between the Flask API and the Patient Queue.

• Ping/Echo Availability Tactic:

• Simple periodic pings between subsystems to verify that components are operational and responsive.
• Used in backend communication to validate the integrity of dependent modules.

• Exception Prevention Availability Tactic:

• Proactive measures to minimize errors before they occur, such as validating user inputs and sanitizing API requests.
• Applied extensively in user authentication and symptom submission processes.

• Timestamp Availability Tactic:

• Incorporates timestamps for requests and responses to ensure accurate sequencing and prevent stale or duplicated data.
• Particularly important in managing patient triage and queue updates.

• Exception Handling Availability Tactic:

• Robust mechanisms to gracefully recover from unexpected errors.
• For instance, if the Triage Engine fails, the system retries the operation or notifies the administrators without affecting overall system performance.

Here is a Context-Level DFD that was used in the creation and implementation of the prototype, which helped determine which design approach was going to be used for each component:

You can find the Related Views section on the main page of the SAD, here.