11


 


 

Team Name

SPREESTERS

Team Members

K.KEERTHI
CH.MADHAVI
P.V.KEERTHI KRISHNA
K.K.VASUNDHARA

Project Guide

Mr .NAVEEN KUMAR

v1
 11

INDEX
1) Introduction
1.1) Purpose………………………………………………………………………3
1.2) Scope of the project………………………………………………………….3
1.3) Abbreviations………………………………………………………………...3
1.4) References…………………………………………………………………....4
1.5) Techniques……………………………………………………………………4
1.6) Overview……………………………………………………………………..5
2) Requirement Elicitation
2.1) Problem Statement………………………………………………………….5
2.2) Current Scenario………………………………………………………….....5
2.3) Proposed Solution…………………………………………………………..5
2.4) Functional Requirements……………………………………………………6
2.5) Non Functional Requirements………………………………………………6
3) Overall Description
3.1) Product Perspective………………………………………………………….7
3.2) Software and Hardware specifications………………………………………8
3.3) Use case Model Scenario…………………………………………………….9
3.4) Architecture Diagram……………………………………………………….13
3.5) Database Design…………………………………………………………….14
4) Specific Description
4.1) Use case Representation……………………………………………………16
4.2) Deployment Diagram………………………………………………………38
4.3) Sequence Diagram…………………………………………………………39
4.4) Collaboration Diagram……………………………………………………..42

v2
 11

1. INTRODUCTION:

1.1) PURPOSE: Online attendance is for establishing and sustaining the attendance
by maintaining valuable student information. It also integrates the details of students, which
gives an overall view of all the students. The central repository enables to track student data,
percentage of attendance, time table for particular teacher, user contact information and
department details.
This system helps the college management to communicate the details of
the student’s attendance percentage through Mailing Service. This System provides facility to
generate reports on each day, monthly. Then it will identify the students who have less percentage
of attendance than the required aggregate percentage .It sends the mail, messages to the Email
about the attendance details. Apart from this it provides one Tool for the Attendance Updaters to
enter the daily attendance, Generate reports.

1.2) SCOPE OF THE PROJECT : System with adaptability to any

college to monitor the Attendance details of the students. It also provides the
facility to send and receive mail

Create different system users and assign different roles with related
permissions.
Manage all the account details such as student name, phone numbers, address,
email addresses of all the students .
Track all the lecturer and their contact details.
Maintain the details of the lecturer and the subject he/she deals with.
Group the students into a single account according to their branch,year of studying
and section.
Views the student information and hides the personal details of lecturers like their
education qualification ,salary etc.,

1.3) ABBREVIATIONS:

HTTP: Hypertext Transfer Protocol is a transaction oriented client/server protocol between

web browser & a Web Server.

v3
 11

WAS: Web sphere application server is an application server that runs business applications
and support the J2EE and web services standards.

HTML: Hypertext Markup Language is a markup language used to design static web
pages.

J2EE: Java 2 Enterprise Edition is a programming platform— part of the Java Platform—
for developing and running distributed multitier architecture Java applications,
based largely on modular software components running on an application server.

DB2: DB2 Database is the database management system that delivers a flexible and cost-
effective database platform to build robust on demand business applications. Create
different system users and assign different roles with related permissions.

TCP/IP: Transmission Control Protocol/Internet Protocol, the suite of communication

protocols used to connect hosts on the Internet. TCP/IP uses several protocols, the
two main ones being TCP and IP.

1.4)REFERENCES
IEEE SRS Format
Beginning JavaServer Page authors:-Vivek Chopra, Sing Li, Rupert Jones,
Jon Eaves, John T. Bell
Programming and Problem Solving with Java, James M. Slack, Thomson Pte ltd, 2001
www.w3schools.com
www.hotscripts.com
www.roseindia.net

www.developer.com

1.5) TECHNOLOGIES:
J2EE :Application Architecture
DB2:Database
WSAD: Development Tool
WAS: Web Server
Rational Rose: Design Tool

v4
 11

1.6) OVERVIEW: SRS will include two sessions

Overall Description will describe major components of the system, interconnection
and external interfaces.

Specific Description will describe the functions of actors, their role in the system and
constraints.

2) REQUIREMENT ELICITATION:
2.1) PROBLEM STATEMENT:
1. It should monitor the Students Attendance Details.
2. Attendance Reports Generation and Maintenance facility.
3. It should provide a Tool to enter Daily attendance for attendance Updaters.
4. Sending & Receiving Mails facility.

