Milestone 4: View - SENG-350-2024-fall/Team3 GitHub Wiki

Module View Documentation

Contents

  1. Primary Presentation
  2. Element Catalog
  3. Variability Guide
  4. Other Information
  5. Related Views

Primary Presentation

Overview

The Module View provides a structural decomposition of the web application into logical modules, illustrating how the system is organized into layers and packages. This view focuses on the organization of the software code into modules and their relationships, supporting the developers' understanding of the system's architecture.

Diagram Description

Since diagrams cannot be included, the following is a detailed description of the primary presentation.

The application is structured following the Model-View-Controller (MVC) architectural pattern, as implemented by the Django framework.

Layers and Modules:

  1. Presentation Layer:

    • Templates: HTML files that define the structure and layout of web pages.
    • Static Files: CSS, JavaScript, and image files used for styling and client-side interactions.

  2. Application Layer:

    • Views: Python functions or classes that handle HTTP requests and responses.
    • Forms: Python classes that handle user input validation and processing.
    • URLs: Configuration files that map URL patterns to views.

  3. Business Logic Layer:

    • Models: Python classes that define the data structures and business rules.
    • Services: Modules that contain business logic not tied directly to models or views.

  4. Data Access Layer:

    • Database: The underlying database (e.g., PostgreSQL) that stores persistent data.
    • ORM (Object-Relational Mapping): Django's ORM that provides an abstraction over the database.

  5. Support Modules:

    • Utilities: Helper functions and classes used across multiple modules.
    • Middleware: Classes that process requests and responses globally.

Key Elements and Relationships:

  • Views interact with Models: Views retrieve and manipulate data through models to fulfill user requests.
  • Templates are rendered by Views: Views render templates with context data to generate HTML responses.
  • Forms are used by Views: Views use forms to handle and validate user input.
  • URLs map to Views: URL patterns are configured to route HTTP requests to the appropriate view functions.
  • Static Files are served to Clients: Static assets are served to enhance the user interface and experience.
  • Middleware processes Requests/Responses: Middleware components can modify requests and responses as they pass through the application stack.

Notation Key

  • Rectangles: Represent modules or components.
  • Arrows: Indicate dependencies or interactions between modules.
    • Solid Arrows: Direct invocation or usage.
    • Dashed Arrows: Indirect interactions or dependencies.
  • Layers: Groupings of modules that serve a common purpose.

External Elements

  • Client Browser: Represents the user's web browser interacting with the application.
  • External APIs: Third-party services or APIs the application may consume (e.g., payment gateways, geolocation services).
  • Email Server: Used for sending notification emails to users.

Note: External elements are marked distinctly to indicate they are outside the scope of the application's codebase.

Element Catalog

This section provides detailed information about each module in the Primary Presentation.

Presentation Layer

Templates

Element Description
Base Templates Provide the foundational HTML structure (e.g., base.html) used by other templates to ensure a consistent look and feel across the application.
Triage Templates Templates related to the triage process (e.g., triage.html, triage_question_1.html).
Appointment Templates Templates for appointment booking and management (e.g., appointment_list.html, appointment_detail.html).
Profile Templates Templates for user profile management (e.g., profile_view.html, profile_edit.html).

Static Files

Element Description
CSS Files Stylesheets that define the visual appearance of the application (e.g., styles.css).
JavaScript Files Scripts that enhance interactivity and client-side validation (e.g., triage.js, appointment.js).
Images Icons and images used throughout the application (e.g., logos, background images).

Application Layer

Views

Element Description
triage_view Handles the triage process, collects user inputs, and calculates the priority score.
appointment_list_view Displays a list of available appointments based on user selection and priority score.
appointment_detail_view Shows detailed information about a specific appointment and allows users to book it.
profile_view Displays user profile information and allows users to view their details.
profile_edit_view Allows users to edit their profile information, such as contact details and preferences.

Forms

Element Description
TriageForm Collects and validates user inputs during the triage process, including symptoms and durations.
AppointmentForm Handles appointment booking inputs and validations.
ProfileForm Manages user input for updating profile information.

URLs

Element Description
urls.py Contains URL patterns that map HTTP requests to the corresponding views.
triage_urls.py Specific URL patterns related to the triage process.
appointment_urls.py URL patterns for appointment-related views.
profile_urls.py URL patterns for user profile management views.

Business Logic Layer

Models

Element Description
UserProfile Represents user-specific information, such as personal details and medical history.
Appointment Defines the structure of appointment data, including date, time, clinic, and status.
Clinic Contains information about clinics, including location, services offered, and available schedules.
TriageResult Stores the results of the triage process, including priority score and recommended actions.

Services

Element Description
TriageService Contains business logic for calculating the priority score and determining recommendations based on user inputs.
AppointmentService Manages appointment availability, booking logic, and conflict resolution.
NotificationService Handles sending emails or notifications to users regarding appointments or important updates.

