Skip to content

Deliverable 2

Jump to bottom
Samuel Serna Patiño edited this page Oct 14, 2026 · 10 revisions

Deliverable 2: Solution Design + Functionality Preview

Sprint 2

This page shows the project as it was delivered at the end of Sprint 2. Corrections made after the instructor's feedback on this deliverable are documented in Deliverable 3.

Index

1. Architecture & Data

1.1 Deployment Diagram

Deployment Diagram The deployment diagram shows two main types of devices: the client (on the left) and the server (in the center), where the application runs.

The client device is the access point from which users connect to the application. Since it is a web application, users can access it from computers and mobile devices. Each type of device is represented as an independent node, and each operating system has a web browser installed, which allows access to the application.

The server device, named PythonAnywhere Server, hosts the application. Since it will be deployed on PythonAnywhere, the operating system is specified as Linux. The elements that must be installed on the server are also listed: the programming language, the package manager, the version control system, and the project's components — the web framework and the required libraries (Pillow, django-storages, boto3, whitenoise, python-dotenv).

The diagram also includes the project's apps, which correspond to the application's modules: accounts, materials, and tutoring. It also indicates the file that contains the list of project dependencies (requirements.txt).

Finally, the database used is specified — SQLite3 — along with the tables that will be created in the web application, grouped by the app that owns them: University, Program, and User (accounts); Course and Material (materials); Subject, TutorProfile, and TutoringRequest (tutoring).

The Cloudflare R2 device is represented without internal details, as it is only used conditionally in production when the corresponding credentials are configured; in local development, uploaded files are stored on the local filesystem instead.

⚠️ FALTANTE (corrección del docente — SEB-5): el diagrama no incluye la versión de cada tecnología en sus nodos, que la plantilla pide expresamente. Se corrige ahora → va en Deliverable 3.

1.2 Component Diagram

General architecture

StudyBank is a self-contained web application composed of three main functional modules:

  • User and account management.
  • Study material management.
  • Tutoring management. Users access the system through a web browser. Requests are processed by Django, which communicates with the application models and database before returning an HTML response.

The current application does not expose or consume an external public API.

flowchart LR
    U[University Student] --> B[Web Browser]
 
    B -->|HTTP / HTTPS| D[Django Application]
 
    subgraph Django Application
        URL[URL Router]
        V[Views]
        T[Templates]
        M[Models]
        A[Authentication and Authorization]
        S[Static and Media Configuration]
    end
 
    D --> URL
    URL --> V
    V --> M
    V --> T
    V --> A
    T --> B
 
    M --> DB[(SQLite Database)]
 
    S --> W[WhiteNoise Static Files]
    S --> L[Local Media Storage]
    S -. Production configuration .-> R[Cloudflare R2 Storage]
Loading

Component diagram

Component Diagram The diagram shows three components: **accounts**, **materials**, and **tutoring**, along with their connections. The **accounts** component contains the functions:

  • Register a new account using an institutional email (register).

  • Log in with an institutional email and password (login).

  • Edit profile data — university, program, and profile picture (edit_profile).

  • Log out of the current session (logout). The materials component contains the functions:

  • Upload a study material, associating it with a course, university, and file type (upload).

  • List all available study materials (material_list).

  • View the details of a selected material (material_detail).

  • Download a material (download_material). The tutoring component contains the functions:

  • Register as a tutor, indicating the subjects offered (register_tutor).

  • Search for approved tutors by subject (tutor_search).

  • Request a tutoring session from a tutor, specifying date, time, and mode (request_tutoring).

  • View the student's own tutoring requests and their status (my_tutoring_requests).

  • View the tutoring requests received by a tutor (incoming_tutoring_requests).

  • Accept a pending tutoring request (accept_tutoring_request).

  • Reject a pending tutoring request (reject_tutoring_request). Additionally, the diagram shows that both materials and tutoring depend on the login function of accounts: every function in these two components is restricted to authenticated users, so none of them can be executed without a valid session. This dependency is represented with dashed lines directed to the login interface.

Finally, all the functionalities represented in this diagram are explicitly available on the web application through buttons, menus, or other navigation options.

1.3 Data Model

