Content uploaded by Idongesit Efaemiode Eteng
Author content
All content in this area was uploaded by Idongesit Efaemiode Eteng on Nov 23, 2016
Content may be subject to copyright.
INTERNATIONAL JOURNAL OF NATURAL AND APPLIED SCIENCES (IJNAS), VOL. 8, NOS.1& 2 (2013); P. 27 – 34, 6 FIGS,
3 TABLES
.
An object based result processing system
U.C.Nnabuko1, I.O.Iroegbu2, C.I. Ugwuoke3, I.E.Eteng1, M.C. Okoronkwo3
INTRODUCTION
The attempt to process students’ results with minimum or no
error has been noted to be of major concern to parties involved.
Due to the tedious and error-prone nature of manually-computed
results, students do not have access to their results on time.
Hence, the need to evolve a computerized process that will
effectively and efficiently capture the important objects associated
with result processing.
Amadin et al (2010) stated that “An effective measure which
can improve the efficiency of the result processing system is the
introduction of computerization”. They went on to say “A
majority of universities in Nigeria already have custom software
integrated into functional websites that helps in all aspects of
students registration activities (on-line application, entrance
examination results, registration of courses, payment of fees,
hostel allocation, amongst others), but what is still not resent in
most Nigerian Universities is a functional software or platform
that processes students examination results and
formats/edits/uploads them in the prescribed format on a
computer system or onto a computer network”. They highlighted
the importance of computerized result processing by the statement
“…having a qualitative standard of computing and presenting
undergraduate results in the academic world is better and it would
also increase the ability of students and affected staffs to
effectively use computers for their activities which is almost a
sine qua non in all professions today”.
Due to the importance and significance of a Result Processing
System, numerable work has been done on the subject previously.
We picked the most recent work we could get our hands on to
review in this article. Ukem and Ofoegbu (2012) employed the
use of MySQL and Java to develop an application which handled
user validation, students’ registration, course registration, course
assignment to lecturers, grade computation and Grade Point
Average and Cumulative Grade Point Average computation. This
system was reported to be successfully developed, tested and
found to be working as expected. However, the system is still
highly error-prone as data entry is done manually for each
individual and also makes it difficult for users to work offline, in
the case of a server failure. The absence of an audit trail also
makes the security of the system questionable as activities on the
application are left unmonitored.
In reviewing already-existing systems, it was discovered that
the common features in most of them is the problem of
duplication of effort in data entry and the absence of an audit trail.
An audit trail is a record showing who has accessed a computer
system and what operations he or she has performed during a
given period of time.
Thus, a Result Processing System was designed to address the
shortcomings inherent in manual processing as well as some of
the shortcomings of the very numerous systems developed before
it.
ABSTRACT
The aim of this paper is to report on the design, development and deployment of a Result Processing System to help process students’
results. This system was designed for the University of Nigeria, Nsukka. In developing this system, architectural design, UML class
diagrams, database design and human interface design were used. The tools that were used to develop this system are PHP, MySQL,
JavaScript, CSS, Html, Ajax, JQuery and Excel. The Result Processing System developed was able to take care of total score an d grade
computation, generation of relevant reports such as class list and student details, transcript generation, messaging system and audit trail. The
developed system; being modular does not just meet the needs of a specific University but can be adapted and used by other Institutions of
learning.
27
*Corresponding author. Email: idongesitessien@yahoo.com
1Department of Mathematics/Statistics & Computer Science, University of Calabar, Calabar, Nigeria
2iroegbuogechi@gmail.com
3Department of Computer Science, University of Nigeria, Nsukka
© 2013 International Journal of Natural and Applied Sciences (IJNAS). All rights reserved.
The system developed in this article has an audit trail so that
manipulation of students’ results cannot be easily done by
dishonest people as such actions can be easily traced by the
system administrator(s). The system is also designed to allow file
upload, as an Excel file, to the server and subsequently the file
content is saved to the database in order to reduce duplication of
effort in data entry. This also gives the user the option of working
offline on input data; he must not be online to get his work done.
Background
A student’s work in the University of Nigeria, Nsukka is presently
graded in the following letters and each of the letters carries the
following number of grade points:
Table 1. University of Nigeria Grading System
Percentage Score
Letter Grade
Points
Rating
70-100
A
5
Excellent
60-69
B
4
Very Good
50-59
C
3
Good
45-49
D
2
Fair
40-44
E
1
Pass
0-39
F
0
Fail
To determine the final grade a student receives in a
course at the end of a semester, 30% weight is given to
the continuous assessment and 70% to the semester
examination. At the end of each semester, a student’s
grade point average (GPA) is worked out. An example to
demonstrate how the GPA is calculated is shown below
in table 2. Suppose a student offered seven courses in the
first semester of his first year. Assuming he or she
obtains the following grades: A, B, A, C, D, E, F
respectively in the seven courses offered, his GPA would
be calculated as:
Table 2. GPA Calculation Example
Dept.
Course
No.
Course Title
Credit
Unit
Grade
Point
Grade Point
(GP)
COS
101
Intro. to Computer Science
2
A
5
5 x 2 = 10
MTH
111
Elementary Math. I
3
B
4
4 x 3 = 12
MTH
121
Elementary Math. II
3
A
5
5 x 3 = 15
PHY
104
Physics for Physical Sci. I
2
C
3
3 x 2 = 6
PHY
191
Practical Physics
2
D
2
2 x 2 = 4
STA
131
Inference I
2
E
1
1 x 2 = 2
GSP
101
Use of English I
2
F
0
0 x 2 = 0
16
49
GPA = Total Points / Total Credit Units
= 49 / 16
= 3.0625
= 3.06 to 2 d.p.
The following classes of degree and grades of diploma/certificate are awarded on the basis of the following cumulative grade
point averages:
28
Table 3. Classes of Degree
CGPA
Degree
Diploma/Certificate
4.50 – 5.00
1st Class Honors
Distinction
3.50 – 4.49
2nd Class Honors (Upper)
Credit
2.40 – 3.49
2nd Class Honors (Lower)
Merit
1.50 – 2.39
3rd Class Honors
Pass
1.00 – 1.49
Pass
Pass
0.00 – 0.90
Fail
Fail
The application developed in this article is a three-tier
client/server application. In the three-tier architecture, a
middle tier is between the client environment and the
server environment. For example, if you were trying to
access a website with a three-tier architecture type, your
computer (first tier) would connect to the website’s
database application (second tier). The database
application would then send a request, on your behalf, to
the main server (third tier). The main server would
process your request and forward it back to the database
application, which would then present the information to
you. For this application, the tools used to develop the
first tier are JavaScript, CSS, Html, Ajax and JQuery;
tool for the second tier is PHP and the tool for the third
tier is MySQL.
Fig. 1. Three-Tier Client/Server Architecture
Source: http://edn.embarcadero.com/article/10343
SYSTEM DESIGN AND METHODS The design methodology used to develop this
application is Object Oriented Analysis and Design
29
Methodology (OOADM). This software development
methodology involves three aspects: object-oriented
analysis (OOA), which deals with the design
requirements and overall architecture of a system, and is
focused on describing what the system should do in terms
of key objects in the problem domain; object-oriented
design (OOD), which translates a system architecture into
programming constructs (such as interfaces, classes, and
method descriptions); and object-oriented programming
(OOP), which implements these programming constructs.
Reasons for choosing OOADM are:
1. It cuts down development time and costs.
2. It is faster to implement and has significant
competitive advantage.
3. It enables producing more flexible, modifiable,
easily maintainable object-oriented systems.
Architectural Design: The architectural design enables
us to see a structural overview of the system; the access
points and functions of the system. The architectural
design below shows all the menu of functions a user
(irrespective of the access level) has after authentication.
LOGIN
MENU
UPDATE
EDIT & VIEW
RESULT
USER BIODATA
COURSE
DETAILS
STUDENT
BIODATA
STUDENT
COURSE
REGISTRATION
RESULT
BIODATA
COURSE
COURSE
ALLOCATION
COURSE
DETAILS
LECTURER
ASSIGN
COURSES
BIODATA
QUERYDATA ENTRY
LECTURER
BIODATA
STUDENT BIODATA
COURSE LIST
RESULT
REGISTRATION
RECORD
REPORT
RESULT
RESULT
TEMPLATE
CLASS LIST
TRANSCRIPT
BY COURSE
ADMIN
USER ACCOUNT
EDIT USER
CREATE USER
DEACTIVATE
USER
UNBLOCK USER
BLOCK USER
ACTIVATE USER
CREATE
SESSION
TRANSACTION
LOG
MESSAGING
HELP
ABOUT
Fig. 2. Architectural Design
Class Diagram
A class diagram is a type of static structure; a UML diagram
that describes the structure of a system by showing the system’s
classes, their attributes, and the relationships between the classes.
The diagram below shows all the classes, attributes and
relationships between classes for this application.
The UML representation of a class is a rectangle containing three
compartments stacked vertically. The top compartment shows the
class's name. The middle compartment lists the class's attributes.
The bottom compartment lists the class's operations.
The attributes and operations of the public visibility type have a
plus sign (+) in front of them while those of the private visibility
type have a minus sign (-) in front of them.
30
30
Class Session
-logged_in: bool
+admin_id: int
+username: int
+password: string
+surname: string
+first_name: string
+mid_name: string
+title: string
+dept_id: int
+sex: string
+a_level: string
+date_created: date
+date_expired: date
+active: int
+active_date: date
+message: string
__construct()
+is_logged_in(): bool
+full_name() : string
+in_use(admin_id): string
+login(user): bool
+not_active(): bool
+instantiate(): void
+logout(): void
+message(msg): string
-check_login(): bool
-check_message(): void
Class Dept
-table_name:string
-db_fields: string[]
+name: string
+fac_id: int
+dept_id: int
+aka: string
+duration: int
+admin_id: int
+get_faculty_name(dept_id): array
+get_dept_name(dept_id): string
+get_dept_duration(dept_id): int
+get_dept_id(dept): int
+get_all_dept(): string
+find_by_id(id): array
+find_by_sql(sql): array
-instantiate(record): array
-has_attribute(attribute): bool
-attributes(): array
-sanitized_attributes(): array
+save(): bool
+create(): bool
+update(): bool
+delete(dept_id): bool
Class Course
-table_name: string
-db_fields: string[]
+course_id: int
+cos_code: string
+dept_id: int
+title: string
+unit: int
+semester: int
+get_course_title(cos_code): string
+get_course_dept(cos_code): int
+get_all_dept_course(dept_id): string
+get_all_course(): string
+get_course_info(cos_code): string[]
+find_by_sql(sql): string[]
-instantiate(record): object
-has_attribute(attribute): bool
-attributes(): string[]
-sanitized_attributes(): string[]
+save(): bool
+create(): bool
+update(): bool
+delete(course_id): bool
Class Result
+table_name: string
-db_fields: string[]
+id: int
+cos_code: string
+reg_num: string
+admin_id: int
+level: int
+ca: int
+exam: int
+session: string
+get_allocated_course(admin_id): string[]
+get_active_session_for_course
(admin_id,level,course): string
+get_active_dept(admin_id): int
+get_all_allocation(dept_id): string[]
+get_single_result(reg_num,cos_code,
session): bool
+find_by_sql(sql): array
-instantiate(record): array
-has_attribute(attribute): bool
-attributes(): array
-sanitized_attributes(): array
+save(): bool
+create(): bool
+update(): bool
+delete(id): bool
Class Admin
-table_name: string
-db_fields: string[]
+admin_id: int
+username: string
+password: string
+surname: string
+first_name: string
+dept_id: int
+sex: string
+a_level: string
+date_created: date
+date_expired: date
+active: int
+in_use: bool
+get_fullname(admin_id): string
+update_account(): void
+authenticate(username,password): array
+find_all_admin(): array
+find_all_staff(): array
+find_by_id(id): array
+find_by_sql(sql): array
-instantiate(record): array
-has_attribute(attribute): bool
-attributes(): array
-sanitized_attributes(): array
+save(): bool
+create(): bool
+update(): bool
Class Student
-table_name: string
-db_fields: string[]
+student_id: int
+reg_num: string
+dept_id: int
+surname: string
+first_name: string
+mid_name: string
+sex: string
+d_o_b: date
+status: string
+state: string
+lga: string
+phone: string
+email: string
+mode_of_ad: string
+mode_of_study: string
+nationality: string
+address: string
+nok_name: string
+nok_phone: string
+nok_address: string
+relationship: string
+level: int
+get_profile(reg): string
+get_student_dept(reg_num): int
+get_student_level(reg_num): int
+find_all(level,dept): string
+find_by_id(id): string
+find_by_sql(sql): array
-instantiate(record): array
-has_attribute(attribute): array
-sanitized_attributes(): array
+save(): bool
+create(): bool
+update(): bool
+delete(student_id): bool
Class Upload
-table_name: string
-db_fields: string[]
+id: int
+filename: string
+type: string
+size: int
+caption: string
+upload_date: date
+username: string
+dept_id: int
+category: string
+status: string
-temp_path: string
+upload_dir: string
+errors: array
+upload_errors: string[]
+attach_file(file): bool
+save(): bool
+image_path(): string
+size_as_text(): int
+find_all_in_dept(level,dept_id,user): string
+find_by_id(id): string[]
+find_by_sql(sql): string[]
+count_all(): int
-instantiate(record): array
-has_attribute(attribute): bool
-attributes(): array
-sanitized_attributes(): string[]
+create(): bool
+update(): bool
+delete(id): bool
Class Ase ssion
-table_name:string
-db_fields: string[]
+session_id: int
+name: string
+all_session(): string
+find_by_sql(sql): string[]
-instantiate(record): object
-has_attribute(attribute): bool
-attributes(): string[]
-sanitized_attributes(): string[]
+delete(session_id): bool
+create(): bool
+update(): bool
Class Approve
-table_name: string
-db_fields: string[]
+approved_id: int
+dept_id: int
+cos_code: string
+level: int
+get_approved_course(dept_id,level): string
+find_by_sql(sql): string[]
-instantiate(record): array
-has_attribute(attribute): bool
-attributes(): string[]
-sanitized_attributes(): string[]
+save(): bool
+create(): bool
+update(): bool
+delete(approved_id): bool
Class Allocate
-table_name: string
-db_fields: string[]
+allocation_id: int
+dept_id: int
+admin_id: int
+cos_code: string
+allocated_dept: int
+session: string
+get_allocated_course(admin_id): string
+get_course_staff(cos_code,dept_id,session): int
+get_all_allocation(dept_id): string
+get_course_info(cos_code): string[]
+find_by_sql(sql): string[]
-instantiate(record): object
-has_attribute(attribute): bool
-attributes(): string[]
-sanitized_attributes(): string[]
+save(): bool
+create(): bool
+update(): bool
+delete(approved_id): bool
Class MySQLDatabase
-connection: resID
+last_query: string
-magic_quotes_active: bool
-real_escape_string_exists: bool
__construct(): void
+open_connection(): void
+close_connection(): void
+query(sql): resID
+escape_value(value): string
+fetch_array(result_set): array
+num_rows(result_set): int
+insert_id(): int
+affected_rows(): int
+confirm_query(result): void
Class Me ssage
No variables
+newMsg( recipient,message_id,topic):
string
+getMsgId(username,tbl): int[]
+getMsgs( message_id): string[]
+getDraft(message_id): string[]
+fnMulSent(userNames): string[]
+getMsgBody(message_id): string[]
+getSender(message): string[]
+del_Msg(from,message_id): string
+getInboxCount(username): int
+sendMsg(recipient,sender,topic,body):
string
+getRecipient(message_id): string
+saveDraft(username,topic,body): string
+displayMessage(messages,from): void
+displayDraft(messages): void
+display_msg(msg): void
+showMsgBody(message_id,from): void
Class Pagination
+current_page: int
+per-page: int
+total_count: int
__construct(page,per_page,total_count)
+offset(): int
+total_pages(): int
+previous_page(): int
+next_page(): int
+has_previous_page(): bool
+has_next_page(): bool
Fig. 3. UML Class Diagram
Database design
The database design describes how data is represented and used. This application has one database called rps with
nineteen (19) relational tables hosted on MS-SQL Server 2005. The structure is shown below, the items underlined once
indicate the primary field of each table and the items underlined twice are the secondary field(s) of each table.
31
session_id auto
name text
session
message_id auto
topic text
body text
date datetime
message
serial auto
message_id numeric
username text
del_code bool
draft
serial auto
message_id numeric
username text
sender text
del_code bool
read_code bool
inbox
serial auto
message_id numeric
username text
del_code bool
sent
admi n_id auto
dept_id numeric
username text
password text
surname text
first_name text
sex text
a_level text
date_created date
date_expired date
active bool
in_use bool
admins
allocation_id auto
admin_id numeric
cos_code text
dept_id numeric
session text
allocation
course_id auto
cos_code text
dept_id numeric
title text
unit numeric
semeste r numeric
course
dept_id auto
fac_id numeric
name text
aka text
duration numeric
admin_id numeric
dept
approved_id auto
cos_code text
dept_id num eric
leve l numeri c
appro ved
id auto
filename text
type text
size numeric
caption text
upload_date datetime
username text
dept_id numeric
category text
status bool
files
staff_id auto
surname text
first_name text
dept_id numeric
username text
password text
sex text
date_created datetime
date_expired datetime
staff
fac_id auto
name text
faculty
serial auto
dept_id numeric
level nume ric
semester numeric
session tex t
course_code text
prospectus
student_id auto
reg_num text
dept_id numeric
level nu meric
surname text
first_name text
mid_name text
sex text
d_o_b date
status text
states text
lga text
phone text
email text
mode_of_ad text
nationality te xt
mode_of_study text
address text
nok_name text
relationshi p text
nok_phone text
nok_address text
student
reg _id auto
cos_cod e te xt
reg _nu m te xt
se ssi on text
reg
id auto
cos_code text
reg_num text
level nume ric
session tex t
ca numeric
exam numeric
admin_id numeric
result
state_id auto
name text
states
lga_id auto
name text
state_id numeric
lga
Fig. 4. Database Design
Human Interface Design
This shows the interface or interaction between the user and the computer system. The human interface design for this
system is very user friendly and easy to understand and use. Some samples of the human interface design are shown below:
32
Fig. 5. Login page
Fig. 6. Home page for staff access level
33
RESULTS
A Result Processing System was designed, implemented and tested
which can perform the following functions:
1. Calculate the total score and grade in a given course given
the required parameters which are the continuous
assessment score and exam score. This computation is done
at the point of result download and thus, is not stored on the
database. Hence, reducing the risk of grade manipulation.
2. Lecturers prepare their course results (without the total
scores and grades) on a given MS-Excel template and then
upload the file to the server and subsequently, the file is
saved to the database. This allows the lecturers to work on
students’ results offline. Also, to ensure the security of the
application, upload of any file which is not an MS-Excel
2007 file is prohibited.
3. Mostly data entry is done by uploading the concerned file to
the server. This helps check errors during data entry, as the
data is first entered into an Excel spreadsheet and cross-
checked before being saved to the database. It also
eliminates duplication of effort in data entry. Input data can
also be gotten from the user through forms on the
application, as the user may need to enter data individually.
4. Generation of students’ transcript up to the present level,
which is also done at the point of transcript download.
5. Different user types have different access levels which helps
to monitor the roles different levels of admin can handle.
Password encryption policy was also implemented, to help
improve the security of the application.
6. Audit trail was also implemented so that activities on the
application can be traced by the system administrator(s).
7. Single login was implemented. This means that once an
admin is logged in, he or she cannot log in again till he or
she logs out. This was implemented because it was observed
that a multiple access system could make it difficult to
actually keep track of when the person using an account is
exactly the intended admin. This policy makes it easier to
hold an admin responsible for the actions performed by his
or her account.
8. Generation of important reports such as students’ details,
lecturers’ details, class lists, course lists, result sheets and
transcripts.
9. Messaging system to aid information transfer within the
administrative body.
CONCLUSION
The introduction of a computerized method of result processing
solves a lot, if not all, of the problems inherent in the manual method
of result processing. It narrows down result processing and data
handling to just “a click on the mouse button”, thereby making work
faster, more efficient and more effective. And for this reason, the
implementation and use of this application becomes necessary. Over
time, the feasibility of a perfectly working Result Processing System
has been a source of concern to academic bodies. Due to some
uncontrolled factors such as non-payment or late payment of school
fees, inconsistent administrative policies and power failure, the
possibility of realizing such achievement is threatened. Thus just as
human beings, all we can achieve is a “near-perfect” system.
REFERENCES
Amadin, F.I. (2010). Undergraduate Students’ Results
Processing System, Journal of Communication and Computer
Volume 7 No. 10
Bamigbola, O.M. (1997). An Object-Oriented Software Model.
for Students’ Registration and Examination Result Processing
in Nigerian Tertiary Institutions,.
Nnabuko U.C. (2011) Result Processing System. A final year
project in the Department of Computer Science, University of
Nigeria, Nsukka.
Ukem, E and Ofoegbu (2012). A Software Application for
University Students Results Processing, Journal of Theoretical
and Applied Information Technology Volume 35 No. 1
UML basics: The class diagram. Available on:
http://www.ibm.com/developerworks/rational/library/content/Rational
Edge/sep04/bell/
University of Nigeria, Nsukka, Calendar 2007-2009, pages 47, 187-
188, 210.
Wikipedia, “Client-server model”, (2010). Available on:
http://en.wikipedia.org/wiki/Client-server_model
Wikipedia, “Object-oriented design”, (2011). Available on:
http://en.wikipedia.org/wiki/Object-oriented_design
34