SCHOOL MANAGEMENT SYSTEM

By Degif Teka
A Project paper submitted to the School of Graduate Studies of Addis Ababa Unive
rsity in partial fulfillment of the requirements for the Degree of Master of Sci
ence in Computer Science
June 2008

ADDIS ABABA UNIVERSITY SCHOOL OF GRADUATE STUDIES FACULTY OF INFORMATICS DEPARTM

ENT OF COMPUTER SCIENCE
SCHOOL MANAGEMENT SYSTEM
By Degif Teka
Name and Signature of members of the Examining Board: 1. Dr. Dida Midekso, Advis
or 2. ______________________ 3. ______________________ ________________________
________________________ ________________________
- ii -

Acknowledgements
I would like to express my gratitude to my advisor Dr. Dida Midekso for his guid
ance, support and his continuous enthusiasm and encouragement throughout the pro
ject. I am also very grateful and extend my sincere thanks to the principals and
staff members of the department of mathematics at Kokebe Tsibah Secondary Schoo
l for their cooperation by sharing the load that I was teaching to make me have
time to work on this project and throughout my study. Finally many thanks to fri
ends, who have helped and given me suggestions, supports and corrections through
out the project.
- iii -

Table of Contents
Chapter 1 Introduction .........................................................
.......................................................... 1 1.1 Background.....
................................................................................
................................. 1 1.2 Statement of the Problem................
................................................................................
. 2 1.3 Objective...............................................................
........................................................... 3 1.3.1 General Obje
ctive ..........................................................................
.......................... 3 1.3.2 Specific Objectives .........................
......................................................................... 3 1.4
Organization of the Document....................................................
..................................... 3 Chapter 2 Overview of the School Managem
ent System .............................................................. 4 2.1
Secondary School in Ethiopia....................................................
...................................... 4 2.2 The Timetabling Problem ...........
................................................................................
..... 5 2.2.1 Time Slot Assignment .............................................
................................................ 6 Chapter 3 Literature Review..
................................................................................
........................ 9 3.1 Observed Products ...............................
............................................................................ 9 3
.2 Manual Timetabling...........................................................
............................................ 10 3.3 Drawbacks of the Reviewed Sy
stems...........................................................................
. 10 Chapter 4 System Analysis .................................................
......................................................... 12 4.1 Functional Requ
irements .......................................................................
........................ 12 4.2 Non Functional Requirements ....................
................................................................... 12 4.3 Analy
sis Model ......................................................................
........................................ 13 4.3.1 Use case Diagram .............
................................................................................
..... 13 4.3.2 Actor Description................................................
................................................... 15 4.3.3 Use Case Descriptio
n...............................................................................
.............. 16 4.3.4 Sequence Diagrams.......................................
......................................................... 21 Chapter 5 System De
sign............................................................................
................................. 26 5.1 Design Goals...........................
................................................................................
....... 26 5.1.1 Performance Criteria...........................................
................................................... 26 5.1.2 Dependability......
................................................................................
................... 27 5.1.3 Maintenance........................................
................................................................... 27 5.1.4 End
User Criteria .................................................................
.................................. 27 5.2 Architecture of the System ...........
................................................................................
. 28 5.3 Subsystem Decomposition................................................
............................................. 29 5.4 Hardware/Software Mapping..
................................................................................
....... 32 5.5 Persistent Data Management ......................................
................................................... 34 5.5.1 Mapping ...........
................................................................................
...................... 34 5.5.2 Relationships among Tables .....................
............................................................. 34 5.6 Algorithmic
Design for the Timetable.......................................................
.................... 38 Chapter 6 Implementation ...............................
............................................................................ 43

6.1 Programming Tool............................................................

............................................. 43 6.2 The SMS Prototype..........
................................................................................
.............. 43 Chapter 7 Conclusion and Recommendations .....................
........................................................ 52 7.1 Conclusion .....
................................................................................
................................ 52 7.2 Recommendations.........................
................................................................................
. 53 References.................................................................
..................................................................... 54 Declara
tion............................................................................
......... Error! Bookmark not defined. - iv -

List of Tables
Table 2.1 Sample timetable displayed in a grid..................................
.................................7 Table 2.2 A typical time grid with five days
and seven time slots a day ............................7 Table 5.1 Number of les
sons for each subject ..........................................................
.........38 Table 5.2 An example of the relationship among classes, subjects and
teachers ..............39 Table 5.3 An example of time slot assignment.........
.........................................................40
-v-

List of Figures
Figure 2.1 Concepts of timetabling construction at schools......................
..........................6 Figure 4.1 Use Case diagram of the SMS..............
............................................................13 Figure 4.2 Sequen
ce diagram for student registration ............................................
...........20 Figure 4.3 Sequence diagram for recording attendance .............
.......................................21 Figure 4.4 Sequence diagram for transc
ript generation.....................................................22 Figure 4.
5 Sequence diagram for viewing student status ..................................
................23 Figure 4.6 Sequence diagram for timetable generation ........
.............................................24 Figure 5.1 Architecture of the s
ystem...........................................................................
.....28 Figure 5.2 Layered representation of the system.........................
......................................30 Figure 5.3 Subsystem decomposition diag
ram ..................................................................31 Figure
5.4 Deployment diagram of the system............................................
......................32 Figure 5.5 Mapping objects into Tables ................
............................................................35 Figure 5.6 Relati
onship diagram of the tables ...................................................
................36 Figure 6.1 Login Screen......................................
...............................................................44 Figure 6.2 Spl
ash screen .....................................................................
...............................44 Figure 6.3 Main menu..........................
..............................................................................45
Figure 6.4 Screen shot of student registration ................................
...................................45 Figure 6.5 Parental and Emergency form ...
.......................................................................46 Figure
6.6 Screen shot of report card.................................................
................................47 Figure 6.7 Screen shot of the timetable .....
........................................................................48 Figur
e 6.8 Timetable for one class/section ..........................................
..............................49 Figure 6.9 Timetable for a teacher.............
........................................................................49 Figur
e 6.9 Screen shot of attendance recording page .................................
.......................50 Figure 6.10 Screen shot of a page displayed for parent
s ...................................................51
- vi -

Abbreviations
SMS: School management system ASP: Active Server Page CGAAEB: City Government of
Addis Ababa Education Bureau
SQL: Structured Query Language DBMS: IIS: Database management system
Internet Information Service
HTTP: Hyper Text Transfer Protocol
- vii -