2.2) CURRENT SCENARIO:

In the existing system, the details of the students regarding their attendance and
marks are being maintained in the database and a print of it is made and sent to parents by
post monthly once. The problems here are:
• More manual work.
• Chance of missing the letters through post.
• Consumes more time.

2.3) PROPOSED SOLUTION:

This system helps the college to communicate the details of the attendance. By
generating reports twice or thrice a week it will identify the students who have less
percentage of attendance than the stipulated attendance percentage and sends mails.
Salient Features:

• Fast and accurate report generation.

• Easy, interactive GUI.

v5
 11

• Two way communication

2.4) FUNCTIONAL REQUIREMENTS:
The main purpose of functional requirements within the requirement specification
document is to define all the activities or operations that take place in the system. These
are derived through interactions with the users of the system.
But the general Functional Requirements arrived at the end of the interaction with
the Users are listed below. A more detailed discussion is presented in the Chapters, which
talk about the Analysis & Design of the system.
The system holds the details of the students personal and attendance details and
staff details, branch details.
It holds the Daily, Weekly, monthly attendance Reports of students .
It holds the details login.
The system allows the administrator to manage different users.
It also allows the administrator to insert, update, delete the details of students,
staff.
It allows the administrator to send mail to students mails.
It allows the students to check the attendance percentage.
It allows the attendance updater to enter daily attendance and generate reports.
It allows the students to send feedback staff mails.
It allows the staff to send a message to other staff/students about important
notices.

2.5) NON-FUNCTIONAL REQUIREMENTS:

The non-functional requirements consist of
1. Constraints.
2. Guidelines.
Constraints:
These are the requirements that are not directly related to the functionality of the
system. These should be considered as mandatory when the system is developed. The
following Constraints were arrived at for the system:

v6
 11

1. The system should be available over the intranet so that the Users like the
administrator, staff, student can use the system from their respective locations.
2. For gaining entry into the system the users should be registered by the administrator
and should be able use login & passwords for gaining access to the system.
3. The users should be able to change their passwords for increased security.
4. The system should be easy to understand and organized in a structured way. The users
should also receive appropriate messages about any errors that occur.
5. There should be no limitation about the hardware platform that is to be used to run the
system.
6. Data integrity should be maintained if an error occurs or the whole system comes
down.
Guidelines:
We have discussed mandatory requirements in the previous section. The
requirements in this section should be taken as suggestions & they should be thought of
as recommendations to further enhance the usability of the system.
1. The system should display a menu for users to choose from.
2. The system should display users’ requests in a reasonable time.
3. Services of the system should be available 24 hours a day.
4. The system should be designed in such a way that it is easy to enhance.
5. It should be scalable & easily maintainable.

3) OVERALL DESCRIPTION:
3.1) PRODUCT PERSPECTIVE:
The web pages (XHTML/JSP) are present to provide the user interface on
customer or client side. Communication between customer and server is
provided through HTTP/HTTPS protocols.
The Client Software is to provide the user interface on system user client side
and for this TCP/IP protocols are used.
On the server side web server is for EJB and database server is for storing the
information.

v7
 11

HTTP/
HTTPS

HTML
Client
(Customer) Web
sphere DB2

Client
Software
(user)

TCP/IP

CLIENT Application Database

Server Server

3.2) SOFTWARE AND HARDWARE SPECIFICATIONS:

Software Requirements

Operating System : Windows XP/2003

User Interface : HTML,JSP
Client-side Scripting : JavaScript
Programming Language: Java
Web Applications : JDBC, Servlets, JSP
IDE/Workbench : My Eclipse
Database : db2
Server Deployment : Websphere

v8
 11

Hardware Requirements

Processor : Pentium IV
Hard Disk : 40GB
RAM : 256MB

Communication Interface:

Client on Internet will be using HTTP/HTTPS protocol.

Client on Intranet will be using TCP/IP protocol.

3.3) USE CASE MODEL SCENARIO:

Inbox
Change profile

Student Updater
Upgrade Details

View Attendance

Update Attendance

Manage Mails

Faculty
Administrator
View All Details

View Student Details

v9
 11

1.) Administrator:
Administrator is responsible for view all details, details of attendance,
sending and receiving mails.
View all details: View the list of student details and the list of faculty
details
View Attendance Details: Administrator can view the attendance details
of students.
Manage mails: Sends e-mail to the students who have less attendance
percentage. Administrator receives the e-mail from student who has less
percentage of attendance and the reason for his absence.

