ADVANCED OOP — R&D PROJECT PROPOSAL INTERACTIVE QUIZ ENGINE

Advanced OOP with Python

Python + Flask + MySQL

Project Proposal

Interactive Quiz Engine

1. Abstract / Summary

This research and development project proposal presents the design, architecture, and implementation strategy for the Interactive Quiz Engine, a web-based educational assessment platform built with Python, Flask, and MySQL. Educational institutions frequently suffer from feedback delays caused by manual test grading, non-reusable assessment materials, and fragmented student tracking across spreadsheets and paper records. The Interactive Quiz Engine directly addresses these inefficiencies by introducing a multi-format quiz creation tool, automated evaluation pipelines for objective question types, and centralized attempt history tracking.

By leveraging core Object-Oriented Programming (OOP) principles—specifically polymorphism, encapsulation, and layered repository design—the engine cleanly separates core business logic (e.g., dynamic answer evaluation) from data persistence and interface routing. The software enables educators to author quizzes containing Multiple Choice (MCQ), True/False, and Short Answer questions within minutes, while providing students with instant score feedback upon submission. Expected project outcomes include a operational 5-layered Flask/MySQL web application, complete automated test suites, dynamic class performance reporting, and comprehensive architectural documentation suitable for academic defense.

2. Problem Statement

Traditional educational assessment workflows in secondary and higher education environments rely heavily on manual paper-based examinations, static word processors, or disconnected spreadsheet templates. This operational model gives rise to three critical structural challenges:

·        Manual and Time-Consuming Grading: Teachers hand-grade multiple-choice, true/false, and short-answer items on physical paper or in disconnected Excel sheets, delaying crucial feedback to students by days or even weeks.

·        Absence of Reusable Question Repositories: Assessments are constructed from scratch each academic term rather than being organized within a shared, search-enabled repository of categorized questions.

·        Fragmented Student Tracking: Student evaluation history is fragmented across paper logs, local files, and ad-hoc submission forms, preventing educators from maintaining a holistic view of student progress over time.

Observed Evidence

In our academic institution and local coursework environments, instructors routinely rely on physical paper tests, basic Google Forms, or Microsoft Word documents to distribute quizzes. None of these existing tools seamlessly combine diverse question formats, instant objective auto-grading, manual grading queues for open-ended questions, and centralized historical analytics within a unified system. As a direct consequence, student feedback loops remain drastically delayed, and instructor administrative workloads are unnecessarily inflated.

Impacted Stakeholders

The primary stakeholders suffering from this problem are educators—who require a rapid, automated method to author, deploy, and evaluate assessments—and students, who need immediate diagnostic feedback on their comprehension rather than waiting days for paper return.

3. Project Objectives

General Objective

To research, design, and develop a robust, open-source web application for interactive quiz creation, taking, auto-grading, and performance tracking using Python, Flask, and MySQL based on strict Object-Oriented Programming (OOP) and layered architecture principles.

Specific Measurable Objectives

·        Objective 1: Rapid Quiz Creation — Enable instructors to build complete, multi-format quizzes (MCQ, True/False, Short Answer) in under 10 minutes.

·        Objective 2: Zero-Latency Auto-Grading — Automate the evaluation of MCQ and True/False questions instantly upon submission, achieving a 0-manual-step evaluation flow for objective items.

·        Objective 3: Instant Student Feedback — Provide students with immediate score reports and question breakdown upon quiz submission.

·        Objective 4: Centralized Attempt Tracking — Deliver a centralized evaluation and analytics view for teachers to review attempt records, inspect detailed responses, and manually mark short answers.

·        Objective 5: Extensible Architecture — Implement an extensible system architecture following OOP polymorphism and repository patterns to support seamless future question-type expansions.

4. Research & Development Questions

To guide the architectural design, implementation, and evaluation of the Interactive Quiz Engine, the project addresses the following engineering questions:

·        RQ1 (Software Architecture): How can Object-Oriented Polymorphism be structured in Python to allow unified quiz scoring without conditional type checking ('if/else' branching) across heterogeneous question types?

·        RQ2 (Design Pattern): How should a multi-layered Flask architecture (Routes -> Services -> Repositories -> Database) be implemented to ensure total separation between business evaluation logic and SQL database persistence?

·        RQ3 (Database Optimization): What database schema design best balances normalized structure for questions/choices with efficient retrieval of historical attempt records and instant auto-grading execution?

·        RQ4 (Workflow Integration): How can manual short-answer review queues be integrated alongside automated objective grading pipelines without degrading user experience or data integrity?

5. Scope and Limitations

6. Target Users and Stakeholders

The platform caters to three user primary roles governed by strict Role-Based Access Control (RBAC):

·        1. System Administrator: System administrators responsible for creating teacher and student accounts, managing user profiles, assigning institutional roles, and maintaining global configuration.

·        2. Teacher / Instructor: Primary content authors who build custom quizzes, maintain reusable question banks, establish scoring criteria, monitor live student attempts, and manually evaluate short-answer submissions.

·        3. Student: End-users who log in to view assigned assessments, execute timed quiz attempts, submit answers, and instantly review scored results and attempt feedback.

7. Proposed System Features

System capabilities are prioritized using the MoSCoW framework to ensure core stability:

8. Object-Oriented Programming (OOP) Design Plan

The core architectural strength of the Interactive Quiz Engine lies in its clean Object-Oriented design, strictly adhering to polymorphism, encapsulation, and single responsibility principles.