Abstract
This project work automates school management system. In the system two applicat
ions are developed, Windows based (thick client) and Web based (thin client). Th
e windows application takes most of the activities such as offline student regis
tering, transcript and report card generation and producing the timetable. The w
eb application facilitates attendance recording by the homeroom teachers, to vie
w status of students by their parents and to view reports by kebele and kifle-ke
tema education bureau officials. Our solution of the timetable is very simple. I
n the high school considered for the project there are ten subjects for both gra
de nine and grade ten. Loads are assigned to each subject teacher and a code is
given for each teacher-subject combination. A simple search technique has been u
sed during allocation of each teacher-subject code to a time slot. A database ha
s been used to enforce constraints and to store data. The prototype has been tes
ted with data from Kokebe Tsebah Secondary School. It has been observed that the
system successfully registers students, facilitates attendance recording by the
home room teachers and generates various reports such as report card, transcrip
t and a feasible timetable satisfying the constraints (requirements). It has als
o been shown that the system facilitates to view the status of students by their
parents using the Internet or Intranet of the school.
- viii -

Chapter 1 Introduction
1.1 Background
Education system forms the backbone of every nation. And hence it is important t
o provide a strong educational foundation to the young generation to ensure the
development of open-minded global citizens securing the future for everyone. Adv
anced technology available today can play a crucial role in streamlining educati
on-related processes to promote solidarity among students, teachers, parents and
the school staff. Education is central to development. It is one of the most po
werful instruments for reducing poverty and inequality and lays a foundation for
sustained economic growth. With this aim currently our government has given spe
cial emphasis to the educational sector and school improvement activities such a
s continuous professional development for teachers, training and upgrading teach
ers and capacitating schools with manpower and materials are among the major act
ions which have been taken in both primary and secondary schools. In order to fa
cilitate and simplify these actions one of the major tool is to have automated s
chool management system. School Management System(SMS) consists of tasks such as
registering students, attendance record keeping to control absentees, producing
report cards, producing official transcript,
preparing timetable and producing different reports for teachers, parents, offic
ials from kebele or kefle ketema education bureaus and other stakeholders. Autom
ation is the utilization of technology to replace human with a machine that can
perform more quickly and more continuously [2]. By automating SMS documents that
took up many large storage rooms can be stored on few disks. Transcript images
can be annotated. It reduces the time to retrieve old transcripts from hours to
seconds. However, the school system in the government schools of Addis Ababa is
not automated and the record officers generate transcripts and reports manually
and the school administrators use their experienced knowledge of miss and hit ap
proaches to prepare timetables.
-1-

1.2
Statement of the Problem
To help promote students achievement and success, schools must have access to co
mplete, accurate, and timely information about students. One of the benefits of
automated SMS is that the student record system will simplify retrieval of requi
red information and is a great instrument for school improvement by taking measu
res from the information acquired. Despite the use of automated SMS, the governm
ent schools in Addis Ababa are using paper based documentation system for perfor
ming various tasks and the school administrators apply their knowledge of hit an
d miss approach in scheduling classes and courses (preparing the timetable) whic
h wastes manpower and much time unnecessarily that does not utilize the current
technology. Transcripts of students are prepared manually by the record officer
and teachers. Report cards are produced by the home-room teachers. Attendance of
students is recorded by the home-room teachers. In order to control absentees a
nd know the number of days that a student has been absent from the school during
the school days the attendance officer has to collect the attendance slips from
the corresponding homeroom teachers and compile it which is also a time taking
process. In addition to that retrieving records of students who have graduated c
ouple of years ago has been a difficult task and the manual system also has diff
iculty of producing different reports which are required by the stakeholders suc
h as teachers, administrators or officials from kebele and kifle-ketema. Teacher
s may want to associate a student with his parent or emergency persons for disci
plinary measures which need searching of the students record in the record offic
e. It has been difficult to search a record from thousands of such records and o
bserved that students can take any person claiming that he/she is their parent o
r emergency person which creates problem in control of students. Due to the inef
ficiency of the current manual system, the need arises to automate SMS in order
to efficiently handle students attendance, to produce transcript, report cards an
d the various reports satisfying users and customers and to produce timetable wh
ich can schedule courses for teachers and classes of students.
-2-

1.3
Objective
The general and specific objectives of the project are described below:
1.3.1 General Objective
The general objective of the project is to automate the SMS.
1.3.2 Specific Objectives
In order to attain the general objective, the following list of specific objecti
ves is set: To develop an offline registration system, To facilitate attendance
record keeping, To facilitate various report generation, To allow teachers, pare
nts, school community and Education bureau officials to view reports on students
, To produce a timetable
1.4
Organization of the Document
This report document contains seven chapters including this chapter. Chapter two
defines and describes concepts with regard to SMS, aiming to give a general vie
w to the reader of the document about tasks or activities which need automation
in the school environment. Chapter three presents review of research works on SM
S. In chapters four and five, we presented the analysis and design of the develo
ped system respectively. In the remaining chapters, prototype development and co
nclusion and recommendations are briefly explained.
-3-

Chapter 2
Overview of the School Management System
This project emphasizes on school management system in Ethiopian secondary schoo
ls. Therefore, we give an overview of the management system of secondary schools
in Ethiopia.
2.1
Secondary School in Ethiopia
Secondary education follows eight years of primary education and is for children
aged 14 and above. At the beginning of each academic year which starts in Septe
mber (Ethiopian New Year), the students get registered and assigned rooms. Each
class (section) of students is assigned to a fixed room. Home room teachers are
assigned to each class of students. There are two semesters per year. The first
semester final examination is usually administered during January, the second se
mester final examination is administered during the end of June and consequently
the results of each class of students is collected, organized, ranked by the co
rresponding home room teacher and reported to each student. The homeroom teacher
also records attendance of each student on each school day which is later organ
ized by the attendance officer. A student who has been absent for more than twen
ty days is not allowed to take a semester final examination and will be forced t
o withdraw. Transcripts are generated by the record officer. A student may reque
st transcript when he/she wants to transfer to other school or when he/she has c
ompleted/graduated from the school and needs to join higher education or for som
e other purpose. Officials from kebele and kifle-ketema education bureaus want t
o get statistical reports like number of registered students at the beginning of
every year, number of drop outs, and number of passes/failures for each subject
at the end of each semester as well as number of passes/failures at a grade lev
el to help them participate in decision making.
-4-

