COLLEGE OF COMPUTING AND INFORMATICS

INDUSTRIAL PROJECT I
DEPARTMENT OF INFORMATION TECHNOLOGY

Class Scheduling System

ADVISOR: DAGNE W(MSc)

HARAMAYA, ETHIOPIA

December 29, 2023

DECLARATION
This is to declare that the project is done by 4th year Information Technology department under
the title of Web based class scheduling system for haramaya university.

Project advisor Signature Date

________________ ________________ ________________

Project examiner Signature Date

1. ________________ ________________ ________________

2. ________________ ________________ ________________

3. ________________ ________________ ________________

Group Members Signature

Abebaw Tegegne ________________

Abel Dereje ________________

Esuyawkal Bishaw ________________

Chlota Ayele ________________

Simon Menta ________________

i
 ACKNOWLEDGMENT
First of all, we would like to thank our God. Then, we would like to really thank and appreciate
our advisor Mr. Dagne W. for his remarkable comments, suggestions and over all advice for us
from starting day of project up to the enter life cycle of the project without any tiredness. We
would like to thank our gratitude classmates and Group members for giving us a good guideline
for project throughout numerous consultations. We would also like to expand our deepest
gratitude to all those who have directly and indirectly guided us in doing this project work. We
are really thankful to them. Finally, we thank Mr. Wogayew A. who helped us by providing
important information during data gathering for our project

ii
Table of Contents
DECLARATION..............................................................................................................................i
ACKNOWLEDGMENT.................................................................................................................ii
List of Tables...................................................................................................................................v
Table of Figures..............................................................................................................................vi
List of Acronyms...........................................................................................................................vii
CHAPTER ONE..............................................................................................................................1
1. INTRODUCTION...................................................................................................................1
1.1 Background.......................................................................................................................1
1.1.1 Mission......................................................................................................................1
1.1.2 Vision.........................................................................................................................1
1.2 Statement of the Problem..................................................................................................2
1.3 Objectives of the project...................................................................................................2
1.3.1 General Objective......................................................................................................2
1.3.2 Specific Objectives....................................................................................................2
1.4 Scope of the project...........................................................................................................3
1.5 Significance of the Project................................................................................................3
1.6 Methodology.....................................................................................................................3
1.6.1 System analysis and design methodology.................................................................4
1.7 Feasibility studies..............................................................................................................5
1.7.1 Technical Feasibility..................................................................................................5
1.7.2 Operational Feasibility...............................................................................................5
1.7.3 Time Feasibility.........................................................................................................6
1.7.4 Economic Feasibility.................................................................................................6
1.8 Time schedule...................................................................................................................6
1.9 Budget Plan.......................................................................................................................7
1.10 Organization of the Project............................................................................................7
CHAPTER TWO.............................................................................................................................8
2. Requirement analysis...............................................................................................................8
2.1 Overview of the Existing System......................................................................................8
2.2 Problems with the existing system....................................................................................8

iii
 2.3 Overview of the Proposed System....................................................................................9
2.4 Specific Requirements....................................................................................................10
2.4.1 Functional Requirement...........................................................................................10
2.4.2 Nonfunctional Requirement.....................................................................................10
2.5 Business Rules................................................................................................................11
2.6 Model analysis (system models).....................................................................................11
2.6.1 Use case diagram.....................................................................................................11
2.6.2 Sequence diagram....................................................................................................21
2.6.3 Activity Diagram.....................................................................................................27
2.6.4 State chart modeling................................................................................................33
2.6.5 Class diagram...........................................................................................................36
2.7 User Interface Prototyping..............................................................................................37
CHAPTER THREE.......................................................................................................................38
3. System Design.......................................................................................................................38
3.1 INTRODUCTION..........................................................................................................38
3.2 DESIGN GOALS............................................................................................................38
3.3 PROPPSED SOFTWARE ARCHITECTURE...............................................................38
3.3.1 SUBSYSTEM DECOMPSTION.............................................................................38
3.4 Access control and security.............................................................................................42
References......................................................................................................................................43