Core Domain Classes & Hierarchy

·        User (Base) -> Admin, Teacher, Student: Base domain class handling core credentials and authorization logic. Subclasses (Admin, Teacher, Student) expose specific privilege boundaries.

·        Quiz: Aggregate entity holding metadata (title, time limit) and maintaining an ordered composition of Question objects.

·        Question (Abstract Base): Abstract base class enforcing the contract method grade(answer). Specialized concrete classes implement custom grading rules:

·          • MCQQuestion: Compares selected choice ID against correct Choice entities.

·          • TrueFalseQuestion: Evaluates boolean matching logic.

·          • ShortAnswerQuestion: Applies exact/keyword string matching or flags for manual review queue.

·        Choice: Represents one selectable option belonging to an MCQ Question.

·        Attempt & Answer: Represents a student's submission run, aggregating a collection of Answer domain objects and computed total score.

Polymorphic Evaluation Pipeline

9. System Architecture

The application strictly implements a 5-Layered Architecture to maintain loose coupling and high cohesion across components:

·        1. Presentation Layer (Browser UI): HTML5, CSS3, JavaScript rendering dynamic web forms, timed execution containers, and instant result views.

·        2. Web / Controller Layer (Flask Routes): Flask Blueprints (auth, quiz, attempt) receiving HTTP requests, validating input formats, and rendering response templates.

·        3. Service Layer (Business Logic): QuizService, AttemptService, and ScoringService encapsulating business workflows and grading rules.

·        4. Repository Layer (Data Access): QuizRepository, QuestionRepository, and AttemptRepository isolating all raw SQL operations from upper layers.

·        5. Database Layer (MySQL): Relational MySQL database storing normalized domain entities with full relational integrity constraints.

Strict Architectural Layering Rule

Routes ONLY communicate with Services. Services handle pure business logic and invoke Repositories. Repositories are the sole components executing SQL queries against MySQL. Zero SQL code or grading logic is permitted inside app.py or route handlers.

Example Execution Sequence Flow (Quiz Submission)

·        Step 1: Student clicks 'Submit Quiz', dispatching an HTTP POST payload containing response data to the attempt route.

·        Step 2: The `attempt` route extracts session context and forwards payload to `AttemptService.submit_attempt()`.

·        Step 3: `AttemptService` instantiates an `Attempt` entity and passes it to `ScoringService`.

·        Step 4: `ScoringService` iterates through responses, polymorphically invoking `.grade()` on each derived `Question` instance.

·        Step 5: `AttemptRepository` executes parameterized SQL queries to persist the scored Attempt and Answers in MySQL.

·        Step 6: Flask route renders the final result summary page back to the student browser.

10. Database Plan & Schema Design

The MySQL database schema is structured to ensure high performance, third-normal-form (3NF) relational compliance, and strict foreign key integrity.

Security & Seeding Strategy

·        Security Integrity: User passwords are strictly hashed using Werkzeug/Bcrypt cryptographic salts. No plaintext passwords are stored.

·        SQL Injection Safeguards: All repository methods enforce prepared, parameterized SQL statements to immune the application against SQL injection attacks.

·        Database Seeding: Automated seed scripts populate initial admin/teacher/student profiles, sample quizzes covering all question types, and dummy submission records for validation.

11. Methodology and Timeline

The project follows an Agile development methodology structured over a 12-week timeline. Execution responsibilities are evenly split across the two-person engineering team (Hay Ravanmonyvan & Lim Sak).

12. Expected Results & Verification

The final deliverable outputs and their corresponding verification evidence are outlined below:

·        1. Operational Software: A fully functional web application hosting quiz authoring, taking, instant auto-grading, and RBAC portals.

·        2. Verification Test Suite: Minimum of 10 comprehensive unit/integration test cases covering polymorphic scoring logic, role access checks, and repository data persistence.

·        3. Comprehensive Documentation: Complete architectural documentation, schema definition files, and defense presentation deck.

·        4. Live Project Demonstration: An end-to-end live demonstration demonstrating an instructor building a quiz, a student taking it, and instant auto-grading rendering results on screen.

13. Risk Management and Ethics

Project Risk Matrix & Mitigation

·        Resource Constraint (Small Team): A 2-person team has constrained bandwidth. Mitigation: Lock core 'Must-Have' scope early and prune 'Nice-to-Have' features if milestones stall.

·        Evaluation Subjectivity: Keyword matching for short answers can yield false negatives. Mitigation: Route text responses to a teacher review queue rather than forcing unreliable full automation.

·        Timeline Squeeze: Rushed testing near project completion leads to system defects. Mitigation: Write automated unit tests concurrently alongside each feature module.

Ethics & Data Privacy Considerations

·        Data Privacy & Security: All user passwords must be hashed using industry-standard salted algorithms (Bcrypt/Werkzeug). Student quiz records and grades are restricted strictly to authorized teachers and administrators.

·        Academic Integrity: The project adheres strictly to academic integrity standards; all architectural design patterns, external code libraries, and references are fully cited.

14. References

•  Flask Documentation (v3.0.x). Web Development One Drop at a Time. Pallets Projects. https://flask.palletsprojects.com
• MySQL 8.0 Reference Manual. Relational Database Management System. Oracle Corporation. https://dev.mysql.com/doc/
• Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
• Martin, R. C. (2017). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall.
• Werkzeug Security Documentation. Password Hashing Utilities. Pallets Projects. https://werkzeug.palletsprojects.com/en/stable/utils/#module-werkzeug.security