2.2
The Timetabling Problem
School timetabling is a major administrative activity in any school. A number of
subjects taught by the corresponding teachers are allocated into a number of av
ailable classrooms and a number of timeslots, subject to constraints. The tasks
that are considered in constructing the timetable are: Assigning periods to clas
ses. There is a need to spread out lessons across the teaching cycle as much as
possible, e.g. to avoid having 3 lessons on the same day. Some classes need dou
ble periods (preferably 2 consecutive periods). This happens currently for Math
ematics and English since each of the subjects have 6 lessons per week (for five
days) and therefore on one of the days these subjects should have two lessons f
or each class of students. Some combinations of assignments lead to acceptable t
imetables, others do not. Such restrictions follow from conditions imposed by cl
asses (rooms), students or teachers. We distinguish two types of conditions: con
ditions that must be met (requirements) and conditions that should be fulfilled
as well as possible (desires) [5]. A class of students has a fixed room througho
ut the academic year and therefore we use class and room alternatively. Here a r
oom is mentioned only when there are students in it. The time tabling problem is
said to be feasible if and only if it satisfies the following constraints (requ
irements): Every teacher and every class must be present in the timetable in a p
redefined number of periods; There can not be more than one teacher in the same
class at the same period; No teacher can be assigned to more than one class at t
he same time; There can be no "uncovered periods" (that is, periods when no teac
her has been assigned to a class).
-5-

Violation of the constraints leads to an infeasible solution which usually happe

ns in the manual preparation of the timetable. Therefore, these constraints have
to be satisfied in order to get a feasible solution.
2.2.1 Time Slot Assignment
The school timetabling is a weekly scheduling for all the classes of a school, a
voiding teachers meeting two classes at the same time, and vice versa. This mean
s that an event may be placed in the timetable only in such a way that it does n
ot violate constraints. Figure 2.1 shows the concepts of timetable construction
at schools. Lessons in a subject are taught by a teacher to a corresponding clas
s of students and the timetabling problem is a problem of allocating resources,
i.e. assigning to teachers and class of students, time slots and lessons [3, 4].
A time slot is a period and a lesson is an event associating a teacher, a subje
ct and a class of students with in a time slot.
Subject
Teacher
Lesson
Room
Time Slot
Figure 2.1 Concept of timetabling
construction at schools
Timetabling is based on a rectangular time grid that divides the planning period
into disjoint time intervals of equal duration (42 minutes in this case) which
are called time slots or simply periods. Table 2.1 shows a typical time grid wit
h one day (Monday) for all possible classrooms (ri) and seven time slots a day.
-6-

Table 2.1 Timetable for one day (Monday) of the five days . r1 r2 r5 p1 e1 e22 e
6 p2 e3 e5 e7 p3 e8 e10 e15 p4 e12 e34 e20 p5 e32 e27 e24 p6 e26 e19 e25 p7 e28
e21 e29
Monday
.. . . . . .
rn e9 e18 e11 e17 e23 e35
If there are m classes i=1,,m, n teachers j=1,,n, and T timeslots t=0,,T-1., then t
he total number (rij) of lectures which is commonly called load of the teacher i
s known in advance. Each lecture takes one time slot.
Currently in the government high schools in Ethiopia, there are five school days
from Monday to Friday and there are seven periods per each school day. A time t
able for each class or teacher could be prepared on a grid as shown in table 2.2
. A cell in the grid represents teacher and subject combination in the case of c
lass/section time grid and the class that a teacher teaches in the case of a tea
cher time grid.
Table 2.2 Typical time grid with five days and seven time slots a day Monday Tue
sday Wednesday Thursday p1 p2 p3 p4 p5 p6 p7
Friday
-7-

The lectures are activities and teachers and classes are resources. These resour
ces are not available at certain time periods. A lecture can be given in period
t only if the corresponding class and teacher are available in t [1]. All lectur
es have equal processing length, i.e. the length of the period and have to be sc
heduled without preemption.
To automate the school activities some literature reviews have been done. The li
terature reviews is discussed in chapter 3.
-8-

Chapter 3 Literature Review

Automated SMS plays a great role in simplifying the job of employees at the scho
ol and satisfying the need of customers and stakeholders of the school. Even tho
ugh no documentation is found in Ethiopia to be reviewed, products have been obs
erved at some schools to help understand the problem of managing schools and han
dling school data. This chapter reviews these products.
3.1
Observed Products
In the year 2003 City Government of Addis Ababa Education Bureau (CGAAEB) was ve
ry much interested to have automated school management system to get uniform and
quick access to the students data for administrative purpose on promoting the st
udents achievement and related issues. The bureau has selected Wundrad Preparator
y School for pilot test. At the time the school principals together with officia
ls from CGAAEB signed a contractual agreement with some software developer compa
ny. The developers installed their first version of the product which can regist
er a student offline and generate official transcript with some level of difficu
lty. As the system is not fully automated, it does not support management of att
endance, does not support generating report cards and other important functions
such as generating school timetable and a web based report for parents. Due to t
he lack of follow up by the government officials at CGAAEB, the company was unab
le to complete the project. The school currently is unable to use the partially
developed system because of lack of trained person and lack of hardware and soft
ware maintenance. Another product that is in use is transcript generator system.
The transcript generator system at Menelik II Preparatory School generates offi
cial transcript of students. In order to generate transcript the record officer
enters the student information along with the grade marks for the grades complet
ed per year and per semester. Then the system generates the required official tr
anscript. Currently the school is using the system to generate official transcri
pt even though the data entry format has unnecessarily many fields which are not
applicable for the record office but can be used for continuous assessment by t
he course teacher. -9-

3.2
Manual Timetabling
Manual timetables are prepared by dedicated teachers. In manual timetabling, it
is common to proceed in an iterative fashion where each iteration selects and sc
hedules a lesson [3]. Scheduling a lesson requires to choose a classroom (fixed
for each section of students) and a time slot such that the commitment to the ch
oice will not violate any constraint. In school timetabling, we are required to
schedule a given set of meetings such that the resulting timetables are feasible
and acceptable to all people involved. Humans are able to prepare the timetable
using some hit/miss approach. So it is possible to automate the timetable based
on a simulation of the human way of solving the problem. Such techniques, that
we call direct heuristics, were based on a successive augmentation. That is, a p
artial timetable is extended, lecture by lecture, until all lectures have been s
cheduled. The underlying idea of all approaches is to schedule the most constrai
ned lecture first. Usually some responsible teachers are assigned to schedule su
bjects and teachers. The number of teachers available per each subject is predef
ined and the load that each teacher has is calculated. With these data the timet
able constructor assigns each teacher-subject association to the appropriate cla
sses with the available time slots. The manual solution of the timetabling probl
em usually requires many person-days of work. In addition, the solution obtained
may be unsatisfactory. The lessons should be fairly distributed satisfying the
identified constraints.
3.3
Drawbacks of the Reviewed Systems
The reviews described have the following problems: Generate official transcript
with some level of difficulty, Do not sufficiently produce the required reports
to allow parents to view status of their children and reports for officials of k
ebele and kifle-ketema to help them participate in decision making,
- 10 -