iv
List of Tables
Table 1.0 software tools--------------------------------------------------------------------------------------5
Table 2.0 Time schedule-------------------------------------------------------------------------------------6
Table 3.0 Budget plan----------------------------------------------------------------------------------------7
Table 4.0 Use case documentation for login-------------------------------------------------------------13
Table 5.0 Use case documentation for Add Faculty Information-------------------------------------14
Table 6.0 Use case documentation for Add Department Information--------------------------------15
Table 7.0 Use case documentation for Add Instructor Information----------------------------------16
Table 8.0 Use case documentation for Add Course information--------------------------------------17
Table 9.0 Use case documentation for delete course information------------------------------------18
Table 10.0 Use case documentation to Add a Class Schedule-----------------------------------------19
Table 11.0 Use case documentation for search schedules----------------------------------------------20
Table 12.0 Access control and security-------------------------------------------------------------------42

v
 Table of Figures
Figure 1.0 Use case diagram..........................................................................................................11
Figure 2.0 Sequence diagram for login..........................................................................................20
Figure 3.0 Sequence diagram for adding information...................................................................21
Figure 4.0 Sequence diagram for updating information................................................................22
Figure 5.0 Sequence diagram for delete information....................................................................23
Figure 6.0 Sequence diagram for adding accounts........................................................................24
Figure 7.0 Sequence diagram for the add schedule.......................................................................25
Figure 8.0 Sequence diagram for the search schedule..................................................................26
Figure 9.0 Activity diagram for login............................................................................................27
Figure 10.0 Activity diagram for adding information...................................................................28
Figure 11.0 Activity diagram for adding user accounts................................................................29
Figure 12.0 Activity diagram for adding class schedule...............................................................30
Figure 13.0 Activity diagram for the searching schedule..............................................................31
Figure 14.0 State Chart modeling for login...................................................................................32
Figure 15.0 State Chart Modeling for adding information............................................................33
Figure 16.0 State chart modeling for search..................................................................................34
Figure 17.0 class diagram..............................................................................................................35
Figure 18.0 User interface Prototyping.........................................................................................36
Figure 19.0 System Architecture...................................................................................................38
Figure 20.0 Component diagram...................................................................................................39
Figure 21.0 Deployment diagram..................................................................................................40

vi
 List of Acronyms

Acronyms Their Respective Meaning

HU Haramaya university
UML Unified Modeling Language
OOSE Object-Oriented Software Engineering
UC Use case
GUI Graphical user interface
HUCSSDB Haramaya university class scheduling system
database
HTTP Hyper text Transfer protocol
CS Class schedule

vii
 CHAPTER ONE

1. INTRODUCTION
Scheduling is the process of arranging, controlling and optimizing work and workloads in a
production process or manufacturing process. Timetabling concerns all activities with regard to
producing schedules that must be subject to different constraints. The problem is managing a
timetable of all college classes. Accordingly, for any college, class scheduling management is a
complex and time-consuming task. The colleges used the manual method of preparing the class
schedule. With the manual system, more time and labor force are required to plot, arrange, and
revise the class schedules, room utilization and teacher load provided by the program committee.
With these problems, we propose a project in which an automated class scheduling system is
created that uses its own algorithm to assign resources in the most efficient and accurate manner.
This schedule management system module automatically creates schedules for the class and the
class teacher.

1.1 Background

Haramaya University (HU) is one of the oldest higher learning institutions in Ethiopia
established in 1954 E.C. with the intention of producing highly qualified graduates. HU was
established in the beautiful town of Ale maya, which is located approximately 510 km from
Addis Ababa, the capital city of Ethiopia. [1]

1.1.1 Mission

The mission of HU is to train competent graduates in diverse fields of study; undertake

knowledge-generating, problem-solving and cutting-edge research; and provide demand-driven
and transformative community engagement activities that contribute to sustainable local,
national, regional and global development. [2]

