Final Report: Development of UTE GYM Membership Management System

Manual and paper-based gym membership tracking commonly leads to lost records, missed renewal dates, unverifiable payments, and no reliable way to separate what front-desk staff, trainers, and members are each allowed to do. This report presents the design and development of the UTE GYM Membership Management System, a role-based web application built in Python using the Flask framework, the SQLAlchemy ORM, Jinja2 templates, and a relational MySQL/SQLite3 database. The system was developed following Object-Oriented Programming principlesencapsulation, inheritance, polymorphism, and abstraction and a four-layer architecture that separates presentation (routes and templates), business logic (services), data access (repositories), and persistent storage (database). Four roles are supported: Admin, Staff, Trainer, and Member, each constrained by a role-based access control (RBAC) layer enforced through route decorators and a UserFactory that maps each account to a permission-bearing domain class. Core features include member registration, membership-plan enrollment and renewal, payment recording and verification, attendance check-in, and trainer-assigned training sessions. The development followed an iterative, prototype-oriented workflow: requirements analysis, OOP and database design, layer-by-layer implementation, and automated testing with pytest covering authentication, RBAC, models, services, schema contracts, and the staff check-in flow. Results show a working, testable system that models the full membership lifecycle and enforces business rules such as pending-until-verified payments and dynamically computed membership status. The report concludes with an evaluation of the system's functionality, usability, and maintainability, and proposes future improvements including a fully role-restricted production deployment, richer reporting, and (per the guideline's original scope) a native desktop client.

I. Introduction

1.1 Problem Statement

Small and medium-sized gyms frequently rely on manual, paper-based or spreadsheet-based record keeping for member registration, membership renewal, payment tracking, and daily attendance. This approach is slow to search, prone to human error, offers no automatic way to flag an expiring or expired membership, provides no verification step for cash or transfer payments, and gives every staff member the same unrestricted access to sensitive records regardless of their role. As a gym's member base grows, these weaknesses compound: renewal dates are missed, revenue figures become unreliable because unverified payments are indistinguishable from confirmed ones, and there is no structured way for trainers to manage the members assigned to them.

1.2 Objectives

● To analyze the operational problems of manual gym membership tracking.

● To design a role-based management application using Object-Oriented Programming principles.

● To develop a Flask/Jinja2-based web interface for Admin, Staff, Trainer, and Member roles.

● To design and implement a relational database (MySQL, with SQLite3 for local development) using SQLAlchemy.

● To implement CRUD, search, filter, validation, and reporting features for members, plans, payments, and attendance.

● To implement role-based access control (RBAC) so each role can only perform its permitted actions.

● To test and evaluate the application based on usability, functionality, reliability, and performance.

1.3 Scope and Significance

Scope:

· User and role management

· Member registration and management

· Membership plan catalog management

· Membership enrollment and renewal

· Payment recording and verification

· Attendance check-in/check-out

· Trainer-assigned training sessions

· No online payment gateway integration

· No SMS/email notifications

· No multi-branch support

· No native desktop or mobile application

Significance:

· Centralizes records in a single database

· Reduces scattered and duplicated information

· Provides an auditable system for tracking activities

· Enforces accountability through role-based permissions

· Improves payment verification and management

· Provides dashboards for staff, trainers, and members

· Shows each user only the data relevant to their role

1.4 Functional and Non-Functional Requirements

Requirement Type	Examples
Functional requirements	Register members; create/edit membership plans; enroll and renew memberships; record and verify payments; check members in/out; assign and schedule training sessions; search and filter records; view role-scoped dashboards.
Non-functional requirements	Usability (clear role-specific dashboards); performance (fast page loads on typical gym-front-desk hardware); reliability (dynamically computed, always-current membership status); security (hashed passwords, session timeout, RBAC); maintainability (four-layer architecture, automated tests); data accuracy (server-side validation before persistence).

II. Literature Review and Development Background

2.1 Background of Similar Systems

Two categories of exiting systems were reviewed: generic spreadsheet-based tracking and commercial gym-management SaaS platforms. Table 5 compared these with the proposed system.

System	Main Features	Strengths	Limitations	Lessons for Proposed System
Spreadsheet-based tracking	Manual entry of members and payments in a spreadsheet	Simple, no setup cost	No validation, no role separation, no automatic status/expiry logic	Automate status computation and enforce structured, validated input
Commercial gym-management SaaS	Member CRM, billing, class scheduling, reporting	Feature-rich, polished UI	Subscription cost, vendor lock-in, limited customization for a course project	Reuse the useful concepts (role dashboards, membership lifecycle, verified payments) in an in-house, extensible architecture
Proposed System (UTE GYM)	OOP domain model, Flask web UI, SQLAlchemy/MySQL database, CRUD, RBAC, payment verification, attendance, training	Purpose-built for the gym's roles; fully owned source code; automated test coverage	Prototype-level: single-branch, no payment gateway, no notifications yet	Future development can add login hardening, notifications, and multi-branch support