Do not generate timetable for the schools Do not facilitate attendance record ke
eping by the homeroom teachers
This project work tries to fill the gap by automating the various activities at
schools. It tries to satisfy customers need and simplify the works of administra
tors, record officer and teachers. With an automated school management system pa
rents can easily interact with the school community to follow up their childrens
achievement and play their role in the school development processes.
- 11 -

Chapter 4 System Analysis

In this chapter the functional and non-functional requirements of the system are
described and modeled using UML models.
4.1
Functional Requirements
The functional requirements of the system are: register a student, record attend
ance of students, generate various reports, generate timetable.
4.2
Non Functional Requirements
Security requirements are important factors in this system as classified data wi
ll be stored in the database. User validation will be done during login to insur
e that the user is valid and that the user only has access to his or her permiss
ion data. General users will only have access through the user interface. The sy
stem will have consistent interface formats and button sets for all forms in the
application, will have a form based interface for all data entry and viewing fo
rmats, and will generate reports that are formatted in a table and that should l
ook like the existing manual report formats for user friendliness. The system wi
ll be easily maintained by the developer or other authorized trained person and
it shall respond as fast as possible in generating report and producing the time
table.
- 12 -

4.3
Analysis Model
To produce a model of the system which is correct, complete and consistent we ne
ed to construct the analysis model which focuses on structuring and formalizing
the requirements of the system. Analysis model contains three models: functional
, object and dynamic models. The functional model can be described by use case d
iagrams. Class diagrams describe the object model. Dynamic model can also be des
cribed in terms of sequence, state chart and activity diagrams. For the purpose
of this project we have described the analysis model in terms of the functional
model and dynamic models using use case and sequence diagrams.

4.3.1 Use case Diagram

Use cases of the system are identified to be RegisterStudent, RecordAttendance, Gener
ateTranscript, GenerateReportCard, ViewReport and ProduceTimetable. The diagram depict
d in Figure 4.1 shows the use case diagram of the system.
- 13 -

RegisterStudent RegisterStudent
UpdateRecord
RecordOfficer
GenerateTranscript
GenerateReportCard
HomeRoomTeach er
RecordAttendance
ViewReport Parent
Official
GenerateTimetable Admin
Figure 4.1 Use Case Diagram of the SMS
- 14 -

4.3.2 Actor Description

Name: RecordOfficer Description: A RecordOfficer is a person who registers a stu
dent, input, update student data and produce transcript and report card. Name: H
omeRoomTeacher Description: A HomeRoomTeacher is a teacher assigned by the schoo
l director to each class of students to follow the students closely. He/She has
the responsibility of recording attendance of students and submitting. Name: Par
ent Description: A Parent is a person who is registered as parent of the student
and responsible to follow the student in close contact with the school. He/She
can view the status of the student such as attendance and result/performance of
the student online. Name: Official Description: An Official is a person who is r
egistered as a legal concerned official from kebele or kifle-ketema to get repor
ts on students of the school. He/She will be viewing the report online. Name: Ad
min Description: Admin is a person who is responsible to produce the timetable f
or each teacher and classroom by providing the necessary parameters.
- 15 -

4.3.3 Use Case Description

Name: Actors: Description: Precondition: RegisterStudent RecordOfficer To regist
er some one as a student of the school A student has to be eligible (has to be f
rom the pre-specified junior schools that the school will accept)
Flow of Event: (1) student wants to be registered as a student of the school (2)
Record officer verifies that the student is eligible (3) Registration form will
be given to the student (4) The student completes the registration form that co
ntains students full name, address, parent name, emergency person names and addre
sses and other detail information. (5) RecordOfficer of the school checks whethe
r the contents of the registration form is properly completed (6) RecordOfficer
fills and submits the form to the system (7) System registers (8) Use case ends
Post Condition: Name: Actors: Description: Student Registered RecordAttendance H
omeRoomTeacher To record attendance of students in each school day
- 16 -

Precondition:
A home room teacher must login as the home room teacher of the class to record a
ttendance
Flow of Event: (1) A home room teacher wants to record absentees from the class
(2) The home room teacher fills in the attendance slip in the class room (3) Hav
ing the attendance slip the home room teacher logs in to record (4) HomeRoomTeac
her records absentees and submits (5) System acknowledges (6) Use case ends Alte
rnative Flow of Events Alternative flow A: User is not a home room teacher of th
e class
A3. User cant record attendance for the required class of students A4. Use case e
nds Name: Actors: Description: Precondition: Flow of Events: (1) The record offi
cer logs in and selects the class/section to which the student belongs (2) The r
ecord officer searches the student from the class/section based on the search cr
iteria defined (3) The system processes the report card (4) System displays and
print the result GenerateReportCard RecordOfficer To produce a report card for s
tudents per semester A student must have complete grade marks in all subjects of
the semester
- 17 -

(5) Use case ends Alternative Flow of Events Alternative flow A: The user logged
in is not the record officer
A1. User can not generate report card A2. Use case ends Alternative flow B: The
student is incomplete at least in one subject B3. The system can not generate th
e report card. B4. Use case ends Name: Actors: Description: Precondition: Flow o
f Event: (1) A student wants to get transcript (2) The record officer logs in an
d searches the students record from the database based on the search criteria (3
) The system processes the transcript (4) System displays and print the result (
5) Use case ends Alternative Flow of Events Alternative flow A: The student is i
ncomplete at least in one subject GenerateTranscript RecordOfficer To produce tr
anscript based on the request of a student A student must have completed at leas
t a semester to have grade report
- 18 -