1.1.2 Vision

Haramaya University strives to be one of the top ten universities in Eastern Africa with an
international reputation by 2030.

1
1.2 Statement of the Problem
The existing class scheduling system at HU is susceptible to different labor 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; this is
a time-consuming process.
 Time conflict: While scheduling class, one class can have more than one course at the
same time. Class duplication is also based on time conflicts.
 Inconsistency of the data: There will be unavailability for future use since the data might
be misplaced during the manual scheduled class, so the data will not be preserved
properly for future use.
 Slow retrieval of data: Informor list, student list, building list, course list, and lecture
classroom list information is stored in paper, and it takes a long time to retrieve the data
(information).
 Difficulty managing class and laboratory room schedules.
 Overlapping of classes due to tiredness in checking each schedule.

1.3 Objectives of the project

1.3.1 General Objective

The general objective of this project is to develop a web-based class scheduling system for HrUs.

1.3.2 Specific Objectives

The specific objective of this project includes the following:

 Identify the user requirements through interviews, questionnaires and document analysis
 The system was designed for implementation with detailed UML specifications.

2
  A system that can replace the manual class scheduling system can be developed based on
the UML design specifications.
 Test the system for any defects using different white and black box test mechanisms
 Integrate help facilities with respect to the use of the application [3]

1.4 Scope of the project

The scope of the project includes the following functionalities:

 Class scheduling
 The view class is scheduled
 Offered courses from each department.
 Assigned instructors of each offered course.
 Assigned classroom.
 Allocated time (period) of each course.

1.5 Significance of the Project

After implementing this automated system, it is very easy to schedule classes. This system solves
the problems of previous time consumption and tiresome systems, saves considerable time and
money, schedules very quickly, delays avoid and helps the university reduce costs such as labor
and stationery. Moreover, it avoids wasting time in teaching and learning processes.

1.6 Methodology

Data collection methodologies are methods used to collect different data from different sources
(documents, users and organizations, etc.). The following are the data collection methods used
for data collection requirements.
Primary data sources
 Interview: We used interviews as one of the major data collection methods. During the
interviews, our team obtained different necessary information from the school director.
 Observation: As part of the learning process and as a student, we have gone through the
scheduling process.
3
  Document analysis: We analyzed different documents from the colleges and departments.
Secondary source data

 Internet: The internet helps us to access the available sample on the internet and to
download different types of tutorials that will help us complete the project.

1.6.1 System analysis and design methodology

The team chose to follow the object-oriented system analysis and design methodology during the
whole project life cycle (analysis, design, etc.) because of the many benefits that this approach
has overstructured, including reusability, quality improvement, maintainability and complexity
management. Hence, we applied the concepts of object-oriented system development
methodology throughout the project because it manages and assembles objects that are
implemented in our system and because of the composition of objects and interactions between
objects in the system. This process is categorized into two phases. These phases are: [4]

Object-oriented analysis

During this phase, we looked at the problem domain, with the aim of producing a conceptual
model of the information that exists in the area that has been analyzed. This model includes the
functions of the system (use case modeling), identifying the business objects, organizing the
objects and determining the relationships among them.

Object-oriented design

During this phase, model object interactions and behaviors support the use case scenario, and the
object model is updated to reflect the implementation environment. Additionally, we transform
the conceptual model produced in object-oriented analysis to take into account the constraints
imposed on our system format; thus, we use this phase to refine the use case model to reflect the
implementation environment.

Development Methodology

4
The development method we use to develop the proposed system is the waterfall approach/
Sequential. The system documentation process activities of specification, development,
validation and evolution are represented in a separate process phase.

Software Tools

Table 1.0 software tools

Activities Tools/Programs
ReactJS Is used for building user interfaces for web applications
Draw.io powerful desktop app used to draw UML diagram
Platform Windows
Documentation MS Word
User Training Power Point
Modeling UML (Unified Modeling Language)

1.7 Feasibility studies

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