Data Access Layer

ORM

Element Description
Django ORM Provides an abstraction layer for database interactions, allowing models to be queried and manipulated easily.

Database

Element Description
PostgreSQL The relational database system used to store persistent data for the application.
Database Schemas The structure of the database tables corresponding to the models defined in the application.

Support Modules

Utilities

Element Description
utils.py Contains helper functions and common utilities used across multiple modules (e.g., date formatting, validation routines).
validators.py Custom validation functions for forms and models.

Middleware

Element Description
AuthenticationMiddleware Ensures users are authenticated before accessing certain views.
LoggingMiddleware Captures and logs requests and responses for debugging and monitoring purposes.

Variability Guide

The application supports several points of variability and configuration to accommodate different deployment environments and user needs.

Configurable Settings

  1. Database Configuration:

    • Support for different database backends (e.g., PostgreSQL, MySQL, SQLite) through Django's settings.
    • Parameters such as database host, port, user, and password can be configured.

  2. Authentication Backend:

    • Ability to switch between different authentication methods (e.g., username/password, OAuth providers).
    • Configurable via Django's authentication settings.

  3. Appointment Parameters:

    • Number of appointments displayed per page can be adjusted.
    • Appointment booking windows (e.g., how far in advance users can book) are configurable.

  4. Triage Scoring Thresholds:

    • The thresholds for priority scores that determine recommended actions can be adjusted.
    • Weight factors in the priority score calculation (e.g., severity weight, symptom weight) are configurable.

  5. Language and Localization:

    • Support for multiple languages through Django's internationalization framework.
    • Text strings and templates can be localized.

  6. Email Notifications:

    • Email server settings (SMTP host, port, credentials) are configurable.
    • Templates for email notifications can be customized.

Plugin Support

  • Custom Themes:

    • The application supports theming through the use of CSS and template overrides.
    • Organizations can implement custom branding.

  • Integration with External Services:

    • API keys and endpoints for external services (e.g., mapping services, third-party analytics) can be configured.

Deployment Configurations

  • Debug Mode:

    • Toggle between development and production settings, affecting debugging outputs and static file handling.

  • Middleware Configuration:

    • Enable or disable middleware components based on performance or security requirements.

Other Information

Design Decisions and Rationale

  1. Use of Django Framework:

    • Rationale: Django provides a robust, scalable framework with built-in ORM, authentication, and admin interfaces.
    • Alternatives Considered: Flask (less overhead but requires more setup for standard features), Ruby on Rails.

  2. MVC Architectural Pattern:

    • Rationale: Separates concerns, making the application easier to maintain and extend.
    • Alternatives Considered: Model-View-ViewModel (MVVM), but deemed less suitable for web applications without heavy client-side logic.

  3. Priority Score Calculation on Server Side:

    • Rationale: Centralizes the business logic and maintains data integrity.
    • Alternatives Considered: Calculating on the client side, but rejected due to security concerns and potential manipulation.

  4. Dynamic Form Rendering:

    • Rationale: Improves user experience by showing relevant questions based on previous answers.
    • Implementation: JavaScript functions handle form progression and visibility.

Rejected Alternatives

  • Single Page Application (SPA):

    • Considered using a frontend framework like React or Angular.
    • Rejected Due To: Increased complexity and resource requirements; deemed unnecessary for the application's scope.

  • Serverless Architecture:

    • Considered deploying on a serverless platform.
    • Rejected Due To: Need for persistent connections and complex background processing not well-suited to serverless constraints.

Context Diagram

Description of the Context Diagram:

  • The system interacts with external entities such as:

    • Users: Patients accessing the application via web browsers.
    • Clinics: Backend systems or staff interfacing for appointment management.
    • Email Server: External SMTP server used for sending notifications.
    • Third-Party APIs: Services for address validation, geolocation, or analytics.

  • The application sits within a deployment environment that includes:

    • Web Server: Hosts the application (e.g., Gunicorn or uWSGI).
    • Reverse Proxy: Nginx or Apache serving as a proxy and handling static files.
    • Database Server: Hosts the PostgreSQL database.

Related Views

Allocation View

  • Relation: The Module View maps to the Allocation View by showing how software modules are deployed onto hardware and assigned to development teams. image

Runtime View

  • Relation: The Module View relates to the Runtime View by defining the components that interact during execution. nLR1RXit4BtpAmO-sGStzm8E8jj9Mg1EDbeblHG8AEv4cePBRack7VrzPxchSAaIa988pKLO3jzx96VUa7hXWtIXRxK853J2iZU1MeGFX4zmJtBZP0lNi7ByYI1D0ukkisH2YoR0hRMVoMoWSbQXzq985Qo3IWRYQI4wrYP5dMJinP-uXbjddpow2v1-_vs3blY8pkEW-6Ntbxbyio7pvI

Context View

  • Relation: Provides an external perspective, showing how the system interfaces with external entities. image