A3. The system can not generate transcript A4. Use case ends
Name: Actors: Description: Precondition:
GenerateTimetable Admin To generate timetable for teachers and classes There sho
uld be subject teachers and classes for which the timetable is to be produced
Flow of Event: (1) Admin wants to generate timetable (2) Admin logs in (3) Admin
registers teachers (4) Admin assign classes for each subject teacher by filling
a form and then submits it (5) The system generates the timetable (6) System di
splays the result (7) Use case ends Alternative Flow of Events Alternative flow
A: No teacher is registered to be assigned to classes
A5. The system can not generate timetable A6. Use case ends
- 19 -

Name: Actors: Description: Precondition: Flow of Event:

ViewReport Parent To view the status of a student A parent must be recorded in t
he system as parent of the student
(1) A parent wants to view status of his/her student (2) Parent logs in to the s
ystem supplying user name and password (3) System displays a form for search cri
teria for a student (4) Parent fills in the form and submit (5) Parent selects t
o view the required report (6) System displays the appropriate report (7) Use ca
se ends Alternative Flow of Events Alternative flow A: Parent is not recorded as
parent of a student A2. The parent can not login A3. Use case ends Alternative
flow B: parent is unable to give appropriate name and Id number of a student B5.
System can not display the students information B6. Use case ends
- 20 -

4.3.4 Sequence Diagrams

Sequence diagrams show the interaction between participating objects in a given
use case. They are helpful to identify the missing objects that are not identifi
ed in the analysis object model. To see the interaction between objects, the fol
lowing describe the sequence diagram of each identified use cases. In Figure 4.2
below, once the user has activated the registeration module by interacting with
the boundary object NewRegisterationButton button, the control object named
RegisterationControl manages the activities involved in registerStudent use case. Fi
rst the RegisterationControl creates registeration form which will be filled by th
e secretary and submitted. The registration control sends the record to a persis
tent storage. The sequence diagrams for RecordAttendance, GenerateTranscript, ViewRep
ort and GenerateTimetable use cases are shown in figures 4.3, 4.4, 4.5 and 4.6 resp
ectively.
:
:RecordOfficer
NewRegistrationButt on <<UI>>
Create()
:RegistrationControll
:Registration Form
<<UI>>
Press Button()
Create()
Fill() Submit() Validate() Acknowledge()
Figure 4.2 Sequence Diagram for Student Registration - 21 -

: HomeRoom_ Teacher<<actor>>
U U
:RecordAttentandance_ Button
:Attendance Control
:LoginForm
:AttendanceRecord_ Form
1: PressButton()
2: Create()
3: Display()
4: FillData() 5: Submit()
6: Validate()
7: Display() 8: Validate() 9: FillData() 10: Submit() 11: SubmitForm()
12: Acknowledge()
Figure 4.3 Sequence Diagram for Recording Attendance
- 22 -

:RecorOfficer
:Transcript Button <<UI>> Create()
:TranscriptController
:SelectYearGSection&SemForm <<UI>>
Transcript
Press Button ()
Create()
Fill data() submit() Validate() acknowledge () Generate()
Figure 4.4. Sequence Diagram for Transcript Generation
- 23 -

: Parent_ <<actor>>
ViewStudentStatus_ :StudentStatus Control Button
:LoginForm
:StudentStatusReport :ReportForm
1: PressButton()
2: Create()
3: Display()
4: FillData() 5: Submit()
6: Validate() 7: Display() 8: Validate()
9: FillData() 10: Submit() 11: SubmitForm()
12: GenerateReport()
Figure 4.5 Sequence Diagram for viewing student status by the parent
- 24 -

:Admin
:ProcessButton <<UI>>
Press Button
:TimetableControl
:GenerateTimetable Form <<UI>>
:Timetable
Create()
Display()
FillData() Submit() Validate()
Create()
Acknowledge()
Figure 4.6 Sequence Diagram for generating Timetable
- 25 -

Chapter 5 System Design

In the previous chapter we have identified the functional and non-functional req
uirements of the system and produced the analysis model. The following are discu
ssed in this chapter: design goals, system architecture, system decomposition, d
eployment and database design.
5.1
Design Goals
Design goals describe the qualities of the system that developers should optimiz
e. Such goals are normally derived from the non-functional requirements of the s
ystem. Design goals are grouped into five categories. These are Performance Depe
ndability Maintenance End User Criteria
5.1.1 Performance Criteria
The part of the system to be used for the record office should have a fast respo
nse time (real time) with maximum throughput. Furthermore, the system should not
be taking up too much space in memory. The record officer has chosen fast respo
nse time over throughput and hence the system should try to be more interactive.
In the case of the timetabling subsystem, the system should be more reliable in
order to satisfy the constraints than fast response time.
- 26 -

5.1.2 Dependability
The school needs the system to be highly dependable as it is expected to be used
by nonIT professionals. The system should be robust and fault tolerant. Further
more, as the system is handling sensitive data of the school, high emphasis shou
ld be given with regards to security, as there are subsystems to be accessed thr
ough web.
5.1.3 Maintenance
The system should be easily extensible to add new functionalities at a later sta
ge. It should also be easily modifiable to make changes to the features and func
tionalities.
5.1.4 End User Criteria
Usability: Usability is the extent to which a product can be used by specified u
sers to achieve specified goals with effectiveness, efficiency and satisfaction
in a specified context of use. From the end users perspective the system should b
e designed in such a way that it is easy to learn and use, efficient and having
few errors if any. Trade-off is inevitable in trying to achieve a particular des
ign goal. One best case is the issue of security versus response time. Checking
User-Id and Password before a member can enter to the SMS creates response time
problem/overhead. The other case is the issue of response time versus quality. T
here is some amount of time taken by the system to generate the timetable. So th
e user has to wait a little after telling the system to generate the timetable a
nd getting the result to get a quality timetable.
- 27 -

5.2
Architecture of the System
The proposed system is expected to replace the existing manual system by an auto
mated system in all facets. It is mainly based on the system Analysis document (
chapter 4). The architecture used for the system is a 3 tier Client/Server Archi
tecture where a client can use Internet browsers to access the online report pro
vided by the system within the local area network of the school or any where usi
ng the Internet. Figure 5.1 shows the architecture of the proposed system. The d
ata tier maintains the applications data such as student data, teacher data, tim
etable data etc. It stores these data in a relational database management system
(RDBMS). The middle tier (web/application server) implements the business logic
, controller logic and presentation logic to control the interaction between the
applications clients and data. The controller logic processes client requests su
ch as requests to view students result, to record attendance or to retrieve data
from the database. Business rules enforced by the business logic dictate how cli
ents can and cannot access application data and how applications process data. A
web server is a program that runs on a network server (computer) to respond to
HTTP requests. The most commonly used web servers are Internet Information Serve
r (IIS) and Apache. The web server used in this system is IIS. HTTP is used to t
ransfer data across an Intranet or the Internet. It is the standard protocol for
moving data across the internet. The client tier is the applications user inter
face containing data entry forms and client side applications. It displays data
to the user. Users interact directly with the application through user interface
. The client tier interacts with the web/application server to make requests and
to retrieve data from the database. It then displays to the user the data retri
eved from the server.
- 28 -