1.7.1 Technical Feasibility

New systems are usually established to overcome the technical limitations of the previous
system. In the same way, this system is technically large enough to be applied easily to the
problems identified in the existing system. In addition, both hardware and software for this
system are highly available and can be owned at a low cost. Therefore, it can be concluded that
the system is technically feasible

5
1.7.2 Operational Feasibility

The system will operate on any operating system or platform on which Apache was installed.
Therefore, the system will operate on any kind of platform, so the entire team member expects
the system to be operationally feasible.

1.7.3 Time Feasibility

Time feasibility is the most important and superior consideration. The period of time considered
a resource under user control and sufficient to accomplish some work and it is an instance or
single occasion for some work. This system provides much faster and easy methods of recording
options and other various functionalities, as mentioned above in the objective section. This
system is feasible because it reduces the time required to with a paper-based operational
approach

1.7.4 Economic Feasibility

It involves the cost incurred on the system development team, the estimated cost of hardware and
software, the cost of performing feasibility studies and so on. The system will not incur much
more cost beyond the capacity of the university capital when automating the system, such as
costs for networking equipment, hardware and other infrastructures. Since the university is well
equipped with the required hardware and software, the project was found to be economically
feasible. Therefore, our system will be acceptable for solving problems economically.

1.8 Time schedule

Table 2.0 Time schedule
Activities Month
No October Novembe December January February Marc May
r h
1 Project title
submitted

6
 2 Analysis phase
3 Proposal
4 Design phase
5 Coding
6 Implementation
& testing
7 Project close-up

1.9 Budget Plan

Table 3.0 Budget plan
Material Quantity Unit price Price
personal computer - -

Human power 5 6000 30000

Coffee and tea 5 950

Flash disc 1 350 350

Mobile card 10 20 200

Paper and pen 350

Documentation printing - 3 350

Others 400

Total - - 32600

1.10 Organization of the Project

This document includes three chapters, namely, Chapter One: Introduction This chapter applies
for the acceptance of our project or determines whether our project is acceptable. The following
are the contents of the paper: “background”, “statement of the problem”, and “proposed system
7
chapter Two Requirement analysis”. This chapter includes subtopics such as existing system
descriptions, business rules, and functional requirements and diagrams such as use cases and
sequence chapter three system designs. This chapter mainly focuses on the process of defining
the components, modules, interfaces, and data for a system to satisfy specified requirements. It
includes subtitles such as the purpose and goal of design and the software architecture of existing
and current systems.

CHAPTER TWO

2. Requirement analysis

2.1 Overview of the Existing System

The manual system is quite tedious, and since the existing scheduling system is manual, it has to
process everything manually from the course offering to the final schedule. The tasks that are
currently performed in the registrar and departments regarding 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 were performed manually, and the
process was tedious, required considerable time, and needed great commitment and previous
skills. For better accomplishment of those tasks, a computerized system is the best and most
interactive because it reduces effort, costs and waste of time.

2.2 Problems with the existing system

The manual Class Scheduling system lies face down to various problems. These problems can be
identified from the following perspectives: performance, security, efficiency, budget, human
power and services given by the existing system to the users.
Performance

 Prone to error
 When the scheduler performs the scheduling process, overlapping (clashing) of
periods may occur.

8
  Time Consumption
o When additional timetables are processed every semester, the process of
arranging the schedule is very complicated since the scheduler needs to consider
many criteria.
o Preparing schedules for each department every semester takes a long time.
o If the scheduler makes an error when scheduling the time table, the recovery error
will be
take another time to regard.

Security and controls

The existing class scheduling system records are stored in plain text and are not encrypted.
Files that are stored as paper files can be lost, burneted or damaged by moisture or eaten.
by rats and termites. Therefore, it is difficult to control and secure these manual records since
they do not
have any authentication or authorization system.
Efficiency