2.2 Concepts and Technologies

System	Main Features
Spreadsheet-based tracking	Manual entry of members and payments in a spreadsheet
Commercial gym-management SaaS	Member CRM, billing, class scheduling, reporting
Proposed System (UTE GYM)	OOP domain model, Flask web UI, SQLAlchemy/MySQL database, CRUD, RBAC, payment verification, attendance, training
System	Main Features
Spreadsheet-based tracking	Manual entry of members and payments in a spreadsheet
Commercial gym-management SaaS	Member CRM, billing, class scheduling, reporting
Proposed System (UTE GYM)	OOP domain model, Flask web UI, SQLAlchemy/MySQL database, CRUD, RBAC, payment verification, attendance, training
UI/UX Design	The design of interface screens (Jinja2 templates and static assets) and navigation flow so the application is clear and easy to use for each role.
Software Testing	The process of checking that each function works correctly and meets requirements; implemented with the pytest framework.

III. Research and Application Development Methodology

3.1 SDLC Model Selection

An Iterative, Agile-inspired workflow was selected: the four-layer architecture, database schema, and role-based routes were built one feature area at a time, with each cycle followed by manual verification and, later, automated pytest coverage.

Model	Description	Suitability
Prototype Model	Build a working prototype, collect feedback, and improve the system.	Suitable for an initial working version.
Iterative Model (selected)	Develop the system in repeated cycles, adding one feature area per cycle.	Matches how the four layers and role-scoped routes were actually built.
Agile-inspired Workflow	Plan, design, code, test, and review in short cycles.	Reflected in the feature-by-feature route/service implementation and later test-writing pass.
Waterfall Model	Complete requirements, design, coding, testing, and deployment in strict sequence.	Not used — requirements for later modules (e.g., training scheduling) evolved after earlier modules were built.

3.2 System Architecture Design

A Layered architecture separates the web interface, business logic, data access, and database, matching the guideline’s recommended structure with the UI layer implemented as Flask routes and Jinja2 templates instead of PyQt6 windows.

Layer	Main Responsibility	Example Classes or Files
UI Layer (Web)	Render forms, tables, dashboards, and menus; capture user interaction via HTTP requests	Jinja2 templates in app/templates/; static assets in app/static/
Controller / Routing Layer	Receive HTTP requests, apply authentication/RBAC decorators, call services	app/routes/auth_routes.py, admin_routes.py, staff_routes.py, trainer_routes.py, member_routes.py, decorators.py, rbac.py
Business Logic Layer	Process rules, validation, and workflows (e.g., membership status, payment verification)	app/services/auth_service.py, membership_service.py, payment_service.py, attendance_service.py, training_service.py
Data Access Layer	Connect to the database and run queries via the ORM	app/repositories/user_repository.py, membership_repository.py, payment_repository.py, attendance_repository.py
Database Layer	Store structured data in a relational database	MySQL/SQLite3 database; app/models/ (SQLAlchemy entity classes); database/schema.sql

3.3 OOP Design and Class Structure

The system applies inheritance and polymorphism through a common User base class specialized into Admin, Staff, Trainer, and Member subclasses, each overriding permission-check methods; encapsulation and abstraction are applied by hiding database access inside repository classes and business rules inside service classes so route handlers never touch SQL directly.

Class Type	Example Class	Responsibility
Entity Class	User, Admin, Staff, Trainer, Member, Membership, Payment, Attendance, TrainingSession	Represent data objects and attributes; role subclasses override permission methods (e.g., can_manage_members, can_verify_payments).
UI / Template	base.html, dashboard templates per role, member/plan/payment forms	Render the interface and collect user input (Jinja2, the web equivalent of a PyQt6 form).
Controller (Route)	AuthRoutes, AdminRoutes, StaffRoutes, TrainerRoutes, MemberRoutes	Receive requests, enforce RBAC decorators, delegate to services.
Service Class	AuthService, MembershipService, PaymentService, AttendanceService, TrainingService, CoachService, UserService	Process business rules, validation, and multi-step workflows.
Repository Class	UserRepository, MembershipRepository, PaymentRepository, AttendanceRepository, TrainingRepository, MembershipPlanRepository, CoachRepository	Insert, update, delete, and query data via SQLAlchemy.
Database / Config	SQLAlchemy db instance (extensions.py), config.py	Open the database connection, bind models to tables, and manage app configuration.

3.4 Database Design Using SQLite3 / MySQL

The relational schema (database/schema.sql) defines roles, users, and role-specific tables, plus membership, payment, attendance, and training entities, connected by foreign keys. A representative subset is shown below.

