TITLE: WEB DASED CLASS SECHUDULING SYSTEM FOR

BURIE CAMPUS

A PROJECT REPORT

Submitted by:

NAME OF THE STUDENT ID NO

1. EYOSIAS BEYEN DMU1303680
2. YIDENKACHEW DEMISSE DMU1307367
3. KELMU GEMEDA DMU1303917
4. YOHANNES ABEBEW DMU1307316
5. REDIWAN SULTAN DMU1306662

In partial fulfilment for the award of the degree of

BACHELOR OF SCIENCE IN COMPUTER SCIENCE

Under the guidance of
INS. YESHIEMBET BAYU

-------------------------------------
ADVISOR SIGNATURE

DEPARTMENT OF COMPUTER SCIENCE

BURE CAMPUS
DEBRE MARKOS UNIVERSITY
BURIE
30 DEC, 2024 G.
 Abstract

This document proposes a Class scheduling system which is a web-based application that
manages all daily activities of Debremarkos University, Burie campus of registrar office. The
system can keep track of registrar office adding, editing, searching, viewing and deleting of
Class scheduling system. The process of data collection will use to develop this proposal via
interview and observation and other methodology. The existing system is manual based system.
We want to change the existing manual system by new automated system. In this project we will
use object oriented system development methodology (OOSD) using php programming language
and html language from an effective design and MYSQL to database application. The project
aims at developing newly automated system that provides fast and reliable service for the
registrar office, departments, lectures and students by minimizing time and resource wastage.
Our project tries to identify the weakness of the existing system by highly investigating the
problems of the existing system and providing clear and concise solutions for those problems.
Before directly deploying this system we will perform different types of testing procedures for its
functionality. Our project specifies hardware and software requirements. The project will be
done by all the group members and each member has his own individual task and is responsible
for his tasks.
 Acknowledgements
First of all, we would like to thank our God. Then, we would like to thank and appreciate our
advisor instructor Yeshimebet B.
Table of Contents
Acknowledgements.................................................................................................................................3
CHAPTER ONE............................................................................................................................................10
1. Introduction...........................................................................................................................................10
1.1 Introduction.....................................................................................................................................10
1.2 Background of the Project.............................................................................................................10
1.3 Problem Statement..........................................................................................................................10
1.4 Objectives of the project.................................................................................................................11
1.4.1 General Objective.....................................................................................................................11
1.4.2 Specific Objectives....................................................................................................................11
1.5 Scope of the project........................................................................................................................11
1.6 Significance of the Project...............................................................................................................11
1.7 System requirement........................................................................................................................12
1.7.1 Software Tools..........................................................................................................................12
1.7.2 Hardware Tools.........................................................................................................................12
1.7.3 Programming language.............................................................................................................12
1.8 Methodology of the project.............................................................................................................12
1.8.1 Data Sources.............................................................................................................................12
1.8.2 Fact finding technique..............................................................................................................12
1.8.3 System Analysis and Design Methodology................................................................................13
1.8.4 Development Methodology......................................................................................................13
1.9 Feasibility Studies............................................................................................................................13
1.9.1 Technical Feasibility..................................................................................................................13
1.9.2 Operational Feasibility..............................................................................................................13
1.9.3 Political Feasibility....................................................................................................................14
1.9.4 Economic Feasibility.................................................................................................................14
CHAPTER TWO...........................................................................................................................................15
2. System Analysis.....................................................................................................................................15
2.1 Overview of the Existing System......................................................................................................15
2.1.1 User of the Existing System.......................................................................................................15
 2.2 System Requirement Specification..................................................................................................16
2.2.1 Functional Requirement............................................................................................................16
2.2.2 Non-Functional Requirement...................................................................................................18
2.2.3 Business Rule............................................................................................................................19
2.2.4 Change Cases............................................................................................................................20
2.3 System Requirement Analysis..........................................................................................................20
2.3.1 Actor and Use Case Identification.............................................................................................20
2.3.2 Sequence Diagram....................................................................................................................34
2.3.3 Activity Diagram........................................................................................................................38
2.3.4 Analysis Class Diagram..............................................................................................................45
CHAPTER THREE........................................................................................................................................46
3. System Design.......................................................................................................................................46
3.1 Design Class Diagram.......................................................................................................................46
3.2 Database Design/ Physical Data Model...........................................................................................48
3.3 User Interface Design......................................................................................................................48
3.4 System architecture (Deployment diagram)....................................................................................51
CHAPTER FOUR..........................................................................................................................................52
4. Implementation.....................................................................................................................................52
4.1. Over View of Programming Language Used...................................................................................52
4.2. Algorithms Overview Used.............................................................................................................52
4.2.1. Pseudo code............................................................................................................................52
4.2.2. Sample code............................................................................................................................52
CHAPTER FIVE............................................................................................................................................60
5. Testing...................................................................................................................................................60
5.1 Sample testing.................................................................................................................................60
5.1.1 Unit testing...............................................................................................................................60
5.1.2. Integrating testing...................................................................................................................62
5.1.3. System testing.........................................................................................................................62
CHAPTER SIX..............................................................................................................................................64
6. Conclusion and Recommendation.........................................................................................................64
6.1 Conclusion.......................................................................................................................................64
6.2. Recommendation and Future Enhancement..................................................................................64
References.................................................................................................................................................65

List of Tables:
Table 1: software tools…………………………………………………………………12

Table 2: Functional Requirement…………………………..………………………….15

Table 3: Non-Functional Requirement…………………………………….…………..19

Table 4: use case documentation for login…………………………………….…….23

Table 5: use case documentation for Manage system user………………………….24

Table 6: Use case documentation for Add Faculty Information……………………24

Table 7: Use case documentation for Add Department Information……………….25

Table 8: Use case documentation for Add Building Information……………………26

Table 9: Use case documentation for Add Room Information……………………..27

Table 10: Use case documentation for Add Instructor Information…………………28

Table 11: Use case documentation for Add Student (year and section) Information...29

Table 12: Use case documentation for Add Course information….30

Table 13: Use case documentation for Delete course information………………….….30

Table 14: Use case documentation to Add Class Schedule……………………..………31

Table 15: Use case documentation to Edit Schedule……………………………………32

Table 16: Use case documentation to Delete Class Schedule………………….…….….33

Table 17: Use case documentation to view All Schedule……………………………….34