Figure 5.1 Architecture of the System

5.3
Subsystem Decomposition

Subsystem decompositions will help reduce the complexity of the system. The subs
ystems can be considered as packages holding related classes/objects. The SMS un
der consideration is decomposed into subsystems as shown in Figure 5.2. These su
bsystems are further decomposed into other subsystems. The major subsystems iden
tified are StudentRegistration, Login, Attendance, ReportCard, Transcript, Timetab
rt subsystems. Users are classified in to roles. The Login subsystem authenticates
a user to grant access based on the role of the user. The StudentRegistration subs
ystem registers a
- 29 -

student offline. It allows recording the detail information of the student inclu
ding parental and emergency person. Transcript and ReportCard subsystems are used to
generate transcript and report card respectively. The Timetable subsystem generat
es a timetable, which involves allocating a time slot to a subject teacher for a
class of students. The Attendance subsystem facilitates recording absent students
on the school day by the homeroom teacher to control absentees and to report to
parents and the administrator to take corrective measures. The Report subsystem g
enerates reports to parents, officials from kebeles and kifle-ketema and teacher
s in order to facilitate viewing students status and course achievement online.
- 30 -

SMS
Transcript Sub system
Report Sub system
Student Registration Sub system
Login Sub system
Attendance Sub system
ReportCard Sub system
Timetabling Sub System
Figure 5.2 Layered Representation of the System
- 31 -

Further decomposition of some of the subsystems is shown in Figure 5.3.

Registration Subsystem
Attendance Subsystem Teacher Home Page
Student
Registrar
Account
Attendance
Transcript Subsystem Record-Officer Student
Report subsystem Parent/Official Initialize Home Page
Transcript
Report
Figure 5.3 Subsystem Decomposition Diagram
5.4
Hardware/Software Mapping
One of the major tasks in system design deals with hardware/software mapping whi
ch deals with which components would be part in which hardware and so on. The SM
S is a broad system that performs many functions as described in chapter 4. It c
onsists of web based system used by homeroom teachers to record attendance. The
web based system also assists parents and officials to get or view status and re
port on students achievement and progress. The system assists the record officer
to generate transcript and report cards. So the web based part is expected to ru
n on - 32 -

a networked environment on different Operating System platforms. The client/serv

er architecture of the system enables different clients to connect to the server
remotely through Internet connection. The system has two nodes such as the Web
server and Clients. These nodes are shown as UML Deployment diagrams in Figure 5
.4. The nodes can represent specific instances (workstations) or a class of comp
uters (web server), which is a virtual machine. The applications of the system w
ill run on the web server connected to the database server by ado.net
:Client machine Web Browser
:Web/application server :Web HTTP
/ li i
Applications ASP.NET
ADO.NET
: Database Server
Database
Fig 5.4 Deployment Diagram of the System. The system has two applications to be
developed on the same database, Windows and Web applications. When dealing with
windows applications, there are compiled program that must be distributed to the
users desktop before they can use it. Depending on the application, there may a
lso be one or more supporting DLLs or other executables such as Crystal Reports
[6]. While in thin-client applications (Web applications) there is typically no
program or DLL to be distributed.
- 33 -

Users merely need to start their browsers and enter the URL of the application W
eb site. The server hosting the Web site is responsible for allocating all the r
esources the Web application requires.
5.5
Persistent Data Management
Persistent data management deals with how the persistent data (file, database, e
tc) are stored and managed and it outlives a single execution of the system. Inf
ormation related to student basic information, students attendance and grade mark
, the timetable produced and other related information are persistent data and h
ence stored on a database management system. This allows all the programs that o
perate on the SMS data to do consistently. Moreover, storing data in a database
enables the system to perform complex queries on a large data set The schools re
gister students every year in thousands per grade level. For complex queries ove
r attributes and large dataset Microsoft SQL Server is implemented, which is a R
elational Database Management System.
5.5.1 Mapping
In order to store information persistently we map objects into tables and the at
tributes into fields to the specific table based on the objects found on the sys
tem. Therefore, we identified the major tables that will be implemented on the s
elected DBMS. For this reason, some of the mapping of objects to tables is displ
ayed as in Fig 5.5.
5.5.2 Relationships among Tables
This part is to describe and show the necessary relationships among the tables,
which are selected to store the data persistently in the system. Generally there
are three types of relationships in a relational database system. These are one
-to-one, one-to-many and many-to-many relationships. The system under considerat
ion has one-to-many and many-to-many relationships. Student and AcademicSubject
tables have many-to-many relationships. One of the aims in a database system is
to reduce redundancy and for that purpose many-to-many relationship has to
- 34 -

be reduced to one-to-one relationship. The Student and StudMarks and the Academi
cSubject and StudMarks have one-to-many relationship by using the StudMarks tabl
e as the associate table. The relationship of the remaining tables and the ones
described here are descriptively shown in Fig. 5.6.
- 35 -

Student
StudId:String Name:String Age:Number Sex:String Nationality:String Address:Strin
g Tel: String
Student
<<Table>> StudId:String <<pk>> Name:String Age:Number Sex:String Nationality:Str
ing Address:String Tel: String
Subject
SbjCode:String SbjName:String
Subject
<<Table>> SbjCode:String <<Pk>> SbjName:String
studMarks
StudId:String SbjCode:String Sem:String AYear:Number GSection: String Mark:Numbe
r
studMarks
<<Table>> StudId:String <<Pk>><<Fk>> SbjCode:String <<Pk>><<Fk>> Sem:String <<Pk
>> AYear:Number <<Pk>> GSection: String Mark:Number
EmergencyContact
StudId:String ContactName:String IsParent:Boolean Sex:String Nationality: Date T
ele:Sting
EmergencyContact
<<Table>> StudId:String <<Fk>> ContactName:String IsParent:Boolean Sex:String Na
tionality: String Tele:Sting
Attendance
Attend_Index:Number StudId:Number ADate:Date Description:String
Attendance
<<Table>> Attend_Index:Number<<Pk>> CustId:String <<Fk>> BookId:String <<Fk>> Cr
editCadNo:String Amount:Currency
Figure 5.5 Mapping Objects into Tables
- 36 -

