How aliakbar007/attendance-system-sih25012 works
1. This is a small, self-contained desktop attendance application, not a client-server system. The architecture is centered on a local GUI, local face/identity data, and file-based persistence.
2. main_gui_ctk.py is the primary application entry point and user-facing layer. Based on the name and the problem domain, it is the teacher/operator interface for starting attendance capture, viewing results, and interacting with the system.
3. util.py is the shared logic layer. It is the most likely place for attendance rules, face matching or identity lookup, file read/write helpers, and any non-UI processing used by the GUI.
4. The db/ directory holds serialized application state in pickle files (hom.pickle, oniq.pickle). These appear to be the persisted identity/recognition data used by the app at runtime, likely representing enrolled users or face feature data.
5. Attendance output is stored in flat files rather than a database:
- log.csv looks like the main attendance/event log.
- logged_in.csv appears to track already-processed or currently present identities to avoid duplicate entries.
This means the system relies on filesystem state as its primary persistence boundary.
6. The typical data flow is: user opens the GUI → the app invokes utility functions → the utility layer compares captured identity/face input against the serialized database in db/ → if a match is found, attendance is recorded in CSV files → the GUI shows the result to the operator.
7. The repo does not show any network service, API layer, or external database server. That makes the operational boundary entirely local: one machine runs the UI and processing, while all state lives in the repository’s files.
8. test.py and testing.py are separate validation/support scripts, likely used to exercise recognition or attendance logic without using the full GUI. They are not part of the main runtime path but help verify behavior.
9. requirements.txt defines the runtime dependencies, which likely include the GUI toolkit and any computer-vision or data-processing libraries needed by main_gui_ctk.py and util.py. Those dependencies materially affect the architecture because this is a desktop, dependency-heavy local app.
10. For an architecture diagram, the main boundaries to draw are:
- Operator/UI boundary: main_gui_ctk.py
- Business logic boundary: util.py
- Persistent identity store: db/*.pickle
- Attendance record store: log.csv and logged_in.csv
- Supporting test scripts: test.py, testing.py
11. The main architectural characteristic is that state is file-backed and tightly coupled to the desktop app. That keeps deployment simple for rural-school usage, but it also means data integrity and concurrency are managed at the application/file level rather than by a database or service layer.
Main entry points: util.py Utilities · main_gui_ctk.py Main GUI · db Identity Store · log.csv Attendance Log
Components 16
User Interface
Operator-facing desktop entry point and interaction layer.
- Main GUI · Primary operator interface for running attendance capture and viewing results.
main_gui_ctk.py - Screen Flow · Coordinates capture actions, status updates, and operator feedback.
main_gui_ctk.py - Capture Input · User-triggered capture path that feeds identity or face data into processing.
main_gui_ctk.py - Attendance View · Displays recognition and attendance outcomes to the operator.
main_gui_ctk.py
Core Logic
Shared processing and attendance rules.
- Utilities · Common rules and processing used by the GUI for matching and file handling.
util.py - Match Rules · Compares captured identity or face data against enrolled records.
util.py - Record Attendance · Appends attendance outcomes and prevents duplicate entries.
util.py - File Helpers · Shared read/write helpers for local CSV and pickle-backed state.
util.py
File State
Local persisted identity data and attendance records.
- Identity Store · Serialized recognition or enrollment data used at runtime.
db - hom.pickle · One persisted identity or feature dataset used by matching logic.
db/hom.pickle - oniq.pickle · Another persisted identity or feature dataset used by matching logic.
db/oniq.pickle - Attendance Log · Main flat-file log of attendance events.
log.csv - Logged State · Tracks already-processed or present identities to avoid duplicates.
logged_in.csv
Support
Non-runtime validation and dependency definition.
- Validation Scripts · Standalone scripts used to exercise recognition and attendance logic.
test.py - Testing Script · Additional support script for verifying behavior outside the GUI.
testing.py - Dependencies · Runtime dependencies for the GUI and processing stack.
requirements.txt
Connections 19
- Main GUI → Screen Flow: drives · The entry point coordinates the operator workflow.
- Main GUI → Capture Input: starts · The GUI initiates attendance capture actions.
- Main GUI → Attendance View: shows · The GUI presents recognition and attendance results.
- Screen Flow → Utilities: uses · Screen actions delegate processing to shared logic.
- Capture Input → Utilities: sends data · Captured input is handed to utility processing.
- Utilities → Match Rules: applies · Utility code performs matching and identity lookup.
- Utilities → Record Attendance: records · Utility code writes attendance outcomes and guards duplicates.
- Utilities → File Helpers: reads/writes · Utility code uses shared file access helpers.
- Match Rules → Identity Store: reads · Matching logic loads enrolled identity data from pickle files.
- Identity Store → hom.pickle: contains · Identity store includes the hom dataset.
- Identity Store → oniq.pickle: contains · Identity store includes the oniq dataset.
- Record Attendance → Attendance Log: appends · Attendance events are written to the main CSV log.
- Record Attendance → Logged State: updates · Duplicate-prevention state is maintained in a CSV file.
- File Helpers → Attendance Log: accesses · Shared helpers support reading and writing the log file.
- File Helpers → Logged State: accesses · Shared helpers support reading and writing logged-in state.
- Validation Scripts → Utilities: exercises · Validation scripts likely call shared processing directly.
- Testing Script → Utilities: exercises · Additional script for non-GUI verification.
- Main GUI → Dependencies: depends on · The desktop app relies on declared runtime packages.
- Utilities → Dependencies: depends on · Shared logic likely requires the same processing libraries.