Table 18: simple unit testing……………………………………………………………62

Table 19: sample integrate testing for viewing schedule………………………………..64

List of Figures:
Figure 1: Use case diagram of scheduler, system user use and department………….22

Figure2: Sequence Diagram for Login………………………………………………….36

Figure3: Sequence Diagram for Adding Information……………………………….….37

Figure4: Sequence Diagram for updating Information…………………………….…...37

Figure5: Sequence Diagram for Delete Information…………………………...….….…38

Figure6: Sequence Diagram for adding user Account………………………….…….…38

Figure7: Sequence Diagram for Add Class Schedule……………………….………….39

Figure8: Sequence Diagram for Search Schedule………………………………….………..39

Figure9: Activity Diagram for Login………………………………………………………40

Figure10: Activity Diagram for Adding Information……………….………….……….…41

Figure11: Activity Diagram for Updating Information…………………………….…….…42

Figure12: Activity Diagram for Deleting Information……………………………………..43

Figure13: Activity Diagram for Adding User Account…………………………………….44

Figure14: Activity Diagram for Adding Class Schedule…………………..……………….45

Figure15: Activity Diagram for Searching Schedule……………………………………….46

Figure16: Analysis class diagram of DMU class scheduling system……………………..47

Figure 17: Design Class Diagram Figure ………………………………………………………49

Figure 18: Database Design Figure …………………………………………………….50

Figure 19: User Interface for Login Figure ……………………………………………………51

Figure 20: User Interface for Department ……………………………………..………51
Figure 17: user interface for student user ……………………………………………52

Figure 21: Deployment Diagram…………………………………………………………….…53

List of Acronyms:

Admin  Administrator or scheduler DMU

Debremarkos University Course
Subject

CPU Central Processing unit

Cr. Hr.  Credit Hours

HDD Hard Disk Driver

HTTP Hyper Text Transfer Protocol

Instructor Teacher

MySQL Structured Query Language (database management system)

PHP Hypertext Pre-processor (text editor)

RAMRandom Access Memory

Scheduled prepared

Scheduler Registrar Office or admin

UMLUnified Modelling Language

WAMPWindows, Apache, MySQL, and PHP/Perl/Python)

Appendices
CHAPTER ONE

1. Introduction
1.1 Introduction
In today's schools and colleges, scheduling classes efficiently is really important. But using
traditional methods often leads to problems like scheduling conflicts and wasted resources. To
solve these issues, we propose creating a new web-based system for scheduling classes.

This system will use modern web technology to make scheduling easier and more accessible. It
will help manage class schedules, rooms, and resources in real-time. By moving to a web-based
system, we can update schedules instantly and let everyone involved in scheduling collaborate
better.

This proposal aims to show how we improve and manage schedules at our institution. It will
make scheduling smoother and more organized, helping students, teachers, and administrators
alike. The following sections will explain the goals, scope, how we plan to do it, and what we
expect from this new system.

1.2 Background of the Project

Class scheduling is used in different educational areas such as: colleges, and universities (higher
educational institutions) and doing this takes a lot of time and resources. Based on this we
proposed to solve the problem of the existing scheduling system of Burie Campus for Colleges
by developing web based scheduling system. Our proposed system will eliminate weaknesses of
the existing system by providing fast and easy class scheduling system. Students and Instructors
can view their class schedule online. This system will also provide benefits for the college by
providing simple mechanism to schedule classes. Generally the proposed system will be able to
improve previous system resources, time consuming and tedious way of scheduling system.

1.3 Problem Statement

The existing Class Scheduling System at DMU is susceptible to different labour and time
problems. The main problems of the current Class Scheduling System are as follows.

Repetition of work: if there are any changes to be made during scheduling class manually the
data will have to be entered again. At times the worker would forget to make the changes or
forget that they had already altered it and might redo it again, it’s again time consuming.

Time conflict: during scheduling class one class can have more than one course at the same
time. And class duplication is also based on the time conflict.

Inconsistency of data: there will be unavailability for future use, since data might get
misplaced during manual scheduled class .so data won’t be preserved properly for future use.
 Slow retrieval of data: the information of instructors list, students list, building list, course list,
lecture classroom list stored in a paper it takes a long time to retrieve the data (information).

Too much paper work: since everything and every detail like instructors list, students list,
building list, course list, lecture classroom list and so on in the current class schedule are written
down manually in paper there will be too much paper work. Scheduling all classrooms take lot of
time. Besides, it is highly error prone because it is done by human not by computer and a number
of human labour is required. The loss of manpower (employees), wastage of time to prepare
manually class scheduling system.

Hence, the development of this project is critically important to address the problems listed
above.

1.4 Objectives of the project

1.4.1 General Objective.
The general objective of this project is to develop Web based class scheduling system for DMU.

1.4.2 Specific Objectives

The specific objective of this project includes: -

 To design interactive and friendly user interface.

 To ensure mobile access.
 To provide feedback mechanism.
 To provide real-time scheduling.

1.5 Scope of the project

This project focuses on the current work flow of class scheduling system of DMU burie campus.
The scope of this project is hence bounded to replacing the manual class scheduling system
activities that are currently undertaken at DMU by a more convenient web-based system that
removes the obstacles stated in the statement of problem. Generally the scope of the new
proposed system includes:-

 Class scheduling for computer science department.

 View class scheduled.
 Assigned instructors of each offered courses.
 Assigned class rooms.

1.6 Significance of the Project

After implementing this automated system it is very easy to schedule class. This system solves
the previous time consuming and tiresome system it saves a lot of time and money, scheduling is
very fast and delays can be avoided and it helps the university in reducing costs such as labor and
stationary. And it avoids wastage of time in teaching and learning process.
1.7 System requirement
In this project the following requirement tools were used: -

1.7.1 Software Tools

Activities Tools/programs

Client side coding HTML5

Client side scripting Java script ES2023

Platform Windows10

Database server/Web server MySQL 8.0.34

Server side scripting PHP 8.2

Editors VS code

Documentation MS Word 2021

User training MS PowerPoint 2019

Modelling Gliffy

Table 1: software tools

1.7.2 Hardware Tools

 Client computer: The class scheduling system can be used on workstations with 512MB
or less free space HDD (Hard Disk Drive) and 1GB RAM for fast browsing.
 Server computer: CPU 4.00 GHZ, 500GB HDD and 4GB RAM is required for the
