AI-Powered

Mental Health
Monitoring
System
Intelligent Mood Tracking, Journal
Analysis, and Risk Assessment Platform

Prepared by Instructor: Sir Syed

Bashair Yaqoob
24k-0810
Mehak Zainab 24k-
0508
Table of Contents
Chapter 1: Introduction.........................................................................................................................................................3
1.1 System Overview.................................................................................................................................................3
1.2 Problem Statement..............................................................................................................................................3
1.4 Objectives............................................................................................................................................................4
1.5 Users and Stakeholders........................................................................................................................................4
1.6 System Requirements Summary..........................................................................................................................5
1.7 Software Process Model......................................................................................................................................5
Chapter 2: System Analysis and Modeling............................................................................................................................6
2.1 Use Case Diagram........................................................................................................................................................6
2.2 Class Diagram..............................................................................................................................................................9
2.3 Activity Diagrams.......................................................................................................................................................10
2.4 Sequence Diagram.....................................................................................................................................................11
2.5 Component Diagram.................................................................................................................................................12
2.6 Deployment Diagram................................................................................................................................................15
2.7 Timing Diagram.........................................................................................................................................................16
Chapter 3: Architectural View — 4+1 Model.......................................................................................................................17
3.1 Logical View...............................................................................................................................................................18
3.2 Process View.............................................................................................................................................................18
3.3 Development View....................................................................................................................................................19
3.4 Physical View.............................................................................................................................................................19
3.5 +1 Use Case View......................................................................................................................................................20
Chapter 4: References.........................................................................................................................................................20
Chapter 1: Introduction
1.1 System Overview

The AI-Powered Mental Health Monitoring System is a cross-platform digital health application designed to
support individuals in tracking and understanding their emotional well-being. The system enables users to log
daily mood ratings on a numeric scale of 1 to 10, write personal journal entries, and complete structured
mental health surveys. Using artificial intelligence — specifically natural language processing (NLP) and
sentiment analysis — the system automatically analyses submitted data to detect emotional patterns, assess
psychological risk levels (low, medium, or high), and generates personalized mental health recommendations.

The platform is accessible via a [Link] web application and a React Native mobile application. Both clients
communicate with a [Link] backend API over HTTPS. A separate Python Flask AI service handles all machine
learning operations asynchronously so that the user never waits for analysis to complete. Data persisted in
PostgreSQL for structured relational records and MongoDB for unstructured journal text, with Redis providing
in-memory session caching for fast token verification. An administrative panel allows authorized personnel to
manage survey content and monitor platform-wide usage statistics.

1.2 Problem Statement

Mental health disorders including anxiety, depression, and chronic stress are increasingly prevalent among
students and young professionals worldwide. A significant proportion of individuals experiencing early-stage
psychological distress do not seek professional help, either because warning signs go unnoticed until they
become severe, because access to professional mental health services is financially or geographically limited,
or because social stigma discourages help-seeking behavior.

Existing digital tools are often too clinical in their approach and intimidating for everyday users, too expensive
to sustain as long-term habits, or too generic to provide meaningful personalized insight that changes over
time. Most tools either act as simple mood diaries with no intelligent processing or jump straight to clinical
assessment tools that feel invasive.

There is a clear gap for an accessible, intelligent, and privacy-respecting self-monitoring system that
empowers individuals to understand their own mental health trends in plain language, flag early warning
signals automatically, and receive actionable recommendations — without requiring professional mediation
for every interaction. This system directly addresses that gap by combining user-friendly data entry with
automated AI-driven analysis, translating raw emotional data into a meaningful, ongoing health picture.

1.3 Scope

The system will provide a mental health support platform. Users will be able to register, log in securely, and
manage their personal profiles within the application. The platform will support daily mood logging using a
numeric scale from 1 to 10, along with optional descriptive notes, while restricting entries to one per day.
Users will also have access to a personal journaling feature that allows them to create, store, and retrieve
journal entries. Administrators will be responsible for creating and managing mental health surveys, while
users will be able to complete these surveys and receive calculated scores. The system will incorporate AI-
driven Natural Language Processing (NLP) sentiment analysis to examine journal entries and classify emotional
polarity as positive, neutral, or negative. In addition, the platform will perform mood trend analysis over
rolling 30-day periods to identify improving or declining emotional patterns. Automated risk-level assessments
will be generated by combining mood averages, sentiment analysis outcomes, and survey scores, after which
the system will provide personalised mental health recommendations based on the identified risk level. The
platform will also generate mental health reports containing mood trend graphs, risk badges, and
recommendations for users. Furthermore, an administrative dashboard will be included for survey
management and system-wide analytics, while push notifications, email alerts, and automated background
cron jobs will be used for daily mood reminders, weekly summaries, report-ready alerts, and high-risk
warnings.