View All Details

View Attendance Details

Administrator

Manage Mails

2.) Faculty:
Responsible for updating student attendance, sending and receiving mails,
view student details and viewing his own details.
Updating attendance: Updates student attendance daily by marking the
absentees or sometimes handover it to the updater.
View student details: Faculty can view the attendance of particular student
and also his/her personal details.
Manage own details: Faculty can view own details like timetable, subjects
assigned.

v10
 11

Inbox: Faculty can view the mails under his/her account.

Update Attendance

View Student Details

Faculty

Manage Own Details

Inbox

2.) Updater: Responsible for managing system users, view attendance status of
students , send mail and updating attendance of the students.
Inbox: The updater is responsible for sending mails to those whose attendance
is less than 75% and post some important notices.
View attendance status: View the attendance status and details of the
students.
Upgrade: The updater is also responsible for changing details of the students
year by year like promoting to the next year, changing subjects, faculty and
student details and so on.
Update attendance: The main duty of updater is to update attendance of the
students.

v11
 11

View Attendance

Update Attendance

Updater

Inbox

Upgrade Details

4) Student: Student is responsible for views his/her attendance, changing profile

and managing mails.
View attendance: Student can view attendance details of his/her own.
He/she can view present or particular period of time attendance details.
Change profile: Student can also make any modifications with regard to his
personal and account settings.
Manage mails: Students can also send mails seeking permission leave and
so on and receive mails.

Attendance Details

Change Profile
Student

Manage Mails

v12
 11

3.4) ARCHITECTURE DIAGRAM:

APPLICATION BUSINESS DATA

Role Role-name Role name

Permission Permission name Permission

User Username User name

Change profile Change profile Change details

View Details View Own Details View details

Update Attendance Update Attendance Update

Daily attendance Daily attendance Daily attendance

View Attendance View attendance View attendance

Send Mail Send message Send mail

Inbox Check mails Inbox

Upgrade Details Upgrade details Upgrade

Change password Change password Change password

v13
 11

3.5) DATABASE DESIGN:

Role

Role id
Role name

Updater

Administrator

Student
Faculty

Users

Username
Password Makes
Question
Answer
Name
Type

Task Logs
Role task Username
Task id
role id Task name Date
Task id Permission

v14
 11

DATABASE DESIGN:

Students
Daily attendance
Users Snumber
Sregistration number
Username Sname
Ssection
Password Sregistration number Syear
Question Syear Date
Answer Ssection
Status
Name Sroll number
Subject name
Type Ssemister
Total classes
Sphone number Attended classes
Smail-id

Mails
To
Faculty From
Faculty number Message
Faculty name Date
Faculty type Subject
Faculty department Attendance Details
Faculty phone number Sregistration number
Faculty mail-id Ssection
Syear
Subject1
Totalsubject1
Percentagesubject1
Lab1
Timetable Totallab1
Subjects Day Percentagelab1
Subject number Section Total Percentage
Subject name Year
Alias name Period
Ssection Faculty number
Syear Subject name
Faculty number

v15
 11

Administrator Student

View All Change View Change

Details password Attendance Profile

View Mails Change Mails

attendance password

Updater Faculty

Update Upgrade Update View

Attendance Details Attendance Attendance

View View Change Mails

Details attendance Profile

Change Mails Change

password password

4) SPECIFIC DESCRIPTION:
4.1) USE CASE REPORTS:
a) Administrator:
Administrator is responsible for view all details, details of attendance,
sending and receiving mails.
View all details: View the list of student and their details and the list of
faculty and their details.

v16
 11

View Attendance Details: Administrator can view the attendance details

of students.
Manage mails: Administrator receives the e-mail from student who has
less percentage of attendance and the reason for his absence. Sends mail to
the faculty on new events happening in the college.

Name of the use case: View all details

Description: Administrator can view the all details of faculty and students.
Precondition:
Administrator is already logged in.
Student and faculty database is already created.

Normal flow of events:

Select whose details are to be viewed.
If student is selected, ask for the type of details to be displayed.
If faculty is selected, ask for the type of details to be displayed.
Display the required details.

Alternate flow of events: None

Post condition: None.

Ask for faculty

or student

Student

Faculty
Ask for the
Ask for faculty class

Class selected
Faculty selected

Display the Ask for

required details student

v17
 11

Name of the use case: View attendance details.

Description: Administrator is responsible for view the attendance
details of students.
Precondition:
Administrator is already logged in.
All the details are already stored in the database.

Normal flow of events:

Select the class whose students’ details are to be viewed.
Select the percentage range in which the students to be viewed.
Display as per the selection.

Alternate flow of events: None.

Post condition: None.

Ask for the

class

Class selected

Ask for the current or particular

duration of attendance status

Ask for the Particular range

range

Present

Display the
required status

v18
 11

Name of the use case: Manage mails

Description: Administrator can send mails to those whose attendance
percentage is very low and can also receive mails from those who
want to seek leave.
Precondition:
Administrator is already logged in.

Normal flow of events:

Select Inbox to view mails under his/her account.

Or else select send mails to send a mail.
Do as per selection.

Alternate flow of events: None.

Post condition: None.

Select managing
mails

Send Ask for

recipient
Inbox

View mails Send the

message

v19
 11

b) Faculty:
Responsible for updating student attendance, sending and receiving mails,
view student details and viewing his own details.
Updating attendance: Updates student attendance daily by marking the
absentees or sometimes handover it to the updater.
View student details: Faculty can view the attendance of particular student
and also his/her personal details.
Manage own details: Faculty can view and edit own details like timetable,
subjects assigned.
Inbox: Faculty can view the mails under his account.

Name of the use case: Manage Own Details

Description: View and edit details like timetable, subjects assigned and so on.

Manage Timetable

View Subjects Assigned

Manage Own Details

Change Profile

v20
 11

Name of the use case: Manage timetable

Description: View the timetable of the faculty concerned.
Precondition:
Faculty is already created and logged in.
Timetable database is already created.
Normal flow of events:
Ask for the timetable.
Display the timetable.
Alternate flow of events: None.
Post condition: None.

Select manage
details

Select manage
timetable

View

Edit

Ask for the Ask for the

changes details

Update Display the

changes required details

v21
 11

Name of the use case: View subjects assigned

Description: View the assigned subjects of the faculty.
Precondition:
Faculty is already created and logged in.
Subject database is already created.
Normal flow of events:
Ask for the subjects assigned.
Display the assigned subjects.
Alternate flow of events: None.
Post condition: None.

Ask for subject

assigned

subject
selected

Display assigned
subjects

v22
 11

Name of the use case: Change profile

Description: View the timetable of the faculty concerned.
Precondition:
Faculty is already created and logged in.
Timetable database is already created.
Normal flow of events:
Ask for the timetable.
Display the timetable.
Alternate flow of events: None.
Post condition: None.

Select Change
Profile

Selceted
Account
Modify Account
Details

Personal

Modify Personal
Details

Update
Changes

v23
 11

Name of the use case: View Student details

Description: Faculty can personal as well as attendance details of student.
Precondition:
Faculty is already created and logged in.
Student database is already created.
Normal flow of events:
Select the class whose students’ details are to be viewed.
Select the student.
Ask for personal or attendance details.
The required details are displayed.
Alternate flow of events: None.
Post condition: None.

Ask for the

class

Class selected

Ask for the

student

Student selected

Ask for the Personal

personal details

Attendance

Ask for the

attendance

Display the
required details

v24
 11

Name of the use case: Update attendance

Description: Update attendance status of the students as per given schedule.
Precondition:
Faculty is already created and logged in.
Student database is already created.
Normal flow of events:
Select the class whose attendance details are to be updated.
Alternate flow of events: None.
Post condition: None.

Ask for the

class

Class selected

Ask for the period

from timetable

Period selected

Update student attendance

in displayed list

Store changes

v25
 11

c) Updater: Responsible for creating system users , updating attendance

details, upgrading students details ,changing students and faculty details.
Inbox: The updater can view the mails sent to him.
View attendance status: View the attendance status and details of the
students.
Upgrade: The updater is also responsible for changing details of the
students year by year like promoting to the next year, changing subjects,
faculty and student details and so on.
Update attendance: The main duty of updater is to update attendance of the
students.

Name of the use case: Upgrade details

Description: Update details of the students and staff.

View details

Promote Student

Student Edit Details

Modify Details

Add Student
Delete Student
Upgrade

Add Faculty
Delete Faculty

Faculty Modify Details

View Details Edit Details

v26
 11

Name of the use case: View Details (Student/Staff)