system server.
 External hard disk: for Back up data.

1.7.3 Programming language

1) HTML
2) PHP
3) JAVA SCRIPT

1.8 Methodology of the project

1.8.1 Data Sources
The data/information needed to develop the new system has obtained from department head.

1.8.2 Fact finding technique

Interview.
1.8.3 System Analysis and Design Methodology
The team chooses to follow the object oriented system analysis and design methodology during
the whole project life cycle (Analysis, design etc.) for the many benefits that it has over
structured approach including reusability, improve quality, maintainability and manages
complexity. Hence, we have applied the concepts of object oriented system development
methodology throughout the project, because it manages and assemble objects that are
implement in our system, and the composition of objects and interaction between objects on the
system. This categorized in to two phases. These phases are:-

1.8.3.1 Object oriented Analysis

During this phase we have looked at the problem domain, and with the aim of producing a
conceptual model of the information that exists in the area which have been analysed. And this
Model the functions of the system (use case modelling), identifying the business objects,
organize the objects and also the relationship between them.

1.8.3.2 Object oriented design

During this phase Model object interactions and behaviours that support the use case scenario,
and finally update object model to reflect the implementation environment. And also transforms
the conceptual model produced in object-oriented analysis to take account of the constraints
imposed to our system format, so that we used this phase to refine the use case model to reflect
the implementation environment.

1.8.4 Development Methodology

The development of method we are using to develop the proposed system is the Agile
development approach. Because of its highly suitable for, emphasizes on constant feedback and
adaptation, collaborative and flexibility of system and soon.

1.9 Feasibility Studies

Feasibility is the measure of how the new system is viable or beneficial from the existing
system. It is an on-going process done frequently during systems development projects in order
to achieve a creeping commitment from the user and to continually assess the current status of
the project.

1.9.1 Technical Feasibility

Usually new systems established in order to overcome the technical illness of the previous
system. In the same way, this system is technically big enough to be applied easily to the
problem identified in the existing system. In addition that, both hardware’s and software’s for
this system are highly available and can be owned with small cost. Therefore, it can be
concluded that the system is technically feasible.
1.9.2 Operational Feasibility
The system will operate on any operating systems or platforms which have apache installed.
Therefore the system will operate in any kind of platforms .so the entire team member expects
the system to be operationally feasible.

Platform independent with all client and servers side coding it allows all

1.9.3 Political Feasibility

The system is politically feasible cannot cause any harm or it does not have an influence in the
environments. The project is beneficial because it satisfies the objectives of the customer or the
university. System is free from any problems because there is no negative side to user or workers
to university.

1.9.4 Economic Feasibility

This feasibility is used for evaluating the effectiveness of a new system. In economic analysis the
procedure is to determine the benefits and savings that are expected from a candidate system and
compare them with costs. If benefits outweigh costs, then the decision is made to design and
implement could also be referred to as cost/benefit analysis.
CHAPTER TWO

2. System Analysis
2.1 Overview of the Existing System
As we know manual system is quite tedious and since the existing scheduling system is manual,
it has to process everything manually from course offering to the final schedule. The tasks that
are performed currently in the departments regarding the scheduling are scheduling class rooms,
scheduling laboratory classes and scheduling laboratory hours for the instructors and for the
students. All of the tasks that we visited during the study are performed manually and it is
tedious needs a lot of time, needs a great commitment and previous skill. For the better
accomplishments of those tasks computerized system is the best and interactive as it reduce
efforts, costs and wastage of time.

2.1.1 User of the Existing System

An existing system compromises different players to carry out its job. Among those different
actors (players), the most common are:–

 Student: - view the posted schedule.

 Instructor: - can be professor, assistance professor, lecturer or assistance lecturer
and is a user who gets any information regarding the schedule.
 Quality assurance: - view the posted schedule by the department head.
 Department head: - perform course offering process and then sends the offered
courses to the system users.
 Quality assurance.
 Faculty dean.
2.2 System Requirement Specification
2.2.1 Functional Requirement

The functional requirement of this proposed class scheduling system should be

described regardless of its implementation. It points the major functionalities that
expected to be included in the proposed system to satisfy the objectives of the project.
The proposed system must provide the following features:

Requirement id: - 01
Department head Requirement: -The system shall allow the department head to: -
put information about department, year and section, building, room, academic year
information to the system.
Requirement priority: - High.
Requirement id: -02
Requirement: -The system shall allow the admin to: -delete: system users.
.
Requirement priority: - High.
Requirement id: -03
Requirement: -The system shall allow the department head to edit:- department year
and section, building, room, academic year information to the system.

Requirement priority: - High.

Requirement id: -04
Requirement: -The system shall allow the department head to add schedule by
insert:- department, year and section, academic year, semester, day, time start, time end,
course,
Instructor, room information.
Requirement priority: - High.
Requirement id: -05
Requirement: -The system shall allow the department head to assign each instructor a
course.
Requirement priority: - High.
Requirement id: -06
Requirement: -The system shall allow the department head to to login with his or her
account by
using username and password
Requirement id: -07
Requirement: -The system shall allow the department head to to logout.
Requirement priority: - High.
Requirement id: - 08
Requirement: -The system shall allow the admin to to: - delete user account.
Priority: High
Requirement id: - 09
Requirement: -The system shall allow the department head to to view feedback and
send feedback to system users.

Requirement priority: - High

Requirement id: - 10
Requirement: -The system shall allow the admin to to: - edit user account.
Requirement priority: - High.
Requirement id: - 11
Requirement: -The system shall allow the department head to to post scheduling.
Requirement priority: - High.
Requirement id: - 12
Requirement: -The system shall allow the admin to: -to view feedback from
Department head to and to send feedbacks to the department head.
Requirement priority: High
Department Requirement id: - 13
Requirement: -The system shall allow the department head to to: -submit sleep by
insert:-
department, course code, course title, year, semester, lab hour, lecture hour, credit hour,
mode of delivery, instructor, note to the scheduler.
Requirement priority: - High.
Requirement id: - 14
Requirement: -The system shall allow the admin to view feedback messages posted by
instructors.
Requirement id: -15
Requirement: -The system shall allow the admin to login with his or her. Account
by using username and password
 Requirement priority: - High.