Due to manual operation, most of the activities are prone to wasting resources such as paper.
man power, time, etc., to produce the corresponding outputs. This makes the current system
inefficient while utilizing resources. A mechanism should reduce waste of resources and increase
the efficiency of the system.
Input and output

In the case of the Haramaya University Class Scheduling system, the input of information is
redundant, inaccurate, not well organized and hard, and these inputs may lead to confusion and a
workload for employees and inaccurate output since the information is written in pen and on
paper.

2.3 Overview of the Proposed System

During our observation and interviews, we observed certain problems in the manual
9
based system. Therefore, we propose solving the problem of the existing scheduling system by
developing an automated web-based system. This means that our proposed system will minimize
the current problems and weaknesses of the existing system. The proposed system has several
other features, as follows:
 Accuracy in the handling of data.
 The procedure was fast and had an excellent response time.
 The system is flexible, i.e., it can be accessed at any time.
 Easy method of backing or duplicating data in case of data loss.
 Better storage and faster retrieval system.
 User-friendly interface.

2.4 Specific Requirements

2.4.1 Functional Requirement

A functional requirement defines the capabilities of a system that must be able to perform
successfully. The functional requirement is the study of what a system should be able to do, the
functions it should perform and the interactions between the system and its environment. In
addition, we explain what must be done by identifying the necessary task, action or activity that
must be accomplished.

The developed system is expected to provide the following functionalities:

 The department heads were allowed to assign classrooms to each section.
 Allow department head register subject and its credit hours
 The Allow Scheduler was used to add classrooms and sections.
 Patient information about the head of the department

2.4.2 Nonfunctional Requirement

For a system development to be fruitful, we need to examine our expectations about the system
and record them formally. One of the requirements of the system is nonfunctional. A
nonfunctional requirement is a requirement of the system related to how the system works. The
10
nonfunctional requirements of systems can be expressed as system usability, performance,
reliability and supportability. The following are the nonfunctional requirements of the CS
system.

Usability

To ensure the usability of the system (CS) for the Scheduler, the platform for hosting the system
is web based. A web platform is more familiar to the user than other platforms are, so the user
expertise required for using the system will be browsing pages in the browser. Anyone who can
access the internet via a browser has the level of expertise to use the system (CS).

User interface: The user wants the interface to browse easily to the graphical interface.
Reliability

The system should be reliable enough that when an inexperienced user attempts to use the
system and make an entry into the system, the system should recognize faulty inputs and queries.
The system should also handle exceptions when performing computations to create a schedule
and recognize the considerations that will be discussed in the functional requirement section. The
system should be accessible only by Scheduler, which has a username and password.

Performance

The new system has a faster response time and uses minimal space. The user task is time critical,
but compared with the current manual system, the system response time is acceptable.

2.5 Business Rules

A business rule is a statement that describes a business policy or procedure that must be fulfilled
and obligated for the system to function properly and effectively. The process of identifying
business rules is often iterative in this system, where rules begin as general statements of policy
in the system.
BR-1: No two courses can be scheduled for the same room at the same time.
BR-2: An instructor cannot teach two courses at the same time
BR-3: The department head must assign his department teacher to each section.
11
BR-4: The user of the system must have a legal account to complete the required information.
BR-5: In the classroom, two sections were not assigned at the same time.

2.6 Model analysis (system models)

2.6.1 Use case diagram

The different types of users of a system and the various ways that they interact with the
system. These included the actor, use case, system boundary and relationship.
• The actors that participate in our system are as follows:
Scheduler: an actor who manages the scheduling process. The scheduler is personnel
from the registrar office. The scheduler manages all the records needed for scheduling and
schedule class.
System user: can view and print class schedules.
Department head: - Perform the course-offing process and then send the offered courses
to the scheduler. [5]

12
 Figure 1.0 Use case diagram

Login

Table 4.0 Use case documentation for 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 each time he/she wants to use the system

13
 Actor Scheduler and User (Department Heads) not all System
user
Precondition The user must to be registered to user Account.
Post Condition If the user is authenticated the User logged into the
system and the system displays
all features available for the role associated with 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.

