samarth-p/college-erp

1. System shape

- This is a monolithic Django application called CollegeERP for college management.

- The repo contains one Django project package, CollegeERP, and two main apps: info and apis.

- Persistence is local via SQLite (db.sqlite3), so the architecture is classic Django MVC/MVT with server-rendered pages plus an API layer.

2. Primary user-facing subsystems

- The application is split around two roles: students and teachers, with an admin role handled by Django admin.

- The README and template names show the main business features are attendance, marks, timetable, and basic academic/user management.

3. Django project boundary

- CollegeERP/settings.py, urls.py, and wsgi.py define the global runtime configuration and request routing.

- CollegeERP/urls.py is the top-level dispatcher that likely mounts the info app routes and the admin site, and possibly the apis routes.

- manage.py is the standard entrypoint for local development and management commands.

4. Core business app: info

- info is the main application containing most domain logic, templates, static assets, and model migrations.

- Its templates show distinct screens for:

- login/logout and homepage

- student pages

- teacher pages

- attendance detail and editing

- marks entry/listing

- timetable views

- admin-facing pages

- This app is likely the center of the UI and workflow orchestration.

5. Domain model and data layer

- info/models.py plus many migrations indicate the data model is central and has evolved over time.

- Based on filenames and README, core entities likely include students, teachers, departments, courses, classes, attendance, marks, timetables, and attendance ranges.

- The database is managed through Django ORM; the admin page is used to create and edit these records.

6. Authentication and role-based access

- The README says the login page is common for students and teachers, with usernames based on names and a shared default password.

- This implies role-based behavior after login: the same authentication entrypoint routes users to different dashboards or views depending on whether they are a student or teacher.

- Django admin is a separate privileged access path for managing master data and operational records.

7. Teacher workflow

- Teacher-specific templates such as t_homepage.html, t_students.html, t_marks_entry.html, t_attendance.html, and t_timetable.html suggest teachers can:

- view assigned classes/students

- record or edit marks

- manage attendance

- inspect timetables

- generate reports or detail pages

- Teacher pages appear to be the operational side of the system where data is entered and updated.

8. Student workflow

- Student-facing templates such as homepage.html, attendance.html, marks_list.html, timetable.html, and att_detail.html suggest students can:

- view attendance status

- view marks

- see timetable and class-related information

- access summary/detail pages rather than edit data

- This is a read-oriented layer over the same underlying academic records.

9. Admin and maintenance workflow

- Django admin is used to maintain tables such as Students, Teachers, Departments, Courses, Classes, and related objects.

- There is a custom admin template under info/templates/admin/attendance/attendance_change_list.html, which matches the README’s note about resetting attendance time ranges.

- That reset feature indicates an admin-level maintenance workflow that can regenerate attendance records for a specified date range.

10. API subsystem

- The apis app contains serializers.py, views.py, and urls.py, which suggests a separate REST-style API layer, likely built with Django REST Framework or a similar serialization pattern.

- This layer probably exposes selected model data for programmatic access, distinct from the HTML template-driven UI in info.

- In the architecture diagram, this should be shown as a parallel interface into the same ORM/database, not a separate backend.

11. Presentation layer and static assets

- info/static contains Bootstrap-based assets and dashboard styling (sb-admin.css, JS demo charts, homepage styles).

- The UI is server-rendered via Django templates, with static assets providing layout, navigation, charts, and admin-like dashboard visuals.

- The many templates indicate page-specific rendering rather than a single-page frontend.

12. Request/data flow

- Browser request → Django URL routing → app views (info or apis) → ORM models → SQLite database.

- For HTML pages, views render templates with model data.

- For API endpoints, views likely return serialized data instead of HTML.

- Django admin bypasses most custom UI and directly manages models through the admin framework.

13. Operational characteristics

- The app is designed for local or small-deployment use: single Django process, embedded SQLite database, and static asset serving from the project tree.

- requirements.txt and the README’s runserver instructions reinforce that this is a straightforward Django deployment, not a distributed system.

14. Documentation and legacy artifacts

- The included PDFs (DBMS report.pdf, SE report final.pdf) are supporting documentation, not part of runtime architecture.

- The repo’s many migrations show the schema has accumulated features over time, especially around attendance and teacher/user relationships.

15. What to show in an architecture diagram

- Put Django project shell at the top.

- Show three external entry points: browser users (students/teachers), Django admin, and API clients.

- Under that, show the info app as the main business/UI layer, apis app as the programmatic access layer, and the SQLite database as the shared persistence layer.

- Include static assets/templates as the presentation resources attached to info, since that app owns most of the rendered pages.