Requirement id: -16
Requirement: -The system shall allow the system users to logout except student.
Requirement priority: - High.
Requirement priority: - High.

Table 2: Functional Requirement

2.2.2 Non-Functional Requirement

Nonfunctional requirements describe user-visible aspects of the system that are

not directly related with the functional behavior of the system.
The following are non-functional requirement of the system:

Requirement id: 01
 Requirement: the system should provide a simple, responsive user interface. By
designing user friendly interface, the end users are able to communicate within few
response times.
Requirement priority: High

Requirement id: 02

Requirement: The system should support concurrent users.

Requirement priority: High

Requirement Id: 03

Requirement: The system should minimize errors and error messages should be
Displayed that guide user to handle it.
Requirement priority: High

Requirement id: 04

Requirement: The system does not allow any user to access other user’s information
except the authorized user.
Requirement id: 05

Requirement: The external security should be provided by giving the login

Authentication.
Requirement priority: High

Requirement id: 06

Requirement: The system will be available to its users with internet connection 24 hours
a day.
Requirement priority: High

Table 3: Non-Functional Requirement

2.2.3 Business Rule

The guidelines or the rule that the system uses to achieve its objective, the following
are rules that govern the system to complete each task.

BR1: Authorize to the System: Users must have a valid user name and password for
their respective privilege, the Users Name should be unique and each users should
enter their user name& password to get access to the system.

BR2: Validate users Information: if the user registered correctly then the system
will validates the user information and then authorized to use the system.

BR3: The Scheduler should administer the system and give accesses (views) to
those system users by creating account as per their priority to the system and update
their password.

BR4: Uniqueness: A student (year and section), Instructor, Room, Faculty and
Department must have unique ID.

BR5: Each course should have a unique course code

BR6: The system must get input the list of Course, Instructors, Room and Year
section (student) for Scheduling

BR 7: The schedule always prepared before the beginning of each semester.

BR8: The Report generates all static information regarding students, instructors
and Room schedule.

BR9: System should provide various reports in accordance with requested