The use case ends.
Alternate Flows User fills invalid username and/or password
1. The system Displays error message.

2. The system prompts the user to re enter the valid

information.
Use case continues with BCA 2.

Addility Information

Table 5.0 Use case documentation for Add Faculty Information

Use Case Name Add College Information

Use Case ID UC2
Brief description Brief description This use case represents the procedure
which the Scheduler goes before using the system
14
 resource. It typically accomplished by typing information
of faculty and program on the form and sends to the data
base.
Actor Actor Scheduler Precondition Scheduler already login into
the system and load the Add faculty form Post Condition
Faculty information added to the database
Scheduler already login into the system and load the Add
Precondition 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 Scheduler has to enter the faculty information.
3. When the Scheduler click on the save button.
4. The system then validates the entry.
5. If it is correct save the file to the database.
6. The system shows success acknowledgment message.
7. The use case is end when Scheduler clicks the ok button.
Alternative course of action Entered Faculty already exists
1. system prompts error message
2. System display Faculty information already exists.
3. Use case ends.

Add Department Information

Table 6.0 Use case documentation for Add Department Information

Use Case Name Add Department Information
Use Case ID UC3
Brief description This use case represents the procedure which the Scheduler
goes to add information to the system . It typically
15
 accomplished by typing information of
Department information to the form and sends to the data
base.

Actor Scheduler
Scheduler already login into the system and load the Add
Precondition 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 Scheduler has to enter the Department information.
3. When the Scheduler click on the save button.
4. The systems then validate the entry.
5. If it is correct save the file to the database.
6. The system shows success acknowledgment message.
7. The use case is end when Scheduler clicks the ok button.
Alternative course of action
Entered Department already 1. system prompts error message
Exists 2. System display Department information already exists.
3. Use case ends.
Required information is 1. system prompts error message
Missing 2. System display Required Department information is
missing.
3. Use case continues with BCA2.

Add Instructor Information

Table 7.0 Use case documentation for Add Instructor Information

Use Case Name Add Instructor Information

Use Case ID UC4

16
 Brief description This Use case represents also which the Scheduler
accomplishes by entering
instructor information to the database
Actor Scheduler
Precondition Scheduler 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 Scheduler have to enter the Room information.
3. When the Scheduler click on the save button.
4. The system validates the entry.
5. The system will save the information to the database.
6. The system shows success acknowledgment message.
7. The use case is end when Scheduler clicks the ok button.
Alternative course of action Entered Instructor information already exists
1.The system Display the already exist message
2. The use case end
User inserts Invalid instructor information
1. The system Display the required information is missing
2. The use case continue with use BCA 2

Add Course information

Table 8.0 Use case documentation for Add Course information

Use Case Name Add Course Information

Use Case ID UC5
17
 Brief description This Use case represents also which the Scheduler
accomplishes by entering
instructor information to the database
Actor Scheduler/User (Department Heads)
Precondition Scheduler/User 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 Scheduler has to enter the Course information.

3. When the Scheduler click on the save button.

4. The system validates the entry.

5. The system will save the information to the database.

6. The system shows success acknowledgment message.

Alternative course of action 1Entered Course information
1. already exists The system Display the already
exist message
The use case end

Delete course information

Table 9.0 Use case documentation for delete course information

Use Case Name Delete Course Information

Use Case ID UC6

18
 Brief description This Use case represents also which the
Scheduler accomplishes by entering instructor
information to the database
Actor Scheduler
Precondition Scheduler already login into the system and
load the Course form
Post Condition Course Information Saved
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 Scheduler click on Delete button.
3. The system will prompt that he truly want
to delete the course.
4. When the Scheduler select Yes Button,
5. The system will delete the course
information entry from the database.
6.Thesystem shows success acknowledgment
message.
7. The use case is end when Scheduler clicks
the ok button.
Alternative course of action When the Scheduler select No Button,
1.The system Return back to the course page
2. The use case end