The system will not include real-time consultations with therapists, clinical diagnosis, or medical treatment
services. It will also exclude wearable device integration, payment or subscription features, social networking
or peer messaging functions, and crisis intervention or emergency escalation services.

1.4 Objectives
The main objectives of the system are to:
 Allow users to log one daily mood entry (scale 1–10) with an optional descriptive note
 Enable users to create, read, and delete personal journal entries
 Allow users to complete mental health surveys created by administrators
 Apply NLP sentiment analysis to classify journal emotions as positive, neutral, or negative
 Compute user risk levels (low, medium, high) using mood, sentiment, and survey data
 Generate personalised mental health recommendations based on risk level
 Compile and display mental health reports with mood trends and insights
 Allow administrators to create, update, and delete surveys with scoring weights
 Provide administrators with a system-wide usage analytics dashboard
 Deliver push notifications and email alerts for reports and high-risk warnings
 Automate daily mood reminders and weekly summary report generation through cron jobs

1.5 Users and Stakeholders

Stakeholder / Type Description
Role

User Primary human Registers and uses the platform to monitor personal mental health. Logs daily
actor mood, writes journal entries, completes surveys, and views their health reports
and recommendations

Admin Primary human Manages survey content via the admin panel, views usage analytics
actor dashboards, and moderates user accounts

Guest Primary human Can view the public-facing landing page and initiate the registration process.
actor Cannot access any core system features without a registered and authenticated
account

AI System Secondary Internal automated actor triggered after each data submission to perform NLP
system actor sentiment analysis, risk assessment, and recommendation generation

Notification Secondary Internal and external actor that delivers push notifications (via Firebase FCM)
Service system actor and email alerts (via SendGrid SMTP) on behalf of the system

Development Stakeholder Responsible for building, testing, deploying, and maintaining the system
Team throughout its lifecycle

University / Academic Evaluating the project for technical quality, completeness, and compliance with
Instructor stakeholder software design and architecture guidelines
1.6 System Requirements Summary
Functional Requirements
 The system shall allow users to register with a valid email address and secure password.
 The system shall authenticate users and issue a signed JWT token with a 24-hour expiry.
 The system shall allow users to log one mood entry per day on a scale of 1 to 10 with an optional note.
 The system shall allow users to create, read, and delete personal journal entries.
 The system shall allow users to view and complete available mental health surveys.
 The system shall automatically perform NLP sentiment analysis on submitted journal entries.
 The system shall compute a risk level (low, medium, or high) after each new data submission.
 The system shall compile and display personalised health reports with mood trends and
recommendations.
 The system shall allow administrators to create, update, and delete surveys with scoring weights.
 The system shall allow administrators to view a system-wide usage analytics dashboard.
 The system shall deliver push and email notifications for reports and elevated risk levels.
 The system shall run a daily cron job at 09:00 AM to send mood-logging reminders.
 The system shall run a weekly cron job every Sunday at 08:00 AM to generate and deliver summary
reports.
Non-Functional Requirements
 API response time shall remain under 2 seconds under normal load.
 User data shall be encrypted in transit using TLS 1.3 and at rest using AES-256.
 The system shall maintain 99.5% uptime excluding planned maintenance.
 The interface shall be responsive on desktop and mobile devices.
 The backend shall support horizontal scaling using stateless JWT authentication and Redis caching.
 The codebase shall follow a modular MVC architecture with clear separation of concerns.

1.7 Software Process Model

The Iterative Development Model was selected for this project because the system is composed of clearly
separable functional modules authentication, mood tracking, journal management, survey handling, AI
analysis, report generation, and notification delivery — each of which can be developed, integrated, and
tested independently in a separate iteration. Requirements are sufficiently well understood upfront to plan
the iterations, but the AI analysis component specifically benefits from iterative refinement: the NLP model's
accuracy, the risk scoring thresholds, and the recommendation logic can all be adjusted based on empirical
testing results without disrupting any other module.
Each iteration produces a fully testable software increment that adds functional value. This model was
preferred over a pure Waterfall approach because it allows early feedback on core features before the
complete system is assembled, reducing the cost of late-stage corrections. It was preferred over full Agile or
Scrum because the academic context does not require sprint ceremonies and retrospectives, and a small team
benefits more from a structured iteration plan than from a full agile process framework. The Iterative model
strikes the right balance between planning rigor and the flexibility to refine the AI component based on real
data.

Chapter 2: System Analysis and Modeling