information i.e. (about Students, Instructor, and Room schedule (weekly or for the
semester).

BR 10: The report should be clear and summarized.

2.2.4 Change Cases
- Enhance communication and collaboration
- Facilitate easier adjustments to schedules
- Eliminate paper-based processes and promote sustainability
- Reduce errors and improve data accuracy
- Streamline the scheduling process and improve efficiency
2.3 System Requirement Analysis
2.3.1 Actor and Use Case Identification
 Admin: is an actor who manages the scheduling process.
 Faculty dean & Quality assurance: can view and print class schedule, authentically.
 Student: can view and print class schedule.
 Instructor: can view, print class schedule and send feedback, authentically.
 Department head: perform course offering process, sends the offered courses to the
system user.
 UC1.Login
 UC2.ManageSystem user
 UC3.Add Faculty Information
 UC4.Add Department Information
 UC5.Add Building Information
 UC6.Add Room Information
 UC7.Add Instructor Information
 UC8.Add year and semester Information
 UC9.Add course information
 UC10.Delete course information
 UC11.Add Class Schedule
 UC12.Edit Schedule
 UC13.View Schedule

- Use case Diagram

Figure 1: Use case diagram of the system users.

- Use case Description

 Login

Use Case Name Login

Use Case ID UC1
Brief description User who have privilege to access the system’s functionalities
should be able to login except student user each time he/she
wants to use the system
Actor Admin, department head, faculty dean, quality assurance and
instructor.
Pre-condition The user must to be registered.
Post Condition If the user is authenticated the User logged into the system and
the system displays all features available for the role associated
to the user.
Basic Course Of Action (BCA)
This use case starts when the User accesses the login in feature of the system by selecting his
privilege.
1. The system displays a login form
2. The user enters his/her user and password
3. The user clicks login button
4. The system validates the entered information.
5. The system takes the user to his/her interface.
6. The use case ends.
Alternate Flows
Title Description
4.2User fills invalid 1. The system Displays error message.
username and/or password 2. The system prompts the user to reenter the valid information.
3. Use case continues with BCA 2.

Table 4: use case documentation for login

Manage System User

Use Case Name Manage system user

 Use Case ID UC2
Brief description This use case allows Updating, or Deleting each system users.

Actor Admin
Pre-condition Admin already login into the system and load the user Account page
Post Condition User profile changed in the data base.
Basic Course Of Action (BCA)

This use case starts when the user access the system feature that enable update system user
1. Admin is able to update and delete information for each user in the system by
clicking on The edit or Delete Buttons on the form for each system users.
2. If he press Edit button the system Display change profile form
2.1 The Admin changes the users profile
2.2 The system Update the information changed to the user profile or
3. If the Admin Press Delete Button
3.1 The system will Delete the user account from the system.

Alternate Flows
Title Description
2.1 User inserts 1. The system prompts invalid user account
Invalid
2. System prompts user to reenter valid account information.
Account Information
when editing
Table 5: use case documentation for Manage system user

Add Facility Information

Use Case Name Add College Information

Use Case ID UC3
Brief description This use case represents the procedure which the Admin goes before
 using the system resource. It typically accomplished by typing
information of faculty and Program on the form and sends to the
data base.
Actor Admin
Pre-condition Admin already login into the system and load the Add faculty form
Post Condition Faculty information added to the database
Basic Course Of Action (BCA)

1. The use case starts before scheduling is done.

2. The Admin has to enter the Faculty information.
3. The system then validates the entry.
4. If it is correct save the file to the database.

Alternate Flows
Title Description
4.1Entered Faculty 1. system prompts error message

already exists 2. System display Faculty information already exists.

3. Use case ends.
4.2 Required information 1. system prompts error message
is missing 2. System display Required Faculty information is missing.
3. Use
case continues with BCA2.
Table 6: Use case documentation for Add Faculty Information

Add Department Information

Use Case Name Add Department Information
Use Case ID UC4
Brief description This use case represents the procedure which the Admin goes
to add
 Information to the system. It typically accomplished by typing
information of Department information to the form and sends to the
data base.
Actor Admin
Pre-condition Admin already login into the system and load the Add Department
form
Post Condition Department information added to the database
Basic Course Of Action (BCA)
1. The use case starts before scheduling is done.
2. The Admin has to enter the Department information.
3. The systems then validate the entry.
4. If it is correct save the file to the database.

Alternate Flows
Title Description

4.1Entered Department 1. system prompts error message

already exists 2. System display Department information already exists.
3. Use case ends.
4.2 Required information 1. system prompts error message
is missing 2. System display Required Department information is missing.
3. Use
case continues with BCA2.
Table 7: Use case documentation for Add Department Information

Add Building Information

Use Case Name Add Building Information
Use Case ID UC5
Brief description This use case represents the procedure which the Admin goes
to add information to the system It typically accomplished by
typing information of
Building on the form and sends to the data base.
Actor Admin
Pre-condition Admin already login into the system and load the Add Building
form
 Post Condition The information is Added to the database.
Basic Course Of Action (BCA)
1. The use case starts before scheduling is done.
2. The admin enters the building information.
3. The system validates the entry.

Alternate Flows
Title Description
4.1 Entered 1. The system Display the already exist message
Building
2. The use case end
information already exists
4.2Required information is 1. The system Display the required information is missing
Missing 2. The use case continue with use BCA2
Table 8: Use case documentation for Add Building Information

Add Room Information

Use Case Name Add Room Information
Use Case ID UC6
Brief description This Use case represents also which the Admin accomplishes by
typing information of building in Use case adds room information
send to the database.

Actor Admin
Pre-condition Admin already login into the system and load the Add Room form
Post Condition Entered Room information is saving.
Basic Course Of Action (BCA)
1. The use case starts before scheduling is done.
2. The admin has to enter the Room information.
3. The system validates the entry.
4. The system will save the information to the database.

Alternate Flows
Title Description
 4.1 Entered Room 1. The system Display the already exist message
information
2. The use case end
already exists
4.2Required information is 1. The system Display the required information is missing
missing 2. The use case continue with use BCA 2

Table 9: Use case documentation for Add Room Information

Add Instructor Information

Use Case Name Add Instructor Information

Use Case ID UC7
Brief description This Use case represents also which the admin accomplishes by
entering
instructor information to the database
Actor Admin
Pre-condition admin already login into the system and load the Add Instructor
form
Post Condition Instructor Information Saved
Basic Course Of Action (BCA)

1. The use case starts before scheduling is done.

2. The Admin has to enter the instructor information.
3. The system validates the entry.
4. The system will save the information to the database.

Alternate Flows
Title Description
4.1 Entered Instructor 1. The system Display the already exist message

information already exists 2.The use case end

4.2 User inserts Invalid 1. The system Display the required information is missing

instructor information 2. The use case continue with use BCA 2

Table 10: Use case documentation for Add Instructor Information

Add year and semester Information

 Use Case Name Add year and section Information
Use Case ID UC8
Brief description This Use case represents also which the admin accomplishes by
entering year and semester information to the database
Actor Admin
Pre-condition Admin already login into the system and load the Add year and
section form
Post Condition year and semester Information Saved
Basic Course Of Action (BCA)
1. The use case starts before scheduling is done.
2. The admin has to enter the year and semester information.
3. The system validates the entry.
4. The system will save the information to the database.

Alternate Flows
Title Description
4.1 Entered year and 1. The system Display the already exist message
section
2. The use case end
information already exists

4.2 User inserts Invalid 3. The system Display the required information is missing
year and section 4. The use case continue with use BCA 2
information
Table 11: Use case documentation for Add year and section
Information

Add Course information

Use Case Name Add Course Information
Use Case ID UC9
Brief description This Use case represents also which the admin accomplishes by
entering course information to the database
Actor Admin
Pre-condition Admin already login into the system and load the Add Course form
Post Condition Course Information Saved
Basic Course Of Action (BCA)
 1. The use case starts before scheduling is done.
2. The admin has to enter the Course information.
3. The system validates the entry.
4. The system will save the information to the database.

Alternate Flows
Title Description
4.1Entered Course 1. The system Display the already exist message
information
2. The use case end
already exists
4.2 User inserts Invalid 1. The system Display the required information is missing
Course
2. The use case continue with use BCA 2
Information
Table 12: Use case documentation for Add Course information

Delete course information

Use Case Name Delete Course Information

Use Case ID UC10
Brief description This Use case represents also which the admin accomplishes by
deleting information from the database

Actor Admin

Pre-condition Admin already login into the system and delete the Course
Post Condition Course Information updated
Basic Course Of Action (BCA)
1. The use case starts when the Schedulers select the particular Course ID that needs
to be deleted
2. The admin click on Delete button.
3. The system will delete the course information entry from the database.

Alternate Flows
Title Description
4.1 When the Scheduler 1. The system Return back to the course page
select
2. The use case end
 No Button,
Table 13: Use case documentation for Delete course information

Add Class Schedule

Use Case Name Add Class Schedule

Use Case ID UC11
Brief description This use case allows the department head to setup scheduling time
for each year and semester by assigning room, instructor, course,
education day and time and to prepare Schedule based on the
request of Programs.
Actor Department head
Pre-condition 1. The department head already login into the system and the
system has load the Add Class schedule form.
2. All required information must be entered.
Post Condition The Class schedule data is saved to the database
Basic Course Of Action (BCA)

1. The use case starts when the department head load class schedule page.
2. The system prompts the department head to select departments that he or she wishes to
Add Class schedules.
3. The department head fills all the required information by selecting and by writing.
4. The system validates the entry.
5. The system will Save the Class Schedule to the database

Alternate Flows
Title Description
5.1If year and sections 1. The system Display a message This year and semester
have a class on that time student have schedule on this day and time
2. The use case continue with use BCA 3
5.2 If Instructor have class 1. The system Display a message This Instructor have schedule
on that time for other on this day and time for this Year and semester students.
year and 2. The use case continue with use BCA 3
section student
5.3 If the Room 1. The system Display a message This Room is Reserved by
 already reserved by Instructor name for the year and section student with the course
other year and 2. The use case continue with use BCA 3
section student
5.4 User inserts 1. The system Display the required information is missing
Invalid
2. The use case continue with use BCA 3
Schedule information
Table 14: Use case documentation to Add Class Schedule

Edit Schedule

Use Case Name Edit Schedule

Use Case ID UC12
Brief description The department head wants to edit or modify the Schedule for any
year and section
Actor Department head
Pre-condition 1. The department head have to logged inland

The department head for the Class and Year students must
2.
exist.
Post Condition The changes on the schedule saved to the database.
Basic Course Of Action (BCA)

1. The use case starts when the department head assign new course to the instructor
on Class schedule page for the selected schedule
2. The system displays assign course and assign instructor Form that have all
information about the courses and instructors that the system have

3. The system validates the entry.

4. The system wills Save the Class Schedule to the database.

Alternate Flows
Title Description
4.1If year and sections 1. The system Display a message This year and section student
have a class on that time have schedule on this day and time
2. The use case continue with use BCA 3
 4.2 If Instructor have 1. The system Display a message This Instructor have schedule
class on that time for on this day and time for this Year and section students.
other year and 2. The use case continue with use BCA 3
section student
4.3 If the Room 1. The system Display a message This Room is Reserved by
already
reserved by other year Instructor name for the year and section student with the course
and section student 2. The use case continue with use BCA 3
4.4User inserts 1. The system Display the required information is missing
Invalid
2. The use case continue with use BCA 3
Schedule information
Table 15: Use case documentation to Edit Schedule

View All Schedule

Use Case Name View Schedule Report

Use Case ID UC13
Brief description To view the status of class room, instructor and year and section
Actor System users
Pre-condition 1. Department head have to login into the system
2. System has load the schedule form for the Department
Post Condition Report is viewed to all system users
Basic Course Of Action (BCA)
1. The use case starts when the department head load class schedule page.
2. The system prompts the system users to select departments that he or she wishes to
view schedules.
3. The system display List of schedules for that selected department for all year and
sections.
4. The system Display academic year, semester, department, year and section, day,
course, time start, time end, instructor name, room.

Alternate Flows

Table 17: Use case documentation to view All Schedule

2.3.2 Sequence Diagram
Sequence diagrams are used to model the logic of usage scenarios or the description
of the potential way the system used. Sequence diagrams are a great way to validate
and flesh out the logic of use case scenarios and to document the design of the
system. Debremarkos University Online Classroom Scheduling System has the
following sequence diagrams.
2.3.2.1 Sequence Diagram for Login

Figure2: Sequence Diagram for Login

2.3.2.2 Sequence Diagram for Adding Information

Figure3: Sequence Diagram for Adding Information

2.3.2.3 Sequence Diagram for updating Information

Figure4: Sequence Diagram for updating Information

2.3.2.4 Sequence Diagram for Delete Information

Figure5: Sequence Diagram for Delete Information

2.3.2.5 Sequence Diagram for Adding User Account

Figure6: Sequence Diagram for adding user Account

2.3.2.6 Sequence Diagram for Add Class Schedule

Figure7: Sequence Diagram for Add Class Schedule

2.3.2.7 Sequence Diagram for Search Schedule

Figure8: Sequence Diagram for Search Schedule

2.3.3 Activity Diagram
Activity diagram is used to document the logic of a single operation/method, a single
use case or the flow of logic of a business process. It is equivalent to flowchart and
data flow diagram from s structured development.

2.3.3.1 Activity Diagram for Login

Figure9: Activity Diagram for Login

2.3.3.2 Activity Diagram for Adding Information

Figure10: Activity Diagram for Adding Information

2.3.3.3 Activity Diagram for Updating Information

Figure11: Activity Diagram for Updating Information

2.3.3.4 Activity Diagram for Deleting Information

Figure12: Activity Diagram for Deleting Information

2.3.3.5 Activity Diagram for Adding User Account

Figure13: Activity Diagram for Adding User Account

2.3.3.6 Activity Diagram for Adding Class Schedule

Figure14: Activity Diagram for Adding Class Schedule

2.3.3.7 Activity Diagram for Searching Schedule

Figure15: Activity Diagram for Searching Schedule

2.3.4 Analysis Class Diagram

Class Diagram is used to describe the structure of a system by showing the system’s
classes, their attributes and the relationship between the classes. In addition to that it
shows the static relationship between the classes.
Classes that identified form scheduling system are specified by adding the possible
methods an attributes for each classes. The Class during this phase is detailed to help
the developer to start developing the source code.

Figure 16: Analysis class diagram of DMU class scheduling system

CHAPTER THREE

3. System Design
Systems design is the process of defining the architecture, components, modules, interfaces, and
data for a system to satisfy specified requirements. The purpose of design is to determine how
the system is going to build and to obtain the information needed to drive the actual
implementation of the system. It focuses on understanding the model how the software will be
built. System design is the detail investigation of system elements from logical view.

3.1 Design Class Diagram

Class diagram in the Unified Modelling Language (UML) is a type of static structure diagram
that describes the structure of a system by showing the system's classes:

 their attributes
 operations (or methods)
 And the relationships among the classes.
 A class diagram is an illustration of the relationships and source code dependencies
among classes in the Unified Modelling Language (UML).
Figure 17: Design Class Diagram Figure
3.2 Database Design/ Physical Data Model
Database design is the organization of data according to a database model.
The designer determines what data must be stored and how the data elements
interrelate. With this information, they can begin to fit the data to the database
model. Database management system manages the data accordingly.

Physical data model represents how the model built in the database. A physical database

model Shows all table structures, including column name, column data
type, a n d column constraints.

Figure 18: Database Design

3.3 User Interface Design

User interface design is the design of computers, appliances, machines, mobile communication
devices, software applications, and websites with the focus on the user's experience and
interaction. The goal of user interface design is to make the user's interaction as simple and
efficient as possible, in terms of accomplishing user goals what is often called user centred
design. Good user interface design facilitates finishing the task at hand without drawing
unnecessary attention to it. Graphic design may be utilized to support its usability. The design
process must balance technical functionality and visual elements (e.g., mental model) to create a
system that is not only operational but also usable and adaptable to changing user needs.

Figure 19: User Interface for Login Figure

This interface describes login page user interface where unauthorized user cannot login into the
system but only authorized user that can register into the database can login into the system by
entering user name and password that perform their activity.so security can be perform.

Figure 20: User Interface for Department head

In the department head user interface of the class scheduling system, where the department head
performs various activities.
 Figure 21: User Interface for Student user

3.4 System architecture (Deployment diagram)

Deployment diagram is a structure diagram which shows architecture of the system as
deployment or distribution of software artefacts to deployment targets. Deployment diagrams
model the physical architecture of a system. It also shows the relationship between the software
and hardware. A deployment diagram shows how and where the system is to be deployed; that is,
its execution architecture.

Figure 21: Deployment Diagram

CHAPTER FOUR

4. Implementation
Implementation in the system includes implementing the attributes and methods of each object
and integrating all the objects in the system, to function as a single system the implementation
activity spans the gap between the detailed objects designed model and a complete set of source
code file that can be compiled together and the objective of systems implementation phase is to
convert the final physical system specifications into working and reliable system, document the
work that has been done, and provide help for current and future users and caretakers of the
system.

4.1. Over View of Programming Language Used

The project team used C# programming language to develop this system, since this programming
language is a general-purpose, object-oriented programming language that is structured and
open source , can support all major databases and web browsers. The project team also used
CSS, HTML and JavaScript to develop this system.

4.2. Algorithms Overview Used

4.2.1. Pseudo code
Pseudo code is compact and informal high-level description of a computer programming
algorithm that uses the structural conventions of a programming language but is intended for
human reading rather than machine reading. Pseudo code typically omits details that are not
essential for human understanding of the algorithm, such as variable declaration, system-specific
code and subroutine. The programming language is augmented with natural language
descriptions of the details, where convenient, or with compact mathematical notation. The
Purpose of using pseudo code is that it is easier for humans to understand than conventional
programming language code, and that it is a compact and environment-independent description
of the key principles of an algorithm.

4.2.2. Sample code

A. Pseudo code for login
The sample pseudo code used for login is:
User browse Login Page
Fill the Login Form
Click the Login button
If (Form is filled)
If (valid)
Generate SQL select queries Connect to database Pass queries to database
If (any query fails)
Display error message
Else
Read session
If session exists on database,
User is already logged in,
Display the page
Else if they're correct
Create session ID
Store session ID on database
Display the privileged page
End if
End if
Else Display error message Ask the user to refill the form
End if
End if
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data.SqlClient;
using System.Configuration;

namespace Web_Based_Class_Scheduling_System
{
public partial class LoginF : System.Web.UI.Page
{

string username1, Account_Type, password1, status1;

protected void Page_Load(object sender, EventArgs e)

{
}
protected void Unnamed3_Click1(object sender, EventArgs e)
{
SqlConnectioncon=new
sqlConnection(ConfigurationManager.ConnectionStrings["UserAccountConnectionString"].Con
nectionString);
 con.Open();

SqlCommand cmdcheck = new SqlCommand("select * from UserAccount where

UserName='" + txtsernamel.Text + "'", con);
SqlDataReader da = cmdcheck.ExecuteReader();
while (da.Read())
{
username1 = da.GetValue(1).ToString();
Account_Type = da.GetValue(2).ToString();
password1 = da.GetValue(3).ToString();
status1 = da.GetValue(7).ToString();
}
if (username1 == txtsernamel.Text)
{
string EncrptPwd = Encryptionpw.shaencryption(txtpaswdl.Text);

if (username1 == txtsernamel.Text && password1 == EncrptPwd)

{
if (DropDownListuserlogin.Text == Account_Type)
{
if (status1 == "Enabled")
{
if (Account_Type == "DepartmentHead")
{
Response.Redirect("DepartmentHead.aspx");
}
else if (Account_Type == "Acadamic_Council")
{
Response.Redirect("Acadamic_Council.aspx");
}
else if (Account_Type == "Registor")
 {
Response.Redirect("Registerar.aspx");
}
else if (Account_Type == "Quality_Assurance")
{
Response.Redirect("Quality_Assurance.aspx");
}
else if (Account_Type == "Student")
{
Response.Redirect("Student.aspx");
}
else if (Account_Type == "Instructor")
{
Response.Redirect("Instructor.aspx");
}}
else
{
Response.Write("<script>alert('your account is Disabled ')</script>");
}}
else
{
Response.Write("<script>alert('no user in this account type ')</script>");
}}
else
{
Response.Write("<script>alert('incorrect password ')</script>");
}
}
else
{
Response.Write("<script>alert('unknown user ')</script>");
 }}
protected void Unnamed2_Click(object sender, EventArgs e)
{
Response.Redirect("ForgetPassword.aspx");
}}}

B. Pseudo code for Create Class Schedule

User involved: department head
Fill the Appropriate information
Click the Create button
If (Form is filled)
If (valid)
Generate SQL select queries Connect to database Pass queries to database
If (any query fails)
Display error message
Else
Display the Successfully Created Message.
End if
End if
Else Display error message Ask the user to refill the form
End if
End if

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data.SqlClient;
using System.Configuration;
using System.Net.Mail;
using System.Net;

namespace Web_Based_Class_Scheduling_System
{
public partial class DepartmentHead : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
if(IsPostBack)
{
SqlConnection con = new
SqlConnection(ConfigurationManager.ConnectionStrings["ScheduleConnectionString"].Connect
ionString);
}}
void clear()
{
txtshdlId.Text = "";
txtAcdyr.Text = "";
txtCRS.Text = "";
txtinstctr.Text = "";
txtroom.Text = "";
txttmstr.Text = "";
txttmend.Text = "";
}
protected void btncrt_Click(object sender, EventArgs e)
{
if(txtshdlId.Text !=" " && txtAcdyr.Text !="" && txtCRS.Text !="" && txtinstctr.Text !
="" && txtroom.Text !="" && txttmstr.Text !="" && txttmend.Text !="")
{
try
{
SqlConnection con = new
SqlConnection(ConfigurationManager.ConnectionStrings["ScheduleConnectionString"].Connect
ionString);
con.Open();

string insertschedule = "insert into

schedule(Schedule_Id,Day,Acadamic_Year,Semister,Course,instructor,Room,Department,Type,
Time_Start,Time_End)
values(@Schedule_Id,@Day,@Acadamic_Year,@Semister,@Course,@instructor,@Room,@De
partment,@Type,@Time_Start,@Time_End)";
SqlCommand cmd = new SqlCommand(insertschedule, con);
cmd.Parameters.AddWithValue("@Schedule_Id", txtshdlId.Text);
cmd.Parameters.AddWithValue("@Day",
DropDownListday.SelectedItem.ToString());
cmd.Parameters.AddWithValue("@Acadamic_Year", txtAcdyr.Text);
cmd.Parameters.AddWithValue("@Semister",
DropDownListsems.SelectedItem.ToString());
cmd.Parameters.AddWithValue("@Course", txtCRS.Text);
cmd.Parameters.AddWithValue("@instructor", txtinstctr.Text);
cmd.Parameters.AddWithValue("@Room", txtroom.Text);
cmd.Parameters.AddWithValue("@Department",
DropDownListdep.SelectedItem.ToString());
cmd.Parameters.AddWithValue("@Type",
DropDownListype.SelectedItem.ToString());
cmd.Parameters.AddWithValue("@Time_Start", txttmstr.Text);
cmd.Parameters.AddWithValue("@Time_End", txttmend.Text);
cmd.ExecuteNonQuery();
 con.Close();
}
catch (Exception ex)
{
Response.Write("Error" + ex.ToString());
}
clear();
}
else
{
Response.Write("Enter Appropriet information");
}}}}

CHAPTER FIVE

5. Testing

5.1 Sample testing

5.1.1 Unit testing
Unit testing is software verification and validation method in which a programmer tests if

Individual units of source code are fit for use. The automated web based class schedule

Management system units are tested one by one.

By using this testing we have tested the entire modules of the system separately.

Sample unit testing that we have tested by this testing for login:
Test Case1:

Test Case Name: Login

Purpose: To verify (authenticate) authorized users

Input Expected Result Output Pass/Fail

Valid user name and The system Successfully The system Successfully Pass
password combination accept the user and display accept the user and display the
the profile page user profile page

Valid user name and Please check your Please check your User fail
invalid Password User Name, Name, Password and select
Password and select your your account

Table1: Sample unit Testing

account type and try again!!! type and try again!!!

Incorrect user Please check your User Please check your User Name, fail
name and Name, Password and select Password and select your
valid Password your account type and try account type and try again!!!
again!!!
Incorrect user name Please check your User Please check your User Name, fail
and Incorrect Name, Password and select Password and select your
Password your account type and try account type and try again!!!
again!!!
Null user name and "Pleas fill out this filed" by "Pleas fill out this filed" by fail
Password pointing the empty field pointing the empty field

User name and null "Pleas fill out this filed" by "Pleas fill out this filed" by fail
Password pointing the empty field pointing the empty field
 5.1.2. Integrating testing