Table Name	Field Name	Data Type	Key	Description
roles	role_id	INT	Primary Key	Unique role identifier (Admin, Staff, Trainer, Member, Owner)
users	user_id	INT	Primary Key	Unique account identifier
users	role_id	INT	Foreign Key	Links to the roles table
users	status	VARCHAR(20)	-	ACTIVE / SUSPENDED account status

members	user_id	INT	Primary Key / Foreign Key	Extends users with member-only fields (address, date of birth)
membership_plans	plan_id	INT	Primary Key	Unique plan identifier (duration, price, VIP flag)
memberships	membership_id	INT	Primary Key	Unique membership record
memberships	member_id	INT	Foreign Key	Links to users (the member)
memberships	plan_id	INT	Foreign Key	Links to membership_plans
memberships	status	VARCHAR(20)	-	PENDING / ACTIVE / EXPIRED, derived from end_date
payments	payment_id	INT	Primary Key	Unique payment record
payments	membership_id	INT	Foreign Key	Links to memberships
payments	status	VARCHAR(20)	-	PENDING until verified_by an Admin/Staff user
attendance_log	attendance_id	INT	Primary Key	Unique check-in/check-out record
attendance_log	member_id	INT	Foreign Key	Links to users (the member checking in)
training_schedules	schedule_id	INT	Primary Key	Unique training session record
training_schedules	trainer_id / member_id	INT	Foreign Key	Links a trainer to an assigned member

3.5 UX/UI Design Requirement

As a web application, the interface substitutes Jinja2-rendered HTML pages for PyQt6 windows, while following the same usability principles required by the guideline:

● A role-specific dashboard for each of Admin, Staff, Trainer, and Member, accessed after login.

● Consistent navigation, spacing, and typography across all templates (shared base.html layout).

● Data tables for listing members, plans, payments, and attendance records.

● Form validation with clear, inline error messages on registration, plan, and payment forms.

● Search and filter fields on member, payment, and attendance listings.

● Confirmation prompts before destructive actions such as deleting a member or rejecting a payment.

● Summary-card and status views (e.g., Active/Expiring/Expired counts) in place of a desktop report screen.

Main Dashboard

Member/payment

3.6 Development Workflow

Table 11 summarizes the phase-by-phase workflow used to build the system, followed by the detailed step-by-step flow that was actually used to turn the provided project archive (GYM_fully.zip) into a running, tested application.

Phase	Activities	Expected Output
Problem Analysis	Study manual gym record-keeping, identify problems, collect requirements	Problem statement and requirements (Section I)
System Design	Design architecture, database, class structure, UI/UX flow	Architecture diagram, ERD, class table, template wireframes (Section III)
Implementation	Develop Flask routes, Jinja2 templates, OOP service/repository classes, and the database	Working web application
Testing	Run pytest suites; validate input; check database operations and RBAC	Test cases and results (Section IV)
Documentation	Prepare DOCX report, PPTX slides, screenshots, references, and user manual	Final report and presentation
Improvement	Fix bugs, refine UI/UX, clean up code, prepare the final submission ZIP	Final submission package

Development Workflow Diagram

3.7 Implementation Requirement

The source code is organized into the folders below, matching the four-layer architecture rather than a single unstructured file.

Folder or File	Purpose
run.py	Main application entry point
app/__init__.py	Flask application factory and blueprint registration
app/templates/, app/static/	Jinja2 HTML templates and static assets (the web UI layer, in place of ui/ PyQt6 windows)
app/models/	Entity classes representing data objects (User, Membership, Payment, Attendance, Coach, Training)
app/services/	Business logic and validation classes (auth, membership, payment, attendance, training, coach, user)
app/repositories/	Database access and query classes, one per entity
app/routes/	Flask blueprints (controllers) per role, plus RBAC decorators
database/	schema.sql, seed.sql, coaches.sql, and versioned migration scripts
tests/	pytest automated test suite
docs/	Architecture and role/permission documentation
README.md	Project setup and running instructions

The Project folder Structure

IV. Results and Analysis

4.1 Application Results

This section presents the main screens of the working application. Screenshots should be captured while running the steps in Section 3.6.1 and inserted at the placeholders below.

Main dashboard of the UTE GYM web application

Homepage of the UTE GYM web application

CRUD screenshots: add, update, delete, and view member/plan records

4.2 Testing Results

The application is covered by an automated pytest suite in addition to the manual walkthrough in Section 3.6.1, Step 8. Representative test cases are summarized below; exact pass/fail evidence should be captured by running pytest -v and inserting the console output as Appendix E.