Figure 5.6 Relationship Diagram of the Tables

- 37 -

5.6
Algorithmic Design for the Timetable
The algorithm tries to assign lessons to periods and a teacher to a particular c
lass at a given time while satisfying a set of constraints in order to produce a
feasible timetable. Table 5.1 below shows the number of lessons for each subjec
t per week to be distributed in the time slots of the school days. There are fiv
e school days starting from Monday to Friday and in each of these days there are
seven periods for each class. Table 5.1 Number of lessons for each subject Subj
ects No. of lessons per week Amharic English Mathematics Physics Chemistry Biolo
gy Geography History Civics HPE 3 6 6 4 3 (Grade 9) 4 (Grade 10) 4 (Grade 9) 3 (
Grade 10) 2 2 3 2
A class of students is given a room which is fixed for the class throughout the
academic year. To each class, a subject teacher is assigned for each of the ten
subjects Let C = {c1, c2,, cm}, S = {s1, s2, , s10} and T = {t1, t2, , tn} be the s
et of all classes, subjects and teachers respectively. A teacher teaches only on
e type of subject from the ten subjects while a subject can be taught by many te
achers. Table 5.2 illustrates some examples of assignment of teachers to subject
s and classes.
- 38 -

Table 5.2 An example of the relationship among classes, subjects and teachers Cl
ass Subject Teacher c1 c1 c1 c2 c2 c3 c4 ci s1 s2 s3 s1 s3 s2 s2 sj, 1 j 10 t1 t
2 t5 t1 t6 t3 t4
tk
Let D = {d1, d2, d3, d4, d5} and P = {p1, p2, p3, , p7} be the sets of days and t
ime slots (periods) where |D| = 5 and |P| = 7. Let M (muv) be a 2D matrix in whi
ch each column v corresponds to a class c where c C and each row u corresponds t
o one combination of (d, p) where d D and p P. The value of cell muv is determin
ed as: muv = sjtk, if this cell is assigned to subject-teacher combination sjtk.
muv = #, if this cell is available for assignment.
The subject-teacher code sjtk uniquely identifies the subject teacher assigned t
o the class. For example sjtk could be E5, to identify an English teacher or it
could be M3, to identify a Mathematics teacher and so on. Assigning a teacher to
more than one class at the same period leads to violation of one of the hard co
nstraints and hence the timetable will not be feasible. Table 5.3 shows an examp
le of time slot assignment to a lesson.
- 39 -

Table 5.3 An example of time slot assignment c1 c2

c3 #
d1,p1 d1,p2 d1,p3 d2,p1 d2,p4 d4,p7 d5,p1
s1t1 # # s4t5 s1t1 # #
s1t2 # # s4t5 s10t6 # #
Not Ok
s2t3
# # # # #
The maximum and minimum loads assigned to a teacher are 30 and 6 periods respect
ively. The Teacher and TeacherCode tables in the database design as shown in Fig
ure 5.6 contain the following fields to help scheduling: Teachers Name Subject Co
de that the teacher teaches Grade level (Grade 9 or Grade 10) Class Teachers code
The database consists of other additional tables containing important schedulin
g information. The timetabler selects a teacher from the teachers table and read
s the subject that the teacher teaches, number of lessons of the subject, and al
l the classes which have been assigned to the teacher. The load of the teacher i
s calculated which can not be greater than the maximum load. The system parses t
he Teacher table row by row until all the teachers are visited or to the end of
the rows. Taking a subject-teacher code of the teacher retrieved, the system sel
ects one of the days (Monday, Tuesday, , Friday) randomly based on the number of
lessons of the subject per week, searches a free slot on the selected day for ea
ch class assigned to the teacher, checks if the teacher has been assigned to ano
ther class in the same period. If appropriate free slot has been found then
- 40 -

the lesson is assigned to the slot. If appropriate slot has not been found then
moving previously assigned lesson to a free slot or swapping two or more lessons
has been done. If all the slots in the selected day are filled and swapping cou
ldnt solve the problem, another day is selected. The process continues until the
load of the teacher becomes zero. The algorithmic design of the timetable is sho
wn in Algorithm 5.1.
- 41 -

Algorithm 5.1
Loop until all the teachers in the database are visited Select a teacher from th
e Teacher table Retrieve the Subject-Teacher code, Grade-Level, Number of lesson
s of the subject and all the classes assigned to the teacher Calculate load of t
he teacher If load is greater than maxLoad Display Error Message Exit Applicatio
n While load of the teacher not zero Select a Day uniquely and randomly from the
school days based on the number of lessons of the subject For Each Day of the w
eek selected For Each class assigned to the teacher If allocatedLesson of the su
bject to the class is greater than zero If timeslot is not #, move to the next slo
t If teacher is assigned in the period, move to the next slot If appropriate slo
t is not found swap previously assigned classes Assign lesson to the slot Decrea
se allocatedLesson of the subject Decrease load of the teacher End For End For E
nd While End Loop
- 42 -

Chapter 6 Implementation
In this chapter, the tools used in developing the prototype and the developed sy
stem are described.
6.1
Programming Tool
The system has two different applications using the same database. These are the
Windows application which is sometimes known as thick-client application and We
b application which is known as thin-client application. The Windows application
is developed using C#, which is one of the development languages in .NET and is
object oriented. The Web application is developed using Active Server Pages (AS
P .NET 2.0).
6.2
The SMS Prototype
Here, the implemented system is described. How the user interacts with the syste
m and some of the results of interaction with the system along with the screen s
hots are described. When a user starts the application, a login screen is displa
yed as shown in Figure 6.1 to authenticate the user. If the user has typed the c
orrect user id and password to the login screen, the system displays a splash sc
reen for 3 seconds as shown in Figure 6.2 and then a window containing the main
menus of the system as shown in Figure 6.3. The main window displays menus and s
ub menus based on the role of the user that has logged in.
- 43 -

Figure 6.1 Login Screen

Figure 6.2 Splash Screen
- 44 -

Figure 6.3 Main Menu