Combining modules and testing them is called integration testing. Integration testing is
gradual. First we test the highest level, or coordinating module, and only one of its
subordinate modules. After unit testing, the automated web based class schedule management
system is also tested whether every unit is integrated to each other. This section presents the
integration testing where the units are tested together to see that they interact correctly. And
the linkage between the modules occurs through the usage of the database and the interface
subsystem.

We have used this testing technique viewing schedule:

Table 2: Sample Ingrate Testing For Viewing Schedule

Integrate testing for viewing schedule

Purposes = Student , Instructor , Quality Assurance , Department Head,

Test Data=type(empty) semester(empty),Academic year(empty),year section(empty),

Input Data Expected result

Empty type semester, Any invalid data for “Please fill the out this filed”
Academic year, year section, the other fields
and click submit button

Empty type semester, Any invalid data for “Please fill the out this filed”
Academic year, year section, the other fields
and click submit button

Empty type semester, All fields Full fills “the requested schedule is
Academic year, year section, with valid data displayed”
and click submit button

5.1.3. System testing

System testing of software or hardware is testing conducted on a complete, integrated system
to evaluate the system's compliance with its specified requirements. It is a testing process in which
the aim is to ensure that the overall system works as defined by the requirements.
 Is a testing process in which the aim is to ensure that the overall system works as defined