Test Case ID	Function	Input	Expected Output	Result
TC01	User login (test_auth.py)	Valid email/password	Session created; redirected to the correct role dashboard	Automated (pytest)
TC02	Role permission check (test_rbac.py / test_dynamic_rbac.py)	A Staff account requesting a Trainer-only route	HTTP 403 / access denied	Automated (pytest)
TC03	Membership status computation (test_models.py)	A membership with a past end_date	Status computed as EXPIRED	Automated (pytest)
TC04	Payment verification (test_services.py)	A pending payment marked verified by Admin/Staff	Payment status becomes VERIFIED; counts toward revenue	Automated (pytest)
TC05	Staff check-in flow (test_staff_checkin_flow.py)	Staff checks in a member with an active membership	Attendance record created; check-in time stored	Automated (pytest)
TC06	Coach assignment (test_coach_assignments.py)	A member requests a coach	Assignment record created with PENDING status	Automated (pytest)
TC07	Database schema contract (test_schema_contract.py)	Application startup against schema.sql	ORM models match the defined tables/columns	Automated (pytest)

4.3 Analysis and Evaluation

Criterion	Evaluation Question	Evidence to Include
Functionality	Do all required functions (CRUD, payments, attendance, training) work correctly?	pytest results, manual walkthrough screenshots
Usability	Is each role's dashboard easy to understand and use?	Screenshots, brief user feedback/observation
Performance	Does the system respond quickly for typical record volumes?	Practical observation of page load and query response
Reliability	Does the system run without frequent errors across repeated testing?	Repeated pytest runs, manual regression checks
Security	Is data protected via hashed passwords, session handling, and RBAC?	auth_service.py hashing, decorators.py/rbac.py enforcement
Maintainability	Is the code organized, modular, and easy to extend?	Four-layer folder structure, class design, automated tests

4.4 Discussion of Problems and Limitation

The current prototype has several limitations consistent with a course-scoped system: it targets a single gym branch, has no external payment-gateway integration (payments are recorded and manually verified, not processed online), has no automated email/SMS notification for expiring memberships, and most significantly relative to the original assignment guideline implements its UI as a Flask web application rather than a PyQt6 desktop client. During development, care was needed to keep business rules strictly inside the service layer so that routes and templates remained thin, and to keep the RBAC decorator layer consistent across all four role blueprints.

V. Conclusion and Future Development

5.1 Conclusion

This project addressed the problems of manual gym membership tracking by designing and implementing the UTE GYM Membership Management System, a role-based, four-layer web application built with Object-Oriented Programming principles in Python, Flask, SQLAlchemy, and a relational (MySQL/SQLite3) database. The system provides member registration, membership-plan enrollment and renewal, payment recording and verification, attendance check-in, and trainer-assigned training sessions, all governed by a role-based access control layer distinguishing Admin, Staff, Trainer, and Member accounts. Automated testing with pytest confirmed correct behavior of authentication, permission enforcement, membership-status computation, and the staff check-in workflow. The group has demonstrated the full development cycle problem analysis, OOP and database design, layered implementation, and testing required by the assignment, while transparently documenting where the delivered technology stack diverges from the guideline's PyQt6 desktop specification.

5.2 Future Development

Future Feature	Purpose	Priority
Stricter production login/session hardening	Reduce risk in a real deployment	High
Backup and restore	Prevent data loss	High
Advanced reports and export (PDF/Excel)	Improve decision-making and documentation	Medium
Email/SMS renewal notifications	Reduce missed renewals	Medium
Cloud-hosted MySQL database	Support secure multi-device, multi-user access	Medium
Native PyQt6 desktop client (per original guideline)	Offer an offline-capable desktop alternative to the web UI	Low to Medium

References

[1] Python Software Foundation, "Python 3 Documentation," 2026. [Online]. Available: https://docs.python.org/3/

[2] Pallets Projects, "Flask Documentation," 2026. [Online]. Available: https://flask.palletsprojects.com/

[3] Pallets Projects, "Jinja Documentation," 2026. [Online]. Available: https://jinja.palletsprojects.com/

[4] SQLAlchemy Authors, "SQLAlchemy Documentation," 2026. [Online]. Available: https://docs.sqlalchemy.org/

[5] SQLite Consortium, "SQLite Documentation," 2026. [Online]. Available: https://www.sqlite.org/docs.html

[6] Oracle Corporation, "MySQL 8.0 Reference Manual," 2026. [Online]. Available: https://dev.mysql.com/doc/

[7] pytest-dev Team, "pytest Documentation," 2026. [Online]. Available: https://docs.pytest.org/

[8] G. Booch, R. A. Maksimchuk, M. W. Engle, B. J. Young, J. Conallen, and K. A. Houston, Object-Oriented Analysis and Design with Applications, 3rd ed. Boston, MA, USA: Addison-Wesley, 2007.

Final Report: Development of UTE GYM Membership Management System

មតិយោបល់ 0