This chapter presents the complete set of UML diagrams that model the behaviour and structure of the AI-
Powered Mental Health Monitoring System. Together these diagrams provide a comprehensive view of
system actors, object interactions, workflow logic, class relationships, component dependencies, and
deployment topology.

2.1 Use Case Diagram

Actors

Actor Type Description

User Primary Registers, logs moods, writes journal entries, completes surveys, and views
reports and recommendations

Admin Primary Manages surveys, views system analytics, and moderates user accounts

Guest Primary Accesses the public landing page and initiates registration

AI System Secondary Performs automated sentiment analysis and risk evaluation after data
(System) submission

Notification Secondary Sends automated push and email notifications

Service (System)

Main Use Cases

Use Case Actor(s)

Register / Sign Up Guest

Login / Logout User, Admin

Log Daily Mood User

Write Journal Entry User

Complete Health Survey User

View Mood History User

View Mental Health Report User

Receive Recommendations User

View Notifications User, Admin

 Update Profile User

Create / Update / Delete Survey Admin

View System Analytics Admin

Moderate User Accounts Admin

Trigger AI Analysis AI System

Send Notification Notification Service

Include and Extend Relationships

Relationship Type Purpose

Write Journal Entry → Trigger AI Analysis <<include>> Every journal submission automatically triggers AI
analysis

Complete Health Survey → Trigger AI Analysis <<include>> Survey responses are always processed for analysis

Log Daily Mood → Trigger AI Analysis <<include>> Mood entries contribute to trend and risk analysis

Trigger AI Analysis → Receive <<include>> Recommendations are generated after analysis

Recommendations completion

Login → Verify JWT Token <<include>> Token verification is required during authentication

View Mental Health Report → View <<extend>> Notifications appear only when a report becomes
Notifications available

Trigger AI Analysis → Send Notification <<extend>> Alerts are sent only when high-risk levels are detected

Use Case Description Table

Use Case Preconditions Main Flow Postconditions

Write User is logged in User submits a journal entry → system stores Journal entry, sentiment
Journal entry → AI analysis and recommendations are analysis, and recommendations
Entry generated → notification is sent are saved

View Mental User has existing System retrieves mood, sentiment, and Personalised mental health
Health system data recommendation data → report with trends report is shown
Report and risk level is displayed

Create Admin is Admin creates survey with questions and Survey becomes available to
Survey authenticated scoring weights → system validates and stores users
survey
2.2 Class Diagram
The Class Diagram illustrates the static object-oriented structure of the system, showing all entity, boundary,
and control classes along with their attributes, methods, and the relationships between them.
BCE Model Classification

Class Classes Description

Type

Boundary LoginForm, MoodLogForm, JournalForm, SurveyForm, Interface classes that interact directly with
ReportView, AdminDashboard human actors. They handle input, display
output, and delegate processing to control
classes

Control AuthController, MoodController, JournalController, Classes that handle business logic and
SurveyController, AIController, ReportController, orchestrate the processing flow between
NotificationController, AdminController boundary and entity classes

Entity User, MoodLog, JournalEntry, Survey, SurveyResponse, Persistent data classes that are stored in the
AIAnalysis, Recommendation, Admin database and represent the core domain
objects of the system

Key Class Relationships

From Class To Class Relationship Type Description

User MoodLog Composition (1 to User owns mood logs; logs are deleted when user is
many) deleted

User JournalEntry Composition (1 to User owns journal entries; deleted with user
many)

User SurveyResponse Association (1 to User submits multiple responses; persist independently

many)

User Recommendation Aggregation (1 to A User can receive multiple Recommendations

many)
Survey Survey Response Composition (1 to Survey is composed of questions; response are recorded
many) and deleted with survey

JournalEntry AIAnalysis Association (1 to 1) Each entry generates exactly one analysis record

AIAnalysis Recommendation Dependency Analysis result drives recommendation generation

Admin Survey Inheritance Admin manages Surveys

2.3 Activity Diagrams
Activity Diagrams model the major workflows within the system, showing step-by-step logic including
decisions, concurrent processing (fork and join), and responsibilities across swimlanes.
1. The user logs into the system.
2. The user selects an activity such as logging mood, writing a journal entry, or completing a survey.
3. The system stores the input data.
4. The AI module analyzes the emotional data.
5. The system determines the risk level.
6. Recommendations or warnings are generated based on the analysis.
7. The system generates a mental health report.
8. The report is displayed to the user.
This diagram illustrates how the system processes user input and produces meaningful insights.

2.4 Sequence Diagram

The Sequence Diagram shows the chronological message-passing interactions between system objects for the
primary use case: a user submitting a journal entry and receiving an AI-generated mental health report.
Interaction Flow
1. The user logs into the system.
2. The user writes a journal entry or logs mood data.
 3. The system stores the data in the database.
