documentation

.vscode/settings.json

@@ -0,0 +1,4 @@
+{
+    "python-envs.defaultEnvManager": "ms-python.python:system",
+    "python-envs.pythonProjects": []
+}

ADR Documentation /01_MVCarchitecture.md

@@ -0,0 +1,26 @@
+# Finance Tracker Flask App
+
+This project is a fork of the open-source Finance Tracker (0xramm/Finance-Tracker). The original code provides a working Flask app for tracking expenses and income. For our course project, we decided to keep this base and focus on understanding, documenting, and lightly extending its architecture and quality.
+
+For a full structural overview, see `ARCHITECTURE.md`.
+
+## Decisions
+- Keep the original Flask-based structure and database schema.
+- Use the refactored architecture description in `ARCHITECTURE.md` to explain the system in layered, MVC-style terms (presentation, domain, data access).
+- Add our own documentation and tests on top of the fork.
+
+## Rationale
+- Starting from a working open-source app lets us concentrate on architecture, design, and testing rather than just rebuilding CRUD.
+- This fits the assignment’s goal of adapting and improving an existing project.
+- Documenting the architecture helps us and the grader understand how the app is organized.
+
+## Consequences
+
+** Pros **
+- Faster to get to design and testing work.
+- Clear story for the final report: we evaluated and extended an existing app.
+- We can compare behavior with the original project if needed.
+
+** Cons**
+- We did not design every part of the code from scratch.
+- Some legacy design decisions remain from the original project.

ADR Documentation /02_Flask+SQLite

@@ -0,0 +1,32 @@
+# ADR 0002 – Flask + SQLite Technology Stack
+
+## Overview
+We built the Finance Tracker on top of the **Flask web framework** with **SQLite** as the database, to keep the stack lightweight and easy to run for this class project.
+
+## Decision
+We intentionally adopted and refined the existing technology stack:
+
+- **Flask** – Web framework used for routing, sessions, templating, and request handling.
+
+- **SQLite** – Lightweight, file-based database for storing users and transactions.
+
+- **Jinja2** – Template engine used to generate dynamic HTML views.
+
+## Rationale
+- Flask is simple, flexible, and ideal for a small project.
+- SQLite requires no external server, making it easy to run the project.
+- The inherited stack reduced setup overhead but still allowed us to apply architectural patterns, testing, and documentation practices.
+- Flask integrates naturally with Jinja2, which supports MVC principles through template-based views.
+
+
+## Consequences
+
+### Pros
+- Easy environment setup (`pip install -r requirements.txt`).
+- No separate database needed.
+- Lightweight and fast enough for development/demo.
+- Maintains compatibility with the open-source fork.
+
+### Cons
+- SQLite is not designed for high-concurrency production workloads.
+- Flask requires manual implementation of some features 

ADR Documentation /03_testing

