How abxijth/oop-term-project-student-attendance-management-system works
1. Repository shape
- This is a single Java, object-oriented application in Phase-3/Program/src.
- The Phase-1.pdf and Phase-2.pdf files appear to be project documentation/artifacts, not runtime components.
- There is no visible web layer, database, or service tier in the tree.
2. Overall architecture
- The system is a monolithic attendance management app built around a small set of domain classes and one orchestrating application class.
- The design is centered on in-memory state management through DataStore, with the rest of the classes modeling users, courses, sessions, and attendance events.
3. Main entrypoint and orchestration
- AttendanceManagementSystem.java is the likely main program / controller layer.
- It coordinates user actions such as login, creating sessions, marking attendance, and viewing attendance information.
- In architecture terms, it sits between the user interaction flow and the domain/data classes.
4. User and role model
- User.java is the shared base type for people in the system.
- Student.java, Faculty.java, and Admin.java represent the main roles.
- This suggests a role-based design where permissions and workflows differ by actor:
- Faculty manages class attendance.
- Student views their own attendance.
- Admin oversees the overall system.
5. Academic structure
- Subject.java models a course or subject offering.
- ClassSession.java models a specific lecture or class instance where attendance is taken.
- These classes define the academic context that attendance records belong to.
6. Attendance data model
- AttendanceRecord.java is the atomic attendance entry.
- It likely links a student, a class session, and a present/absent status.
- This is the key bridge between the academic schedule and student attendance history.
7. Shared state and repository boundary
- DataStore.java is the central application state container.
- It likely holds collections of students, faculty, subjects, sessions, and attendance records.
- Architecturally, it acts as an in-memory repository/fake database, which keeps persistence logic simple and local to the application.
8. Primary data flows
- Admin flow: creates or manages users and subjects, with system-wide visibility.
- Faculty flow: selects a subject/session, marks attendance, and stores records.
- Student flow: reads attendance status and percentages from stored records.
- These flows all converge on DataStore, which is the system’s shared source of truth.
9. Responsibility boundaries
- The project separates concerns in a lightweight way:
- AttendanceManagementSystem handles orchestration and user-driven flow.
- Domain classes (Student, Faculty, Subject, ClassSession, AttendanceRecord) hold business data.
- DataStore manages stored collections and lookup state.
- This makes the architecture easy to diagram as controller + entities + shared store.
10. Technology/runtime
- The application is pure Java and intended to run with JDK 8+ from the command line or an IDE such as Eclipse/VS Code.
- No external dependencies, frameworks, or backend infrastructure are visible in the repository tree.
11. What the diagram should emphasize
- A single application boundary enclosing all runtime classes.
- AttendanceManagementSystem as the interaction/orchestration node.
- DataStore as the central shared data hub.
- Role-based actors (Student, Faculty, Admin) connected to the core attendance model (Subject, ClassSession, AttendanceRecord).
Main entry points: DataStore.java DataStore · User.java User · ClassSession.java ClassSession · AttendanceRecord.java AttendanceRecord
Components 12
Other components
- Attendance App · Main orchestration entrypoint for user-driven attendance workflows.
Phase-3/Program/src/AttendanceManagementSystem.java - DataStore · Central application state and lookup collections.
Phase-3/Program/src/DataStore.java - User · Shared superclass for system users and roles.
Phase-3/Program/src/User.java - Student · Learner role that consumes attendance history.
Phase-3/Program/src/Student.java - Faculty · Instructor role that creates sessions and marks attendance.
Phase-3/Program/src/Faculty.java - Admin · Administrative role for system-wide management.
Phase-3/Program/src/Admin.java - Subject · Represents a course or subject offering.
Phase-3/Program/src/Subject.java - ClassSession · A scheduled class instance where attendance is taken.
Phase-3/Program/src/ClassSession.java - AttendanceRecord · Atomic record linking a student to a session and status.
Phase-3/Program/src/AttendanceRecord.java - Login & Dispatch · Routes a signed-in user into the correct role-specific path.
- Attendance Ops · Faculty-side flow for session creation and attendance marking.
- Attendance View · Student-facing flow for viewing attendance status and totals.
Connections 21
- Attendance App → Login & Dispatch: routes · Starts the user interaction flow and selects the role-specific path.
- Login & Dispatch → User: authenticates · Uses the shared user model to identify the signed-in actor.
- User → Student: specializes · Student is a concrete user role.
- User → Faculty: specializes · Faculty is a concrete user role.
- User → Admin: specializes · Admin is a concrete user role.
- Attendance App → DataStore: reads/writes · Coordinates state changes through the shared store.
- Admin → DataStore: manages · Admin operations act on system-wide stored data.
- Faculty → Attendance Ops: drives · Faculty uses the attendance workflow.
- Attendance Ops → Subject: selects · Attendance operations are scoped to a subject.
- Attendance Ops → ClassSession: creates · Creates or opens the class session for attendance.
- Attendance Ops → AttendanceRecord: writes · Marks present/absent entries for students.
- Student → Attendance View: views · Student-facing attendance lookup flow.
- Attendance View → AttendanceRecord: reads · Reporting derives attendance history from records.
- Subject → ClassSession: groups · Sessions belong to a subject offering.
- ClassSession → AttendanceRecord: contains · Each session accumulates attendance entries.
- DataStore → Student: stores · Keeps student entities in memory.
- DataStore → Faculty: stores · Keeps faculty entities in memory.
- DataStore → Admin: stores · Keeps admin entities in memory.
- DataStore → Subject: stores · Keeps subject data in memory.
- DataStore → ClassSession: stores · Keeps scheduled sessions in memory.
- DataStore → AttendanceRecord: stores · Keeps attendance entries in memory.