This model describes the main entities of StudyBank and the relationships between them, as of Sprint 2.

Entity-Relationship Diagram

erDiagram
    UNIVERSITY ||--o{ PROGRAM : "offers"
    UNIVERSITY ||--o{ USER : "attended by"
    PROGRAM ||--o{ USER : "enrolled in"

    UNIVERSITY ||--o{ MATERIAL : "associated with"
    COURSE ||--o{ MATERIAL : "categorizes"
    USER ||--o{ MATERIAL : "uploads"

    USER ||--o| TUTORPROFILE : "has"
    TUTORPROFILE }o--o{ SUBJECT : "offers"

    USER ||--o{ TUTORINGREQUEST : "requests as student"
    TUTORPROFILE ||--o{ TUTORINGREQUEST : "receives as tutor"
    SUBJECT ||--o{ TUTORINGREQUEST : "requested for"

    UNIVERSITY {
        int id PK
        string name
    }

    PROGRAM {
        int id PK
        string name
        int university_id FK
    }

    USER {
        int id PK
        string email
        string password
        int university_id FK
        int program_id FK
        image profile_picture
    }

    COURSE {
        int id PK
        string name
    }

    MATERIAL {
        int id PK
        string title
        text description
        int uploaded_by_id FK
        int course_id FK
        int university_id FK
        string file_type
        file file
        datetime uploaded_at
    }

    SUBJECT {
        int id PK
        string name
    }

    TUTORPROFILE {
        int id PK
        int user_id FK
        boolean is_approved
    }

    TUTORINGREQUEST {
        int id PK
        int student_id FK
        int tutor_id FK
        int subject_id FK
        datetime scheduled_at
        string mode
        text message
        string status
        datetime created_at
        datetime updated_at
    }
Loading

Entity Descriptions

University

University represents an institution available in StudyBank.

A university may:

  • Offer multiple academic programs.

  • Be associated with multiple users.

  • Be associated with multiple study materials. Main attribute:

  • name: unique name of the university.

Program

Program represents an academic program or major offered by a university.

Each program belongs to one university, while one university may offer multiple programs.

Main attributes:

  • name: name of the academic program.
  • university_id: foreign key referencing University.
User

User represents a registered person on the platform.

StudyBank uses the institutional email as the authentication identifier instead of a username.

A user may:

  • Belong to a university.

  • Belong to an academic program.

  • Upload study materials.

  • Have one tutor profile.

  • Submit tutoring requests as a student.

  • Use a profile picture. Main attributes:

  • email: unique institutional email ending in @eafit.edu.co.

  • password: securely hashed user password.

  • university_id: optional foreign key referencing University.

  • program_id: optional foreign key referencing Program.

  • profile_picture: optional user profile image. The current implementation allows university and program to remain empty when a user account is created.

Course

Course represents a course associated with study materials.

Examples include:

  • Calculus I.
  • Databases.
  • Operating Systems.
  • Artificial Intelligence. A course may be associated with multiple materials.

Main attribute:

  • name: course name.
Material

Material represents a study resource uploaded by a user.

Examples include:

  • Notes.

  • Exams.

  • Summaries.

  • Lab reports.

  • Documents or images used as academic support. A material belongs to:

  • One uploader.

  • One course.

  • One university. Main attributes:

  • title: material title.

  • description: explanation of the material.

  • uploaded_by_id: foreign key referencing User.

  • course_id: foreign key referencing Course.

  • university_id: foreign key referencing University.

  • file_type: fixed material classification.

  • file: uploaded resource.

  • uploaded_at: upload date and time.

Subject

Subject represents a subject that a tutor can offer.

Examples include:

  • Calculus.
  • Programming.
  • Physics.
  • Databases.
  • Algorithms.
  • Operating Systems.
  • Artificial Intelligence. A subject may be offered by multiple tutors, and a tutor may offer multiple subjects.

Main attribute:

  • name: unique subject name. Subjects are maintained as a fixed catalog through the Django administration panel.
TutorProfile

TutorProfile extends a registered user with tutoring capabilities.

Each tutor profile:

  • Belongs to exactly one user.

  • May offer one or more subjects.

  • Contains an approval status.

  • Is hidden from tutor searches until approved.

  • May receive multiple tutoring requests. Main attributes:

  • user_id: one-to-one reference to User.

  • is_approved: indicates whether the tutor has been approved by an administrator. The relationship between TutorProfile and Subject is many-to-many.

TutoringRequest

TutoringRequest represents a session request sent by a student to a tutor for a specific subject.

A tutoring request belongs to:

  • One student (the user who submitted it).

  • One tutor (the TutorProfile who receives it).

  • One subject. Main attributes:

  • student_id: foreign key referencing User.

  • tutor_id: foreign key referencing TutorProfile.

  • subject_id: foreign key referencing Subject (on_delete=PROTECT, so a subject cannot be deleted while tutoring requests reference it).

  • scheduled_at: the requested date and time for the session.

  • mode: session mode, either in_person or virtual.

  • message: optional note from the student to the tutor.

  • status: request status — pending (default), accepted, or rejected.

  • created_at / updated_at: timestamps for auditing.

Relationships Summary

Source entity Relationship Target entity Description
University One-to-many Program A university may offer multiple programs.
University One-to-many User Multiple users may belong to one university.
Program One-to-many User Multiple users may belong to one program.
User One-to-many Material A user may upload multiple materials.
University One-to-many Material Multiple materials may belong to one university.
Course One-to-many Material Multiple materials may belong to one course.
User One-to-one TutorProfile A user may have at most one tutor profile.
TutorProfile Many-to-many Subject Tutors may offer several subjects, and subjects may have several tutors.
User One-to-many TutoringRequest A user may submit multiple tutoring requests as a student.
TutorProfile One-to-many TutoringRequest A tutor may receive multiple tutoring requests.
Subject One-to-many TutoringRequest A subject may be referenced by multiple tutoring requests.

Course and Subject Separation

Course and Subject are currently maintained as separate catalogs:

  • Course is used by the study materials module.
  • Subject is used by the tutoring module. This separation was chosen to allow both modules to be developed independently.

A future refactor may unify both entities if the team determines that they represent the same academic concept.

Current Implementation Status

The following domain entities are currently implemented:

  • University
  • Program
  • User
  • Course
  • Material
  • Subject
  • TutorProfile
  • TutoringRequest Implementation status is tracked through GitHub Issues, Pull Requests, and the project board.

⚠️ FALTANTE (corrección del docente — GIS-3): la plantilla pide un modelo relacional (RDS). Lo entregado es un diagrama entidad-relación sin tipos de datos y sin la tabla intermedia de la relación muchos a muchos entre TutorProfile y Subject. Se corrige ahora en GenMyModel → va en Deliverable 3.

2. Mockups

⚠️ FALTANTE (corrección del docente): la plantilla pide mockups o wireframes de las vistas donde se reflejan los requisitos del Sprint 2, respondiendo What, Where y How. No se hicieron. Vistas que deben cubrirse:

Vista Requisito Responsable
Edit profile RF-03 Sebastián (SEB-6)
Search and filter materials RF-05, RF-06 Gisel (GIS-4)
Tutoring request RF-11 Samuel (SAM-3) — ✅ documented in Deliverable 3, section 7.2
Incoming requests (accept / reject) RF-12 Samuel (SAM-3) — ✅ documented in Deliverable 3, section 7.2

RF-21 (log out) es un botón del menú; basta con que aparezca en el navbar de cualquiera de los mockups. Se hacen ahora → van en Deliverable 3.

3. Repository

Library Version
Django 6.0.7
Pillow 12.3.0
django-storages 1.14.6
boto3 1.43.56
whitenoise 6.12.0
python-dotenv 1.2.2

Commits in Sprint 2 by team member (excluding merge commits):

Team member Commits Example
Sebastián Vásquez 4 feat: add profile editing form with name, university, program and picture
Gisel Jaramillo 3 Implementation RF-05 and RF-06: Keyword search and course filtering
Samuel Serna 3 feat: add tutoring request decision management

4. Video

  • https://youtu.be/SBLEIfDHuFg The video (approximately 6 minutes) recaps StudyBank's problem and solution, and presents the functional requirements completed during Sprint 2, with all three members appearing on camera. Sebastián opens and closes the video and summarizes Sprint 2's scope; Gisel recaps the problem and solution; Samuel introduces the team.

The video walks through the functional requirements completed in Sprint 2: RF-03 and RF-21 (accounts), RF-05 and RF-06 (study materials), and RF-11 and RF-12 (tutoring) — completing all 12 Must-have requirements from the original specification. It also includes a live demonstration of the full flow: editing a profile, searching and filtering materials, and requesting and responding to a tutoring session.

⚠️ FALTANTE (corrección del docente): el video no sigue la estructura de la plantilla, que pide 4 a 5 minutos en total (este dura aproximadamente 6):

Parte Duración Contenido
Pitch, presentado por un solo integrante 1 min Integrantes, nombre del proyecto, problema, solución, dónde están y a dónde quieren llegar
Requisitos del sprint 2 min Explicación de los requisitos, sin leerlos
Evidencia 2 min Demostración de que se cumplieron los requisitos planeados

Todos los integrantes deben aparecer. Se aplica en el video del Deliverable 3.

5. Project Management

5.1 Sprint 2 Requirements

Issue Requirement Responsible Pull Request Merged
#12 RF-11 — Request a tutoring session Samuel #55 31/08/2026
#13 RF-12 — Accept or reject a tutoring request Samuel #56 01/09/2026
#6 RF-05 — Search materials by keyword Gisel #59 01/09/2026
#41 RF-21 — Log out Sebastián #58 02/09/2026
#4 RF-03 — Edit profile Sebastián #57 02/09/2026
#7 RF-06 — Filter materials by subject Gisel No pull request (commits 9397baa, dd4c7c1) 02/09/2026

⚠️ FALTANTE (corrección del docente — SEB-4): la plantilla pide los requisitos con estado, sprint y responsable actualizados. Esa tabla no existía en el Sprint 2; se crea ahora en la página Requirements.

⚠️ FALTANTE (trazabilidad — GIS-2, SEB-3): RF-06 entró a main sin pull request.

5.2 Weekly Meetings

Weekly meetings for planning, resolving doubts, assigning issues to each team member, and reviewing progress.

🔄 CORRECCIÓN: Samuel (SAM-4) completed his individual Sprint 2 answers, including 03/09/2026, on Weekly Meetings. Sebastián and Gisel still need to complete their individual answers.

5.3 Retrospective

See Retrospectives — Sprint 2.

✅ CORREGIDO: Sprint 2 retrospective documented on Retrospectives.

5.4 Class Assignments

Component diagram sketch — 27/08/2026

Component diagram sketch Initial hand-drawn version of the component diagram, made in class. It was later refined into the UML diagram in [1.2 Component Diagram](#12-component-diagram).

6. Corrections to Deliverable 1

Corrections applied during Sprint 2 based on the instructor's feedback on Deliverable 1.

6.1 Product Perspective — Memory and Operations

These two literals were missing in Deliverable 1.

f) Memory

No unusual memory constraints apply. The system runs within the resource limits of the free-tier hosting environment used for deployment (PythonAnywhere).

g) Operations

StudyBank operates as a standard request-response web application. There are no background batch jobs, scheduled tasks, or long-running processes in the current scope.

6.2 Limitations

Restructured to follow literals a) to k) of the template.

a) Regulatory policies. Registration is restricted to institutional email addresses ending in @eafit.edu.co; the system does not currently support users from other institutions.

b) Hardware limitations. None beyond requiring a device capable of running a modern web browser with internet access.

c) Interfaces to other applications. The system depends on Cloudflare R2 for production file storage; if R2 is not configured, file storage falls back to the local filesystem, which is not suitable for a multi-server production deployment.

d) Parallel operation. Not applicable; the system does not run in parallel with a legacy system it replaces.

e) Audit functions. Not implemented in the current scope. Django's admin panel provides basic staff-only visibility into records, but no dedicated audit log exists yet.

f) Control functions. Access to protected actions (uploading material, registering as a tutor, requesting tutoring) is restricted to authenticated users through Django's authentication framework.

g) Signal handshake protocols. Not applicable; the system does not communicate with external hardware devices.

h) Quality requirements. See the Non-Functional Requirements section in Requirements Specification (usability, performance, security, browser compatibility).

i) Criticality of the application. StudyBank is an academic support tool; it does not process financial transactions or safety-critical data. Its failure would inconvenience users but does not pose a safety risk.

j) Safety and security considerations. Passwords are stored using Django's default password hashing (PBKDF2); access to protected resources is restricted to authenticated users; tutor profiles require administrative approval before appearing in search results.

k) Physical/mental considerations. Not applicable to the current scope of the product.

6.3 Functional Requirements

All requirements were unified under a single RF-01 to RF-33 numbering, traceable one-to-one to GitHub issues. This replaced the separate US-01 to US-34 numbering used in the Deliverable 1 prioritisation.

Accounts

ID Name Priority Description
RF-01 User registration Must THE system SHALL PROVIDE visitors WITH THE ABILITY TO register an account using a unique institutional email address ending in @eafit.edu.co.
RF-02 User login Must THE system SHALL PROVIDE registered users WITH THE ABILITY TO log in using their institutional email and password.
RF-03 User profile editing Must THE system SHALL PROVIDE authenticated users WITH THE ABILITY TO edit their profile data (university, program, and profile picture).
RF-21 Session logout Must As a registered user, I want to log out so that I can end my session securely.
RF-22 Password recovery Could As a registered user, I want to recover my password so that I can regain access if I forget it.
RF-23 Public user profile view Could As a registered user, I want to view another user's public profile so that I can learn more about them.

Study Materials

ID Name Priority Description
RF-04 Upload study material Must THE system SHALL PROVIDE registered users WITH THE ABILITY TO upload study material, associating it with a subject, a university, and a file type.
RF-05 Search study materials Must THE system SHALL PROVIDE registered users WITH THE ABILITY TO search for study materials using a keyword.
RF-06 Filter materials by subject Must THE system SHALL PROVIDE registered users WITH THE ABILITY TO filter materials by subject.
RF-07 View material details Must THE system SHALL PROVIDE registered users WITH THE ABILITY TO view the details of a selected material.
RF-08 Download material Must THE system SHALL PROVIDE registered users WITH THE ABILITY TO download a material.
RF-13 Rate material Should THE system SHOULD PROVIDE registered users WITH THE ABILITY TO rate a material on a 1 to 5-star scale after downloading it.
RF-14 Rank materials by rating Should THE system SHOULD PROVIDE registered users WITH THE ABILITY TO view materials sorted from highest to lowest rating.
RF-24 Edit uploaded material Could As a registered user, I want to edit a material I uploaded so that I can correct or update it.
RF-25 Delete uploaded material Could As a registered user, I want to delete a material I uploaded so that I can remove outdated content.
RF-26 Filter materials by university Could THE system SHOULD PROVIDE registered users WITH THE ABILITY TO filter study materials by university.
RF-29 Most-downloaded materials panel Could As a registered user, I want to see a panel of the most-downloaded materials so that I discover popular content.
RF-31 Report inappropriate material Won't As a registered user, I want to report inappropriate material so that the platform stays safe.
RF-33 Top-rated materials report Won't As a registered user, I want to see a report of the best-rated material per subject so that I quickly find top resources.

Tutoring

ID Name Priority Description
RF-09 Register as a tutor Must THE system SHALL PROVIDE registered users WITH THE ABILITY TO register as a tutor, indicating the subjects offered. A newly created tutor profile SHALL remain pending until approved by an administrator.
RF-10 Search tutors by subject Must THE system SHALL PROVIDE registered users WITH THE ABILITY TO search for tutors by subject. Only approved tutor profiles SHALL be displayed.
RF-11 Request tutoring session Must THE system SHALL PROVIDE students WITH THE ABILITY TO request a tutoring session from a tutor, specifying date, time, and mode (in-person or virtual).
RF-12 Accept/reject tutoring request Must THE system SHALL PROVIDE tutors WITH THE ABILITY TO accept or reject a received tutoring request.
RF-15 Tutor availability Should THE system SHOULD PROVIDE tutors WITH THE ABILITY TO configure their available schedules.
RF-16 Tutor public profile Should THE system SHOULD PROVIDE registered users WITH THE ABILITY TO view a tutor's profile along with their average rating.
RF-17 Rate tutoring session Should AFTER completing a tutoring session, THE system SHOULD PROVIDE students WITH THE ABILITY TO rate that session on a 1 to 5-star scale.
RF-18 Rank tutors by rating Should THE system SHOULD PROVIDE registered users WITH THE ABILITY TO view tutors sorted from highest to lowest rating.
RF-19 Notify tutor of new request Should AS SOON AS a student submits a tutoring request, THE system SHOULD notify the corresponding tutor.
RF-20 Notify student of decision Should AS SOON AS a tutor accepts or rejects a request, THE system SHOULD notify the requesting student.
RF-27 View tutoring request status Could As a student, I want to view the status of my tutoring requests so that I know if they were accepted.
RF-28 Cancel tutoring session Could As a student, I want to cancel a tutoring session so that I can free up the tutor's time if my plans change.
RF-30 Tutor activity statistics Could As a tutor, I want to view my tutoring statistics so that I can track my activity.
RF-32 Most-searched trends dashboard Won't As an administrator, I want to see a panel of the most-searched subjects/universities so that I understand platform trends.

6.4 Requirements Prioritisation (MoSCoW)

Log out (RF-21) was moved from Could have to Must have, since it is a security prerequisite for any authenticated session.

Priority Requirements
Must have RF-01, RF-02, RF-03, RF-04, RF-05, RF-06, RF-07, RF-08, RF-09, RF-10, RF-11, RF-12, RF-21
Should have RF-13, RF-14, RF-15, RF-16, RF-17, RF-18, RF-19, RF-20
Could have RF-22, RF-23, RF-24, RF-25, RF-26, RF-27, RF-28, RF-29, RF-30
Won't have (this time) RF-31, RF-32, RF-33

6.5 Non-Functional Requirements

ID Name Priority Description
RNF-01 Intuitive user interface Must THE system SHALL provide an intuitive and user-friendly user interface.
RNF-02 Responsive design Must THE system SHALL feature a responsive design that adapts seamlessly to mobile devices.
RNF-03 Fast page loading Must THE system SHALL ensure fast page loading times under normal operating conditions.
RNF-04 Secure password storage Must THE system SHALL store all user passwords securely using strong encryption standard protocols (Django's PBKDF2 hashing). Passwords SHALL NOT be stored as plain text.
RNF-05 Restricted access Must THE system SHALL restrict access to protected resources exclusively to authenticated users, including uploading materials, registering as a tutor, and searching for tutors.
RNF-06 Browser compatibility Must THE system SHALL be compatible with major web browsers, including Google Chrome, Mozilla Firefox, Microsoft Edge, and Safari.

✅ CORREGIDO (SAM-1): the current Requirements page uses objective non-functional requirements and includes a verification criterion for each RNF.

6.6 Product Vision Board

The "nationwide coverage" business goal contradicted the @eafit.edu.co registration restriction. It was changed to EAFIT-wide coverage, and the references to study groups (which had no supporting requirement) were removed.

Vision
To simplify university life and academic workload by developing an accessible platform for all EAFIT students—promoting learning, diversity in teaching, and collaborative work, while helping students achieve better grades, improve study habits, and reduce academic stress.
Target Group Needs Product Business Goals
University students who need academic material or tutors to study for their exams or who wish to share their knowledge or notes on certain topics with others.
  • Insufficient study materials
  • Inefficient explanations of topics
  • Stress due to academic workload
  • Lack of university support with tutoring
  • Study bank containing course-specific university notes, as well as tutoring options.
  • Rating system for notes and tutors based on user reviews, ranked from highest to lowest.
  • Scheduling feature to book in-person or virtual tutoring sessions and check tutor availability.
  • Tutor registration allowing interested students to offer their tutoring services.
  • EAFIT-Wide Coverage and Scale: Become the leading collaborative university repository with the highest number of active class notes and registered tutors across all faculties at EAFIT.
  • Democratization of knowledge: Provide equitable access to high-quality study materials for all EAFIT students, regardless of their major or semester.
  • Search and scheduling efficiency: Reduce the time needed to find relevant study notes or confirm a tutoring session to under 2 minutes.
---

Annex — Architecture details

Additional architecture documentation as delivered in Sprint 2.

⚠️ FALTANTE: las secciones A.2 (módulos) y A.12 (estado de la arquitectura) quedaron desactualizadas al entregar: describen las solicitudes de tutoría y la gestión completa de materiales como planeadas, cuando RF-03, RF-05, RF-06, RF-11 y RF-12 ya estaban implementados. La versión actualizada va en Deliverable 3.

A.1 Model-View-Template Pattern

StudyBank follows Django's Model-View-Template pattern.

Model

Models represent the data and business entities of the application.

Examples include:

  • University

  • Program

  • User

  • Subject

  • TutorProfile Models define:

  • Database fields.

  • Relationships between entities.

  • Data constraints.

  • Representation of persisted information.

View

Views receive HTTP requests, execute the required application logic, interact with models, and select the response to return.

Examples of current tutoring views include:

  • Tutor registration.
  • Tutor search by subject. Views also enforce access restrictions through Django authentication decorators such as login_required.

Template

Templates define the HTML presented to users.

The project uses a shared base template that provides:

  • Navigation bar.
  • Footer.
  • Shared styles.
  • Page title blocks.
  • Reusable layout structure. Specific templates extend the shared base template.

Examples include:

  • Home page.
  • User registration page.
  • Tutor registration page.
  • Tutor search page.

A.2 Application Modules

Accounts Module

The accounts module is responsible for:

  • Institutional user registration.
  • Custom user authentication.
  • Universities.
  • Academic programs.
  • User profile information.
  • Profile pictures. The custom User model uses the institutional email address as the login identifier instead of a username.

Materials Module

The materials module is intended to support:

  • Uploading study materials.
  • Searching materials.
  • Filtering materials.
  • Viewing material details.
  • Downloading materials.
  • Rating and ranking materials. Some capabilities may remain under development depending on the current sprint scope.

Tutoring Module

The tutoring module currently supports:

  • A fixed catalog of subjects.

  • Tutor profile registration.

  • Selection of one or more subjects.

  • Administrative tutor approval.

  • Searching approved tutors by subject. Planned tutoring capabilities include:

  • Tutor availability.

  • Tutor profile details.

  • Tutoring requests.

  • Accepting or rejecting requests.

  • Session ratings.

  • Notifications.

A.3 Request-Response Flow

The following diagram represents the standard request flow in StudyBank:

sequenceDiagram
    actor User
    participant Browser
    participant URLRouter as Django URL Router
    participant View as Django View
    participant Model as Django Model
    participant Database
    participant Template
 
    User->>Browser: Selects an action
    Browser->>URLRouter: Sends HTTP request
    URLRouter->>View: Resolves URL
    View->>Model: Executes application logic
    Model->>Database: Reads or writes data
    Database-->>Model: Returns data
    Model-->>View: Returns model objects
    View->>Template: Sends context data
    Template-->>Browser: Returns rendered HTML
    Browser-->>User: Displays the page
Loading

A.4 Tutor Registration Flow

sequenceDiagram
    actor User
    participant Browser
    participant View as register_tutor View
    participant Form as TutorRegistrationForm
    participant TutorProfile
    participant Database
 
    User->>Browser: Opens tutor registration
    Browser->>View: GET /tutoring/register/
    View->>Form: Creates empty form
    Form-->>Browser: Displays available subjects
 
    User->>Browser: Selects subjects and submits
    Browser->>View: POST selected subjects
    View->>Form: Validates submitted data
 
    alt Form is valid
        Form->>TutorProfile: Creates tutor profile
        TutorProfile->>Database: Saves user and subjects
        Database-->>View: Tutor profile created
        View-->>Browser: Redirects to Home
    else Form is invalid
        View-->>Browser: Displays validation errors
    end
Loading

A tutor profile is created with is_approved = False. An administrator must approve it before the tutor appears in search results.

A.5 Tutor Search Flow

sequenceDiagram
    actor User
    participant Browser
    participant View as tutor_search View
    participant TutorProfile
    participant Database
 
    User->>Browser: Opens tutor search
    Browser->>View: GET /tutoring/search/
    View->>Database: Requests approved tutors
    Database-->>View: Returns approved tutor profiles
    View-->>Browser: Displays tutors
 
    User->>Browser: Selects a subject
    Browser->>View: GET with subject parameter
    View->>Database: Filters approved tutors by subject
    Database-->>View: Returns matching tutors
    View-->>Browser: Displays filtered results
Loading

Only tutor profiles with is_approved = True are included in the results.

A.6 Data Storage

Relational Database

StudyBank currently uses SQLite as its relational database engine.

SQLite stores:

  • User accounts.
  • Universities.
  • Academic programs.
  • Tutor profiles.
  • Subjects.
  • Relationships between tutors and subjects.
  • Other application records as modules are implemented. SQLite is appropriate for local development and the current academic project stage.

Static Files

Static files include:

  • CSS.
  • JavaScript.
  • Interface images.
  • Django administration assets. WhiteNoise is used to serve static assets directly from the Django application.

The main visual design is stored in:

static/css/styles.css

Media Files

Media files include:

  • User profile pictures.
  • Uploaded study materials. During local development, media files may be stored in the local filesystem.

For production, the project is prepared to use Cloudflare R2 through an S3-compatible storage interface when the required credentials are configured.

A.7 External Software Components

StudyBank depends on the following software components:

Component Purpose
Python Main programming language
Django Web framework
SQLite Relational database
WhiteNoise Static file serving
Pillow Image processing support
django-storages External storage integration
boto3 S3-compatible storage communication
Cloudflare R2 Optional production media storage
GitHub Source control, issues, pull requests, Wiki and project board

A.8 Environment Configuration

StudyBank uses environment variables to separate configuration from source code.

Important variables include:

SECRET_KEY
DEBUG
ALLOWED_HOSTS

Optional production storage variables include Cloudflare R2 credentials and bucket configuration.

This approach allows the same source code to be used across local and production environments without placing sensitive information directly in the repository.

An example configuration file is provided through:

.env.example

Actual .env files and secret values must not be committed to GitHub.

A.9 Deployment Environments

Local Development

The local environment uses:

  • Python virtual environment.
  • Django development server.
  • SQLite database.
  • Local media storage.
  • Environment variables for local configuration. The local server is started with:
python manage.py runserver

It is accessed through:

http://127.0.0.1:8000/

The Django development server is used only for development and testing.

Production

A production environment is expected to use:

  • HTTPS.
  • DEBUG=False.
  • A secure SECRET_KEY.
  • Explicitly configured allowed hosts.
  • Persistent media storage.
  • Cloudflare R2 when configured.
  • A production-compatible WSGI or ASGI server. The specific production deployment platform must be documented once the final deployment environment is confirmed.

A.10 Security Architecture

StudyBank applies the following security controls:

  • Password hashing through Django authentication.
  • Institutional email validation.
  • Unique email addresses.
  • Authentication-required views.
  • Django CSRF protection in forms.
  • Environment variables for secret configuration.
  • Tutor approval before public appearance in searches.
  • Restricted Django administration access.
  • Separation of development and production settings. Passwords are never stored as plain text.

A.11 Interface Design

The user interface follows a shared design system:

  • Dark visual theme.
  • Amber accent colors.
  • Fraunces font for headings.
  • Inter font for regular interface text.
  • Shared navigation bar.
  • Shared footer.
  • Reusable buttons and cards.
  • Responsive layouts. The base interface structure is defined in:
templates/base.html

All main application pages should extend this shared template to maintain consistent navigation and presentation.

A.12 Architecture Status

The following components are currently implemented:

  • Django project configuration.

  • Custom user model.

  • Institutional email validation.

  • User registration.

  • Shared navigation and visual design.

  • University and program entities.

  • Tutor registration.

  • Subject selection.

  • Administrative tutor approval.

  • Tutor search by subject.

  • Django administration integration. The following components remain planned or under development:

  • Complete material management.

  • Material ratings and rankings.

  • Tutor availability.

  • Tutor profile details.

  • Tutoring requests.

  • Request acceptance and rejection.

  • Notifications.

  • Tutoring session ratings.

  • Final production deployment. Architecture and implementation status are tracked through GitHub Issues, Pull Requests, and the project board.

Clone this wiki locally