@@ -0,0 +1,32 @@
+# ADR 03 – Testing Strategy with pytest
+
+## Overview
+Because this project is forked from an open-source Finance Tracker, our main contribution focuses on improving reliability and maintainability through automated testing. The original repository did not include a formal test suite.
+
+## Decision
+We decided to add a lightweight but meaningful testing strategy based on:
+
+- **pytest** as the test runner.
+- A **tests/** directory to organize route and behavior tests.
+- A shared **test client fixture** to simulate HTTP requests to the Flask app.
+- Tests that focus on:
+  - Route availability (e.g., `/`, `/login`, `/register`, `/transactions`, `/statistics`).
+  - Correct status codes (200, 302, 404).
+  - Redirect behavior for protected routes (e.g., redirecting unauthenticated users to `/login`).
+
+## Rationale
+- Automated tests give us confidence that core pages work as expected after changes.
+- Route and redirect tests are fast and easy to run on any machine.
+- A clear testing structure demonstrates good software engineering practice on top of the inherited codebase.
+- Using pytest integrates well with Python and Flask and matches course expectations.
+
+## Consequences
+
+### Pros
+- Increases confidence when refactoring or extending the app.
+- Provides quick feedback if a route is accidentally removed or broken.
+- Makes the project look more professional and complete for the final report.
+
+### Cons
+- Current tests focus on high-level behavior and do not cover every edge case or database scenario.
+- More detailed tests (e.g., full login + transaction flows) would require additional setup and test data.

ARCHITECTURE.md

@@ -0,0 +1,142 @@
+# Finance Tracker - Refactored Architecture
+
+## Overview
+The Finance Tracker application has been refactored from a monolithic Flask structure into a clean, layered architecture following MVC principles with proper separation of concerns.
+
+## Architecture Layers
+
+### 1. **Presentation Layer** (`app/views/`)
+- **Purpose**: Handle HTTP requests and responses
+- **Components**:
+  - `auth_routes.py` - Authentication (login, register, logout)
+  - `main_routes.py` - Dashboard, statistics, and API endpoints  
+  - `transaction_routes.py` - Transaction management
+  - `budget_routes.py` - Budget management
+- **Responsibilities**:
+  - Route handling and URL mapping
+  - Request/response processing
+  - Template rendering
+  - Input validation
+
+### 2. **Service Layer** (`app/services/`)
+- **Purpose**: Business logic and domain operations
+- **Components**:
+  - `user_service.py` - User management and authentication logic
+  - `transaction_service.py` - Transaction processing and financial calculations
+  - `budget_service.py` - Budget operations and analytics
+- **Responsibilities**:
+  - Business rule enforcement
+  - Data validation
+  - Cross-cutting concerns (authorization, calculations)
+  - Orchestration of repository operations
+
+### 3. **Repository Layer** (`app/repositories/`)
+- **Purpose**: Data access abstraction
+- **Components**:
+  - `base.py` - Abstract repository interface and database initialization
+  - `user_repository.py` - User data operations
+  - `transaction_repository.py` - Transaction data operations
+  - `budget_repository.py` - Budget data operations
+- **Responsibilities**:
+  - Database CRUD operations
+  - Query execution
+  - Data mapping between database and models
+  - Transaction management
+
+### 4. **Domain Layer** (`app/models/`)
+- **Purpose**: Core business entities and domain logic
+- **Components**:
+  - Data models: `User`, `Transaction`, `Budget`, `Category`
+  - Value objects: `BudgetAnalytics`, `FinancialSummary`
+  - Enums: `TransactionType`, `BudgetPeriod`
+- **Responsibilities**:
+  - Entity definitions
+  - Domain validation
+  - Business state management
+  - Type safety
+
+### 5. **Configuration Layer** (`config/`)
+- **Purpose**: Application configuration and settings
+- **Components**:
+  - `settings.py` - Configuration management
+- **Responsibilities**:
+  - Environment-based configuration
+  - Database connection settings
+  - Application parameters
+
+## Architecture Benefits
+
+### **Separation of Concerns**
+- Each layer has a single responsibility
+- Business logic separated from data access and presentation
+- Clean interfaces between layers
+
+### **Testability**
+- Repository pattern enables easy mocking
+- Service layer can be unit tested independently
+- Clear dependency injection points
+
+### **Maintainability**
+- Modular structure makes code easier to understand
+- Changes in one layer don't affect others
+- Easy to extend and modify
+
+### **Scalability**
+- Clear boundaries allow for easy refactoring
+- Can switch databases without affecting business logic
+- Can add new features without breaking existing code
+
+### **Type Safety**
+- Strongly typed models with dataclasses
+- Enum usage for constants
+- Better IDE support and error catching
+
+## Design Patterns Used
+
+### 1. **Repository Pattern**
+- Abstracts data access logic
+- Provides a consistent interface for data operations
+- Enables easy testing with mock repositories
+
+### 2. **Service Layer Pattern**
+- Encapsulates business logic
+- Provides a clear API for the presentation layer
+- Handles transaction boundaries
+
+### 3. **Factory Pattern** 
+- Application factory (`create_app()`) for Flask initialization
+- Centralized configuration and setup
+
+### 4. **Blueprint Pattern**
+- Modular route organization
+- Clean URL structure
+- Easy feature separation
+
+## Database Schema
+- **users**: User authentication and profile data
+- **transactions**: Financial transactions with type support
+- **budgets**: Budget allocations with period management
+- **categories**: User-defined spending categories
+
+## Running the Refactored Application
+
+```bash
+# Run the refactored version
+python run_refactored.py
+
+# Or run the original version for comparison
+python app.py
+```
+
+## Migration Path
+Both versions (original and refactored) work with the same database schema, allowing for seamless transition and comparison.
+
+## Future Enhancements
+With this architecture, the following can be easily added:
+- Dependency injection container
+- Async support
+- Message queues for background processing
+- Multiple database support
+- API versioning
+- Caching layer
+- Event-driven architecture

README.md

@@ -29,6 +29,10 @@ This Flask-based web application serves as a comprehensive finance tracker, enab
 ![Transaction_page](screenshots/transactions.png)
 #### Add Transaction Popup
 ![Add Transaction Popup](screenshots/add_transaction.png)
+#### Budgets_page
+![Budget_page](screenshots/budget.png)
+#### Add Budget Popup
+![Add Budget Popup](screenshots/add_budget.png)
 #### Statistics page
 ![Statistics page](screenshots/statistics.png)
 
@@ -55,20 +59,53 @@ This Flask-based web application serves as a comprehensive finance tracker, enab
    pip install -r requirements.txt
    ```
 
-## Usage
+## How to Run
 
-1. Initialize the SQLite database:
+### Prerequisites
+- Python 3.8 or higher
+- pip (Python package installer)
 
+### Quick Start
+
+1. **Clone the repository:**
    ```bash
-   python app.py
+   git clone https://github.com/0xramm/Finance-Tracker.git
+   cd Finance-Tracker
    ```
 
-2. Open the application in your web browser:
+2. **Install dependencies:**
+   ```bash
+   pip install -r requirements.txt
+   ```
 
+3. **Run the application:**
+
+   **Option A: Refactored Version (Recommended)**
+   ```bash
+   python run_refactored.py
    ```
-   http://localhost:5000/
+
+   **Option B: Original Version**
+   ```bash
+   python app.py
    ```
 
+4. **Access the application:**
+   Open your web browser and go to: `http://localhost:5000`
+
+### First Time Setup
+1. Register a new account or use the existing demo data
+2. Start adding your income and expense transactions
+3. Create budgets to track your spending
+4. View analytics and statistics on your financial habits
+
+### Features Available
+- **User Authentication**: Secure login and registration
+- **Transaction Management**: Add income and expense transactions
+- **Budget Tracking**: Set and monitor spending limits
+- **Analytics Dashboard**: Visual insights and spending patterns
+- **Responsive Design**: Works on desktop and mobile devices
+
 ## Contributing
 
 Contributions are welcome! If you'd like to contribute to this project, please follow these steps: