Exp-2 - STUDENT MARK ANALYZING SYSTEM
Exp-2 - STUDENT MARK ANALYZING SYSTEM
No:
STUDENT MARK ANALYZING SYSTEM
Date:
1. Problem analysis and project planning
Introduction
Student mark analyzing system has been designed to carry out the
mark analysis process in an educational institution. The results of
respective departments can be efficiently computed without much of
manual involvement.
Objectives
The purpose of this document is to define the requirements of mark
analysis system. This system reduces manual work to great extent. The
mark analysis is carried out by the system in an efficient manner.
Scope
This system is very essential for every educational institution as it
reduces man power. This system can be used for all kinds of educational
institutions to evaluate and analyze the marks and generate reports of
specified criteria.
Problem Statement
For analyzing the marks obtained by students in an educational
institution. We are tasked to build up student mark analyzing system.
For security reasons, the administrator and faculty only can update
the marks and other information. First the user needs to login to the
system for accessing it. The system will retain information on all the
students and the institution. The system analyses the marks and generate
the result reports. The marks and information about the students are
stored in a database and the system works with the database.
The faculty can enter the marks and student information through a
visual environment. The updated details are stored in the database. The
system generates the overall result by analyzing the marks. Mark
analyzer monitors this process. The application in run by the mark
analyzer. The trial for illegal updation would render the system to be
locked.
FUNCTIONAL REQUIREMENTS:
i Login:
This use case describes how a user logs in to the mark analyzing
system.
ii Marks entry:
This use case allows faculty to enter the marks into the student
table.
This use case describes how the system generates the overall
result by analyzing the marks.
iv Maintain student information:
This use case allows the system to generate various reports based
on the criteria specified by the user.
Identified Actors
i Faculty:
ii Administrator:
iii Database:
The database that contains all the information about the student and
their marks.
iv Mark analyzer:
v Student:
Details about the students are entered into the system so that the
student can view the results and reports.
vi Placement Officer:
The placement officers can also view the reports based on the
criteria specified.
Use Case Diagram
lo
faculty gi
n
mark entry
administrator
database mark
analysis
mark
analyser maintain student information
student
result
report
Placement
officer view
reports
3. Design of Students Mark analyzing System
Design Documentation
1. Login
Brief description:
This use case describes how the user logs into the Marks
Analyzing System(MAS).
Flow of events:
Basic flow:
This use case starts with the actor wishes to log in to the
MAS.
Alternative flow:
1. Invalid name and password.
2. If in Basic flow the actor enters and invalid name and
password, the system displays an error message. The
actor can choose to either return to the beginning of
basic flow or cancel the login at which point the use
case ends.
Pre conditions:
None.
Post conditions:
If the use case was successful, the actor is now logged into the
system, if not, the system status unchanged.
2. Marks Entry
Brief description:
This use case allows the faculty to enter the marks into the student
table.
Flow of events:
Basic flow:
This use case starts when the faculty wishes to enter the marks
obtained by the student in different subjects.
Alternative flow:
i. Invalid Marks:
In Basic flow, if invalid marks are entered, the system
displays an error message and prompts for a valid mark. The
faculty must enter a valid mark or cancel the operation in which
case, the use case ends.
ii. Marks already entered:
If in basic flow, the student mark has already been entered,
the system displays the read only copy of marks and informs the
faculty that the mark has already been entered. So, no changes
can be made to it. The faculty acknowledges the message and the
use case ends.
iii. Fields left empty:
If in basic flow, the field is left empty, the system prompts
the faculty to correct the error. The faculty can enter the mark or
mark the student as absent.
P re Condition:
The faculty must be logged on to the system before the use case
begins.
Post Condition:
If the use case was successful, the student mark is saved to system
otherwise the system status is unchanged.
3. Mark Analysis
Brief description:
This use case describes how the system generates overall results by
analyzing the marks, Marks Analyzer monitors this process.
Flow of events:
Basic flow:
This use case begins when the mark analyzer wishes to calculate
the total percentage of marks obtained by the students.
Alternative flow:
i. Marks unavailable:
If in basic flow, the information about student marks could not be
located, the system displays error message and use case ends.
Pre Condition:
The mark analyzer must be logged on to the system before this
use case begins.
Post Condition:
If the use case was successful, the processed mark information is
saved to the system otherwise the system status is unchanged.
Brief description:
This use case allows the administrator to maintain the student
information. This includes adding, changing and deleting information
from the system.
Flow of events:
Basic flow:
This use case starts when the administrator wishes to change, add
or delete student information from the system.
Delete a Student:
1. The System requests the administrator to enter
the register number.
2. Administrator enters the register number and then the
system retrieves and displays the information.
3. The System prompts administrator to confirm deletion of
the student.
4. Administrator verifies the deletion.
5. The System deletes the student from the database.
Alternative flow:
iv. P re Condition:
The administrator must be logged on to the system before
this use case begins.
v. Post Condition:
If the use case was successful, the student information is
added, updated or deleted.
5. Create result/report
Brief description:
Flow of events:
Basic flow:
This use case starts with the actor user wishes to create a report.
1. The system requests the user to specify the
following report criteria:
Report type (either “Overall class/Department
result”, ”Individual
Student Result”, ”Toppers List”, ”Arrears List”
and “Improvement
Rate for the academic year”).
Criteria for the respective report.
2. If the user selects the “Overall class/department
result” report,the system retrieves and displays the
entire Student‟s mark
3. information form the database. The system then
requests the user
4. to enter information he/she requires(criteria).
Alternative flow:
Pre condition:
The user must be logged on to the system before the use case begins.
Post condition:
1. Login
2: Select to login()
7: Valid marks()
8: valid(store in database)
9: Invalid marks()
5: Calculation of total,Average()
: Selectio Session
Administrato n Controller
r Form
3: Add option()
4: Update option()
sequen
ce
5: Delete option()
diagra
m...
sequen
ce
diagra
m...
sequ
ence
diagr
am-...
Add a student
2: Enter details()
3: Validate Details()
no()
3: Validate reg no
6: Update marks()
7: Invalid updation()
8: Request to re-enter or cancel()
Delete a student
6: Invalid reg no
3: Validate type
9: Store to database
1. Login
Main
1: User enter mainform() Form 2: Select to login()
8: Welcome message
generate() 10: Error message-relogin or
cancel() 5: Validate username and Error
password() Message
: Database
2. Marks Entry
Main
Form 3: Enter mark entry form()
2: Enter operation(mark entry)
Marks Entry
6: Faculty enter marks()
Form
1: Request to specify opreration()
5: Request to enter marks()
Faculty
4: Refer from Database()
7: Valid marks()
8: valid(store in database)
Entry
Controller 10: Request to restart/cancel()
Error : Database
9: Invalid marks() Message
3. Mark Analysis
3: Enters into the form()
Main Student Information
2: Processing marks() Form
Form
5: Calculation of total,Average()
8: Restart the operation()
6: Valid modified table into the database()
3: Add option()
4: Update option()
5: Delete option()
Session
Controller
Add Student
3: Validate Details()
2: Enter details()
Addm Addition
for r
controlle
1: Request to enter name,dept,addr()
: Administrator
: Database
Update Student
6: Update
update
marks() 1: Request to enter reg controller
no()
Error
message
: Database
Delete Student
6: Invalid reg no
5: Valid reg no student deleted()
Error
message
: Database
5. Create Result/Report
: Database
error
message
STATECHART DIAGRAM
1. Login
Initialization
Validate Details
Cancelled Cancelled
Cancel
2. Mark Analysis
cancelled cancelled
Cancel
ACTIVITY DIAGRAM
Process the
register no.
Updating the
database
Process
the details
Request to enter the
details of the student
to be added. valid details
Generate register
no. for the student
Confirmation that
student have been added
3. Deleting a Student
check reg.no
Delete
Update
database
CLASS DIAGRAM
1. Login
Main form
enter operation()
Error message
Student
Invalid marks()
Display error message()
Login form
name Welcome form
password
Login Controller
Database
2. Marks Entry
Main form
enter operation()
Student
Database
3. Mark Analysis
Database
enter operation()
Student
Error message
Invalid marks()
Display error message()
Report Controller
Report form
Validate the criteria()
Request the user to enter the
) Ask whether to save or not()
criterias( validates()
selects to save()
validate type() selects not to save()
retrieves information from database()
Database
5. Maintain Student Information
Selection
controller Update form(from
add option() database)
Update optio
Delete option( n() Admin enters reg. no()
) Database
COMPONENT DIAGRAM
<<ActiveX DLL>>
Login
<<ActiveX DLL>>
<<ActiveX DLL>> Maintain Student
Marks Entry Information
<<ActiveX DLL>>
Mark Analysis
<<ActiveX DLL>>
Create
Result/Report