Add-Class Schedule

Table 10.0 Use case documentation to Add a Class Schedule

Use Case Name Add Class Schedule

Use Case ID UC7
19
 Brief description This use case allows the scheduler to setup
scheduling time for each year
Actor Scheduler
Precondition 1. The Scheduler already login into the
system and the system has load the Add
Class schedule form.
Post Condition The Class schedule data is saved to the
database
Basic Course of Action (BCA) 1.The use case starts when the scheduler load
class schedule page.

2.The system prompts the scheduler to select

departments that he or she wishes to Add
Class schedules.

3.The system display Add schedule form.

The Scheduler fills all the Required

information by selecting and by writing.

The use case is end when Scheduler clicks the ok

button.
Alternative course of action If Instructor have class on that time for other
year and section student
1.The system Display a message This
Instructor have schedule on this day and time
for this Year and section students.
Search Schedule

Table 11.0 Use case documentation for search schedules

Use Case Name Search Schedule

Use Case ID UC8

20
Brief description
Actor
Precondition
Post Condition
Basic Course of Action (BCA)
Alternative course of action
The user should be able to search and filter the schedule
information detail using different criteria.
All system User
The user is logged in to the system or not
Properties and schedule matching the criteria are displayed
in a report view.
1. The Use case Begin when the users click on search class
schedule link
2. The user select search schedule for Year and section Al
3. The system displays a search Form to select Year and
section, semester and academic year. 4. When the user click
on the Submit button
5. The system filters the data from the database according to
the search criteria’s.
6. The system displays a Search result as Report.
7. The user select Print Schedule Button
8. The system prompt the user to select his printer form list
Al
9. The system Print the Report
10. The use case is end when the user clicks on Back Button.
User Select Instructor schedule search 1. The user select
search schedule for Instructor 2. The system displays a
search Form to select Instructor Name, Semester and
Academic year. 3. use case continue with BCA 4
21
2.6.2 Sequence diagram

Sequence diagrams are used to model the logic of usage scenarios or to describe the potential
way the system is 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.

Figure 2.0 Sequence diagram for login

22
Figure 3.0 Sequence diagram for adding information

23
Figure 4.0 Sequence diagram for updating information

24
Figure 5.0 Sequence diagram for delete information

25
Figure 6.0 Sequence diagram for adding accounts

26
Figure 7.0 Sequence diagram for the add schedule

27
 Figure 8.0 Sequence diagram for the search schedule

2.6.3 Activity Diagram

An 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 a flowchart and data flow diagram
from structured development. [6]

28
Figure 9.0 Activity diagram for login

29
Figure 10.0 Activity diagram for adding information

30
Figure 11.0 Activity diagram for adding user accounts

31
Figure 12.0 Activity diagram for adding class schedule

32
Figure 13.0 Activity diagram for the searching schedule

33
2.6.4 State chart modeling

A state chart diagram is used for modeling the dynamic aspects of systems if it focuses on
identifying the behavior within our system, that is, the behavior specified to the instances of a
single class. This diagram is similar to the activity diagram. Both activity and state chart
diagrams are useful in modeling the lifetime of an object. However, the activity diagram shows
the flow of control from activity to activity, whereas the state chart diagram shows the flow of
control from state to state.

34
 Figure 14.0 State Chart modeling for login

Figure 15.0 State Chart Modeling for adding information

35
Figure 16.0 State chart modeling for search

36
2.6.5 Class diagram

A class diagram is used to describe the structure of a system by showing the system’s classes,
their attributes and the relationships between the classes. In addition, it shows the static
relationship between the classes. Classes identified from scheduling systems are specified by
adding possible methods to attributes for each class. The class used during this phase is detailed
to help the developer start developing the source code. [7]

37
 Figure 17.0 class diagram

2.7 User Interface Prototyping

User interface prototyping is an iterative development technique in which users actively interact

System User Loading Index home page

Login
38
 no
check Is user
yes

Is Schedule User home