Description: View details of the students and staff.
Precondition:
Updater is already created and logged in.
All the details regarding the updater and attendance is already stored in the
database.
Normal flow of events:
Select whose details are to be updated.
If staff is selected, view the staff details as per selection.
If student is selected, view details as per selection.
Alternate flow of events: None.
Post condition: None

Ask for faculty

or student

Student

Faculty
Ask for the
Ask for faculty class

Class selected
Faculty selected

Display the Ask for

required details student

v27
 11

Name of the use case: Edit Details (student/staff)

Description: Modify the details of the students and staff.
Precondition:
Updater is already created and logged in.
All the details are already stored in the database.
Normal flow of events:
Select whose details are to be updated.
If staff is selected, existing faculty’s details can be deleted or edited.
If student is selected, existing students’ details can be deleted or edited.
Alternate flow of events: None.
Post condition: The changes are reflected onto database.

Select
student/faculty

Faculty Ask for the

faculty
Student

Ask for class

Class selected Faculty

selected
Ask for
student

Student selected

Ask for type of

details

Selected

Update
changes

v28
 11

Name of the use case: Delete student/staff

Description: Modify the details of the students and staff.

Precondition:
Updater is already created and logged in.
All the details regarding the updater and attendance is already stored in the
database
Normal flow of events:
Select whom to be deleted.
Ask for the required details and delete the required one.
Alternate flow of events: None.
Post condition: The changes are reflected onto database.

Select
student/faculty

Faculty Ask for the

faculty
Student
Ask for class

Class selected Faculty

selected
Ask for
student

Student selected
Delete ar per
selected

Update
changes

v29
 11

Name of the use case: Add details (student/staff)

Description: Add new students and staff.

Precondition:
Updater is already created and logged in.
All the details regarding the updater and attendance is already stored in the
database.
Normal flow of events:
Select student if a new student is to be added.
Else select faculty if a new faculty is to be added.
Ask for the required details.
After adding, the details are reflected onto the database.
Alternate flow of events: None.
Post condition: None

Select upgrade

Select add

Faculty Ask for the

faculty details
Student

Ask for
student details

Add details

Update changes
in database

v30
 11

Name of the use case: Promote students

Description: Promote students to next year.
Precondition:
Updater is already created and logged in.
All the details regarding the updater and attendance is already stored in the
database.
Normal flow of events:
Select the class whose students have to be promoted to the next year.
Ask for the required details like subjects and concerned faculty.
Alternate flow of events: None.
Post condition: None

Ask for the

class

Class selected

Select student

Ask for which class they

have to be promoted

Invalid

Valid

Promote to
corresponding year

Update
changes

v31
 11

Name of the use case: Update attendance

Description: Update attendance of the students.
Precondition:
Updater is already created and logged in.
Normal flow of events:
Select a class whose students’ attendance details are to be updated.
Select for how many periods you want to update whether for a single
period or for a whole day.
Then update the attendance.
The corresponding change must be reflected onto the database.
Alternate flow of events: None.
Post condition: Update the changes in the database.

Ask for the

class

Class selected

Ask for the period

from timetable

Period selected

Update student attendance

in displayed list

Store changes

v32
 11

Name of the use case: View attendance status

Description: View attendance status of the students so as to generate reports.
Precondition:
Updater is already created and logged in.
Normal flow of events:
Select a class whose students’ attendance details you want to know.
The details are displayed.
Alternate flow of events: None.
Post condition: None

Ask for the

class

Class selected

Ask for the current or particular

duration of attendance status

Ask for the Particular range

range

Present

Display the
required status

v33
 11

Name of the use case: Inbox

Description: The updater can view the mails sent to him and in turn reply to
them.
Precondition:
Updater is already created and logs in.
Normal flow of events:
Select a mail to read.
Reply if needed after reading.
Alternate flow of events: None.
Post condition: None

Ask for inbox

Inbox selected

Display the
inbox

d) Student:
Student is responsible for views his/her attendance , changing profile and
managing mails.
View attendance: Student can view attendance details of his/her own.
He/she can view present or particular period of time attendance details.
Change profile: Student can do any modifications of personal settings
like name, phone number and so on and account settings like username,
passwords and so on.
Managing mails: Students can send and receive mails.

v34
 11

Name of the use case: View attendance

Description: The first and foremost privilege given to the student is to view
his/her attendance status.
Precondition:
Student is already logged in.
All the details regarding students is already stored in the database.
Normal flow of events:
Select View attendance.
Select particular range to view the attendance status during a particular
range.
Else select present to view the present attendance status.
Display as per the selection.