The roles for the Windows application are Record Officer, System Administrator a
nd Principal. If the record officer has logged in then the main window displays
menus and sub menus to register student along with parental information as shown
in Figure 6.4. The system also displays menus and sub menus to record marks, ge
nerate report cards and Transcripts.
Figure 6.4 Screen shot of student registration form
- 45 -

After the student has been registered, the system facilitates to register the st
udents parent and emergency persons by providing another window as shown in figur
e 6.5. Note that parental and emergency person information is highly required by
the school for handling the student in his/her stay at the school, for example
in the case of taking disciplinary measures for the case that the student has co
mmitted some crimes. So such information as the name, address of the parent or e
mergency person can be easily retrieved.
Figure 6.5 Parental and Emergency Person Data Entry and Retrieval Form
The other role of the record officer is to record marks and generate transcript
and report cards. These are routine tasks which take much of the times of the us
er, but once the marks are recorded the tasks are simplified. When the user want
s to generate report cards or transcripts, he/she selects the corresponding sub
menu from the Reports menu and a form is displayed to facilitate generation of the
reports. A screen shot of a report card is shown in Figure 6.6 and the transcri
pt report has a similar format.
- 46 -

Figure 6.6 Screen shot of Report Card

If the user has logged in as a principal to produce timetable then a form as sho
wn in Figure 6.7 is displayed. When the user clicks on Generate Timetable button t
he scheduler selects a subjectteacher from the database, retrieves all the class
es assigned to the teacher, calculates the load of the teacher which cannot be g
reater than the maximum load and selects one of the days randomly based on the n
umber of lessons of the subject, searches a free appropriate time slot and assig
ns the slot to the lesson. The scheduler repeats the process until the load of t
he teacher becomes zero and all the teachers in the database are visited.
- 47 -

The system produces a feasible timetable satisfying the constraints as shown in

Figure 6.7. Due to screen size we have limited the table to be displayed for pri
nt into a page per class/section as shown in figure 6.8 which could be given to
each class. The system also facilitates a timetable to be generated and printed
for each teacher as shown in figure 6.9.
Figure 6.7 Screen shot that shows automatic generation of the timetable
- 48 -

Figure 6.8 Timetable for class/section 10-2 Students.

Figure 6.9 Timetable for a teacher (an Amharic teacher Code AM1).
- 49 -

The web application is deployed on the central server in the schools intranet an
d the clients in the intranet with any browser can access the (home page) schools
site. The user logs in by providing his/her user Id and password and then the s
ystem displays information based on the role of the logged in user. The roles ar
e homeroom teacher to record attendance, parent and officials to see the status
of students and view reports. When the homeroom teacher logged in to record atte
ndance the form shown in figure 6.10 is displayed. This helps the teacher to rec
ord absentees and to view the number of dates that a student has been absent. Wh
en a student logged in to view his/her status or parent logged in to view the st
atus of his/her child the form shown in figure 6.11 is displayed.
Figure 6.10 Screen shot of attendance recording page
- 50 -

Figure 6.11 Screen shot showing the page displayed for a parent
- 51 -

Chapter 7 Conclusion and Recommendations

7.1 Conclusion
In this project, we developed an automated school management system that facilit
ates the various activities taking place at schools. The system developed in the
project consists of windows and web applications. These are two different appli
cations on the same database. The windows application takes most of the activiti
es such as offline student registering, transcript and report card generation an
d producing the timetable. The web application facilitates attendance recording
by the homeroom teachers and to view reports, to view status of students by stud
ents, teachers and parents. Our solution of the timetabling problem is very simp
le. Data structures are used to implement the timetable designed. The scheduler
selects a subject-teacher from the database, retrieves all the classes assigned
to the teacher, calculates the load of the teacher which cannot be greater than
the maximum load and selects one of the days randomly based on the number of les
sons of the subject, searches a free appropriate time slot and assigns the slot
to the lesson. The scheduler repeats the process until the load of the teacher b
ecomes zero and all the teachers in the database are visited. Finally the result
generated is stored in a database. The prototype has been tested with data from
Kokebe Tsebah Secondary School. It has been shown that the system effectively r
egisters students along with parental information, easily retrieves information
about a student and generates the required reports such as transcript, report ca
rd and timetable. In addition to generating a feasible master timetable it produ
ces a timetable for each teacher. Further more it has been shown that the web ap
plication of the system helps attendance recording by the homeroom teacher and p
arents can view the status of their children using the Internet or Intranet of t
he school.
- 52 -

7.2
Recommendations
To enhance the efficiency of the system, in the following we have listed some re
commendations and future works. As education is central to development there sho
uld be a good facility to make stakeholders participate in school improvement pr
ograms and decision making. Parents and Education Bureaus from Kebele and Kifleketema are among the stake holders. To facilitate easy information access to suc
h bodies the web application could be further enhanced by incorporating addition
al reports required by Kebele and Kifle-ketema Education Bureaus. Such facilitie
s will increase participants in decision making at educational activities and st
udents achievement. We also believe that timetables should be flexible. In real
world situations there are preferences. A restriction of the sort that every tea
cher should have some specific free periods or some part of days off requires an
efficient search technique. Efficiency of the timetable could be further enhanc
ed by improving the search technique so that such constraints as preferences cou
ld be taken into consideration.
- 53 -

References
[1]. E. Burke and W. Erben. Practice and Theory of Automated Timetabling, Third
International Conference, Germany, Springer Private Limited, August 2000 [2]. J.
G. Hedberg et. al. (1992). Educational information systems: Problems of the sma
ll educational organisation. Australian Journal of Educational Technology, 8(2),
132-160. http://www.ascilite.org.au/ajet/ajet8/hedberg.html [3]. M. Marte. Mode
ls and Algorithms for School Timetabling, A Constraint-Programming Approach, Ph.
D dissertation, an der Fakultat fur Mathematik, Informatik und Statistik der Ludwi
g-Maximilians-Universit at Munchen, July, 2002 [4] R.J. Willemen. School Timetable
Construction: Algorithms and Complexity, Thesis, Faculty of Mathematics and Com
puter Science, Technische Universiteit Eindhoven, 2002. [5]. S. Petrovic and E.
Burke. University Timetabling, School of Computer Science and Information Techno
logy, University of Nottingham, 2002, pp. 1-4 [6] T. Willis and B. Newsome. Begi
nning Visual Basic 2005, Wiley Publishing, Inc., 2006.
- 54 -