4. The system sends the data to the AI analyzer.
5. The AI analyzer processes the data and returns the sentiment or risk analysis.
6. The system generates recommendations based on the analysis.
7. The recommendations and mental health report are displayed to the user.
This diagram highlights the chronological interaction between system components and illustrates how data
flows through the system.

2.5 Component Diagram

The Component Diagram illustrates the physical and logical building blocks of the system using proper UML
notation — component boxes with <<component>> stereotypes, provided interfaces (lollipop circles showing
what a component offers), required interfaces (socket semicircles showing what a component needs), and
ports marking the connection points on the component boundary.
Components and Their Interfaces
Component Provided Interfaces Required Interfaces Responsibility

User Module Login, Register UserData (from Auth All user-facing interaction flows
Service)

Auth Service AuthToken Credentials (from User JWT generation and token
Module) verification

Mood Service MoodLog MoodData (required by AI Log and retrieve daily mood entries
Module)

Journal Service JournalEntry EntryText (required by AI CRUD operations on journal entries

Module)

Survey Service SurveyResult SurveyData (required by Deliver survey questions and score
AI Module) responses

AI Analysis Module AnalysisResult RawData, external NLP NLP sentiment analysis and risk level
API scoring

Report and HealthReport, AnalysisResult (from AI Compile health reports and

Recommendations NotifyTrigger Module) generate personalised tips

Notification Service Alert delivery to user NotifyTrigger, SMTP, FCM Push and email alert delivery

Admin Module SurveyMgmt AdminDB access Survey content management and

analytics viewing
2.6 Deployment Diagram
The Deployment Diagram shows the physical distribution of software artifacts across hardware and cloud
infrastructure nodes using UML node notation — 3D cube shapes with <<stereotype>> labels. Artifacts
(deployable files and software modules) sit inside their respective nodes. Communication paths between
nodes are drawn as solid or dashed lines labeled with protocols and port numbers.
Communication Paths

From To Purpose

User Device Web App Server All user API requests

Web App AI Server AI analysis requests

Server

Web App Database Server Read and write structured and document data
Server

Web App Cache Server JWT session token verification

Server

Web App External Services Email and push notification delivery

Server

AI Server External NLP API NLP model inference calls

AI Server Database Server Historical mood and journal data reads for trend analysis

The Database Server and Cache Server sit inside a private VPC (Virtual Private Cloud) with no public-facing IP
address. Only the Web App Server and AI Server can reach them through internal network ports.
2.7 Timing Diagram
Chapter 3: Architectural View — 4+1 Model
The 4+1 Architectural View Model (Kruchten, 1995) describes software architecture from five simultaneous
and complementary perspectives. No single diagram captures the full complexity of a system, so the 4+1
model provides a structured framework that serves different audiences: developers use the Logical and
Development views, system integrators use the Process and Physical views, and clients and evaluators use the
Use Case view. All four main views are driven by and validated against the central Use Case view — the "+1."
3.1 Logical View

3.2 Process View

3.3 Development View

3.4 Physical View

3.5 +1 Use Case View

Chapter 4: References
[1] Booch, G., Rumbaugh, J., and Jacobson, I. (2005). The Unified Modeling Language User Guide (2nd ed.). Addison-
Wesley Professional.

[2] Larman, C. (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative
Development (3rd ed.). Prentice Hall.

[3] Object Management Group. (2017). OMG Unified Modeling Language Specification, Version 2.5.1. Retrieved from
[Link]
[4] Kruchten, P. (1995). The 4+1 View Model of Architecture. IEEE Software, 12(6), 42–50.
[Link]

[5] Pressman, R. S. and Maxim, B. R. (2014). Software Engineering: A Practitioner's Approach (8th ed.). McGraw-Hill
Education.

[6] Sommerville, I. (2015). Software Engineering (10th ed.). Pearson Education.

[7] Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd ed.). Addison-Wesley
Professional.

[8] [Link] / [Link]. (2024). Free Online Diagram Software. Retrieved from [Link]

[9] Lucidchart. (2024). UML Diagram Tool and Templates. Retrieved from [Link]

[10] [Link] Foundation. (2024). [Link] Documentation. Retrieved from [Link]

[11] PostgreSQL Global Development Group. (2024). PostgreSQL 16 Documentation. Retrieved from
[Link]

[12] MongoDB, Inc. (2024). MongoDB Documentation. Retrieved from [Link]

[13] Hugging Face. (2024). Transformers: State-of-the-art Machine Learning for PyTorch, TensorFlow, and JAX. Retrieved
from [Link]

[14] Firebase. (2024). Firebase Cloud Messaging Documentation. Retrieved from

[Link]