Alternate flow of events: None

Post condition: None

Select view
attendance

Particular period Ask for from

date -to

Present

View attendance
percentage

v35
 11

Name of the use case: Change profile

Description: Student is responsible for any modifications in profile.
Precondition: Student is already logged in.
Normal flow of events:
Select change profile.
Modify the changes that are need to be.
Store the modifications.

Alternate flow of events: None

Post condition: Update the changes in database.

Select Change
Profile

Selceted
Account
Modify Account
Details

Personal

Modify Personal
Details

Update
Changes

v36
 11

Name of the use case: Manage mails

Description: Student can send mails to seek leave and also view his/her mails.
Precondition:
Student is already created and logged in.
All the details regarding student is already stored in the database.

Normal flow of events:

Select Inbox to view mails under their account.

Or else select send mails to send a mail.
Do as per selection.

Alternate flow of events: None.

Post condition: None.

Select managing
mails

Send Ask for

recipient
Inbox

View mails Send the

message

v37
 11

4.2) DEPLOYMENT DIAGRAM:

Deployment diagrams can be used to model the physical aspects of the
system. A deployment diagram shows the configuration of run time processing nodes and
the components that live on them.

Client Websph Odbc Databas

ere driver e server

4.3) SEQUENCE DIAGRAM:

Sequence diagram is a graphical view of a scenario that shows object interaction
in a time-based sequence what happens first, what happens next. Sequence diagrams
establish the roles of objects and help provide essential information to determine class
responsibilities and interfaces.

v38
 11

A.)Administrator:

GUI View Update Mails Database

Administrator
login()

validate()

View attendance( )

View records( )

View( )

Update attendance( )

Update( )

Send mail( )

Inbox( )

Mail( )

queue( )

View Mail( )

v39
 11

B.)Faculty:

GUI View Update Mails Database

Faculty
login()

validate()

View attendance( )

View records( )

query( )

View( )

Update attendance( )

Update( )

query( )

Send mail( )

Inbox( )

Mail( )

query( )

Mail( )

v40
 11

C.)Updater:

Updater GUI Update View mail Database

Upgrade

login()

login()

Upgrade details( )

Upgrade( )

query( )

Update attendance( )

Update( )

query( )

View attendance( )

View records( )

query( )

Send mail( )

Inbox( )

Mail( )

query( )

v41
 11

D.)Student:

GUI Profile View Mails database

Student
login()

validate()

Change profile( )

Change( )

query( )

View attendance( )

View records( )

view( )

query( )

Send mail( )

Inbox( )

query( )

4.3) COLLABORATION DIAGRAM:

Collaboration diagrams and sequence diagrams are alternate
representations of an interaction. A collaboration diagram is an interaction diagram that
shows the order of messages that implement an operation or a transaction. A sequence
diagram shows object interaction in a time-based sequence.

v42
 11

A.)Administrator:

2: validate()

View
11: queue( )
4: View records( )
GUI 3: View attendance( )

5: View( )
1: login() 10: Mail( )
8: Send mail( )
Database
Mails

9: Inbox( )
12: View Mail( ) 7: Update( )
Administrator

6: Update attendance( )

Update

B.)Faculty:

2: validate()

3: View attendance( )
View

GUI 4: View records( ) 8: query( )

5: View( )

1: login()
9: Send mail( )
11: Mail( )
Mails
Databas
12: View Mail e
10: Inbox( )
Faculty

7: Update( )

Update

6: Update attendance( )

v43
 11

C.)Updater:

2: validate()

7: View attendance( )

GUI View
12: query( )
8: View records( )

1: login() 5: Update attendance( )

6: Update( )
Update
Databas
11: Mail( )
e

Updater 9: Send mail( )

mail

10: Inbox( )
4: Upgrade( )
13: View Mail( )
3: Upgrade details( )

Upgrade

D.)Student:

2: validate()
3: Change profile( )

Profile

11:
GUI 4: Change( )

1: login()
8: Send mail( ) 10:
Mails databas
e
9: Inbox( )
Student

6: View records( )
7: view( )

View

5: View attendance( )

v44
 11

4.4) CONCLUSION:
Online attendance management system aims at maintaining attendance details,
students’ records. It is the best solution compared to the currently present solution which
involves the risk of losing data. In addition, it should have some supplementary
requirements like availability of system throughout the day and it would remain
unavailable for two hours a day for backup and recovery. The server should be capable of
maintaining sessions within the application.

v45