yes
View course

Scheduler home
Search schedule
Manage schedule info
View schedule
View course
View course
Create class schedule

feedback

Figure 18.0 User interface Prototyping

CHAPTER THREE

3. System Design

3.1 INTRODUCTION

This chapter is concerned mainly with the design of the class scheduling system. To make the
implementation easy, the design is very important. In this chapter, we introduce the design goal,
system architecture, deployment diagram, persistence data management, access control and
security and user interface design in depth on the class scheduling system. Generally, this chapter
describes how the project is designed and what tasks are performed under this project.

39
3.2 DESIGN GOALS

The major design goals of the proposed class scheduling system are good response time,
portability, low cost, accessibility, minimized error, flexibility, and handle redundancy.

Good response time: This class scheduling system will be implemented in the PHP
programming language, which is generally easy to read for all browsers. The interfaces will be
designed such that information can be transmitted efficiently. The user waiting time is avoided
wherever possible. This approach minimizes the amount of time for registrative offices and
department heads to perform all the activities in class scheduling.

Portability: The class scheduling system is platform independent, so it runs through any
window.
Low cost: This proposed system minimizes the cost, which is the cost, of the paper and other
materials used by the current manual system.
Accessibility: The user can print their schedule at any time.

3.3 PROPPSED SOFTWARE ARCHITECTURE

3.3.1 SUBSYSTEM DECOMPSTION

i. Architectural view

The proposed system is a web-based system that can handle creating class schedules and keeping
records of related entities. CSs can create and manipulate the schedule created. There are various
entities that are the backbone of the system. These entities must be properly assigned to the
system so that the system functions as expected. This section of the paper concerns the design of
the system, which consisted of subsystem decomposition, hardware/software mapping, persistent
data management, access control and security, global software control, and boundary conditions.

Subsystem decomposition describes the decomposition into subsystems and the responsibilities
of each. This is the main product of system design. At this point, we identify the following as a
subsystem of the system.
40
 ii. Architectural layer

Figure 19.0 System Architecture

iii. Hardware and software mapping

This section describes the HW/SW mapping of the proposed system. To describe this, we use the
UML deployment diagram. A deployment diagram is a structure diagram that shows the
architecture of the system deployment distribution of software artifacts to deployment targets.
Deployment diagrams model the physical architecture of a system. The figure 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.

41
 A. component diagram

Clint Server Application Server Database Server

Add Schedule

Scheduler
Manage Schedule

Manage System

Persistent
View Schedule

Dep-head

Search Schedule

Users HUCSDB
Print Schedule

Figure 20.0 Component diagram

B. Deployment Diagram

The deployment diagram shows the hardware of our system, the software to be installed in that
hardware. It also shows how hardware and software components work together.

Client Web server application server Database server

42
 Request

Add Schedule

Web browser View Schedule

network Response HUCSSDB

Login

Manage System

Figure 21.0 Deployment diagram

3.4 Access control and security

Access control is a way of limiting access to a system or to physical or virtual resources. In

computing, access control is a process by which users are granted access and certain privileges to
systems, resources or information. In access control systems, users must present credentials
before they can be granted access. In physical systems, these credentials may come in many
forms, but credentials that cannot be transferred provide the most security. [8]

43
Table 12.0 Access control and security

Function Actors

Scheduler Dep-head System User

Add entry 

View course  

Add schedule 

View schedule   

Manage system user 

Manage schedule 

Submit sleep 

Search class schedule   

Print   

Login  

References

[1] https://www.haramaya.edu.et/history/.

[2] https://www.haramaya.edu.et/about/.

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

44
[4] https://en.wikipedia.org/wiki/Systems_analysis.

[5] https://agilemodeling.com/artifacts/useCaseDiagram.htm.

[6] https://en.wikipedia.org/wiki/Activity_diagram.

[7] https://en.wikipedia.org/wiki/Class_diagram.

[8] https://www.techtarget.com/searchsecurity/definition/access-control.

45