by the requirements?

Web based class schedule management system is functionally tested based on the use

case model developed during the analysis phase.

CHAPTER SIX

6. Conclusion and Recommendation

6.1 Conclusion
This class schedule management system is comprehensive web-based class schedule system
management system software. It is designed for better interaction between students,
instructor, Academic-council, Quality-Assurance, department head, Register and system
administrator. This management software is very gracefully handles all the requirements for
easy class schedule management system. The software being web based can be accessed from
anywhere in the world which enables the students, teachers, department head, record officer,
director and administrator the management be in touch with each other at all times.

6.2. Recommendation and Future Enhancement

Finally, we would like to recommend some points on the usage and accessibility of this
system. This system will give a solution for some of the problems in class scheduling system.
So we recommend to the all system users first see the website home page tabs guideline then
by using that guideline use this system properly. We recommended the following regarding to
this system on the user side:

To change the manual system into new system.

Attention should be given to the existing practice in the design, development and
utilization of the new system
To maintain the system timely.
The user must have basic knowledge computer.
The user must have basic skilled on the system how use the system.
Behavioural change of the users of the system to adapt the new system
We advise that the site be hosted on a secure server and that the administration of
the website is give to a person or entity that has experience in managing a website.
Finally the project teams concluded that the department should give a special
consideration for the computer lab, internet connection and last semester studying
credit hours specially for graduating student, because during the development of
the project the group members faced some problems because of this.
Future Enhancement
This system is specifically focus on total credit hours of course to assign time automatically
to create schedule for both lecture and lab class. So in the future it might good that will be
updated to focus lab and lecture hours to assign time during creating course schedule.

References
Book

 A.Hoffer. (2007). Modern Systems Analysis and Design (6th Edition).

 Boston: Allyn and Bacon(2000).Object Oriented System Analysis and Design(6th

Edition)

 James Rumbaugh, Ivan Jacobson, Grady Booch. The Unified Modeling

Language Reference Manual (5th Edition).

 Whitten, L.Jeffrey.Bentley, D.Lonne.Barlow, M.Victor. Systems Analysis and

Design Methods (2nd Edition). WEB BASED CLASS SCHEDULING SYSTEM
FOR ADIGRAT UNIVERSITY Department of computer science

Web

 https://www.google.com.et/#q=classroom+scheduling+system+documentation

 http://www.w3schools.com

 http:// www.uml diagram.org

 http://www.agilemodeling.com/artifacts/useCaseDiagram.htm

 http://guide.agilealliance.org/guide/acceptance.html

 http://en.wikipedia.org/wiki/Class_diagram

 http://www.mitre.org/publications/systems-engineering-guide/

 http://en.wikipedia.org/wiki/Systems_analysis

 http://en.wikipedia.org/wiki/Activity_diagram

 http://searchsoftwarequality.techtarget.com/definition/3-tier-application

 http://www.planet-source-code.com/vb/default.asp?lngWId=