Final

BULE HORA UNIVERSITY
FACULTY OF ENGINERING AND TECHNOLOGY

DEPPARTMENT OF INFORMATION TECHNOLOGY
PROJECT1: DEVELOPING ONLINE CLASSROOMSCHEDULING SYSTEM
FOR BULE HORAUNIVERSITY
PREPARED BY:
NAME OF STUDENTS’ ID NO.
1. ATOMSA ARARSA……………………….…....1097/13
2. GIDISA MEGERSA…………………………….1115/13
3. KABTIMER KASSA.…………………….…......1124/13
4. LENSE ASFAW…………………………..……..1157/13
5. SHEMSADIN MOHAMMED……………..........1142/13
ADVISOR: MR.GEMADA,
MR.HUNDAOL
SUBMISSION DATE: 13/10/2009E.C

BULE HORA, ETHIOPIA
JUNE, 2017
OnlineO Classroom Scheduling System for BHU 2017
Declaration
The project is our own and is not presented for a degree in any other University and all the source
of material used for the project has been duly acknowledged. (Name and signature up to the
number of the project group member).
Name Signature
1. Atomsa Ararsa _____________
2. Gidisa Megersa _____________
3. Kabtimer Kassa _____________
4. Lense Asfawu _____________
5. Shemsadin Mohammed _____________
Faculty of:-Engineering and technology Department of:-Information Technology Project subject:-
Online Classroom Scheduling System for Bule Hora University I certify that this project satisfies
the entire requirement as a project for the degree of Bachlor of science Information technology.
Name of program coordinator: __________________________ Signature______________ This
is to certify that I have read this project and that in my opinion it is fully adequate, in scope and
quality, as a thesis for the degree of Bachelor of Science.
Name of Advisors 1. ________________________signature______________
2._________________________Signature_____________
Examining committee members
1. Chairman ______________________ Signature ___________________
2. Examiner 1 _____________________Signature ___________________
3. Examiner 2_____________________ Signature ___________________
It is approved that this project has been written in compliance with the formatting rules laid down
by the faculty of the University.
i
ACKNOWLEDGMENT
We express thanks and gratitude to our advisor Gemeda and Hundaol who is an instructor in
Bule Hora University, for his day to day encouraging support and guidance in carrying out the
project. We would like to express gratitude and indebtedness to our department members for
their valuable advice and guidance without which this project would not have seen the light of
the day. Moreover we would like to express thanks to Ato Dube team Scheduling system in
BHU who gave us the available information. And we would like to express our gratitude thank
for the staff members who are found in Registrar office for their supporting us during
information collection. Lastly we need thank our family who has supporting us by providing any
requirements for the success of this project.
ii
Contents
Chapter One ........................................................................................................................................... 1
1.1 Introduction ............................................................................................................................ 1
1.2 Background of Study ............................................................................................................. 1
1.3 Statement of Problem............................................................................................................. 2
1.4 Proposed System .................................................................................................................... 2
1.5 Objectives of the Project ........................................................................................................ 3
1.5.1 General Objective ........................................................................................................... 3
1.5.2 Specific Objectives ......................................................................................................... 3
1.6 Significance of the Developed Project .................................................................................. 3
1.7 Beneficiary Group of the Project ........................................................................................... 4
1.8 Scope of the Project ............................................................................................................... 4
1.9 Limitation of the Project ........................................................................................................ 5
1.10 Methodology .......................................................................................................................... 5
1.10.1 . Data Collection Method ............................................................................................... 5
1.11 System Development and Analysis Methodology ................................................................ 6
1.11.1 System Development methodology ............................................................................... 6
1.11.2 System Analysis and Design Methodology................................................................... 6
1.12 System Testing Methodology ................................................................................................ 6
1.13 System Development Tools ................................................................................................... 7
1.13.1 Hardware Development Tools: ...................................................................................... 7
1.13.2 Software Development Tools: ....................................................................................... 7
1.14 System Implementation Tools ............................................................................................... 8
1.15 Feasibility Study .................................................................................................................... 8
1.15.1 Economic feasibility....................................................................................................... 8
1.15.2 Operational feasibility .................................................................................................... 9
1.15.3 Technical Feasibility ...................................................................................................... 9
1.15.4 Organizational Feasibility .............................................................................................. 9
1.15.5 Ethical Feasibility ......................................................................................................... 10
1.16 Activity Plan/Time Table .................................................................................................... 10
1.17 . Cost Break Down Of the Project ....................................................................................... 10
1.17.1 Hardware development cost ......................................................................................... 11
1.17.2 Software cost ................................................................................................................ 11
CHAPTER 2 ........................................................................................................................................ 13
iii
2.1 Introduction to Business Area Analysis .............................................................................. 13

2.2 Existing System Description ............................................................................................... 13
2.2.1 Users of Existing System ............................................................................................. 14
2.2.2 Activities of the existing system .................................................................................. 14
2.2.3 Problems of current system .......................................................................................... 15
2.2.4 Forms and Reports Currently Used in the Existing System ....................................... 16
2.2.5 Structure of the Organization (System Arch) .............................................................. 17
2.3 The Proposed System........................................................................................................... 18
2.3.1 Description and Purpose of the Proposed System ....................................................... 18
2.3.2 Architecture of Proposed System ................................................................................ 20
2.3.3 Data processing architecture of the proposed system ................................................. 22
2.4 Requirement Determination ................................................................................................ 22
2.4.1 Functional requirement ................................................................................................ 23
2.4.2 Non_ Functional requirement ...................................................................................... 23
2.5 Software Requirements Specification (SRS):- .................................................................... 25
2.5.1 System Business Rule:- ................................................................................................ 25
2.6 Essential Use Case ............................................................................................................... 26
2.6.1 Actor Identification and Description ........................................................................... 26
2.6.2 Essential Use Case Diagram ........................................................................................ 27
2.7 Essential User Interface Prototyping ................................................................................... 28
2.8 Analysis Models................................................................................................................... 29
2.8.1 System Use Case Identification ................................................................................... 29
Actor Identification and Description .............................................................................................. 30
2.8.2 System Use Case Diagram ........................................................................................... 31
2.8.3 System Use Case Description ...................................................................................... 33
2.8.4 Sequence Diagram........................................................................................................ 47
2.8.6 Collaboration Diagram ................................................................................................. 66
2.8.7 Conceptual Class Diagram ........................................................................................... 71
CHAPTER 3 ........................................................................................................................................ 73
3.1 Purpose and Design Goals ................................................................................................... 73
3.2 Site Map ............................................................................................................................... 74
3.3 System Decomposition ........................................................................................................ 76
3.4 Layering Class Diagram ...................................................................................................... 77
3.5 Component Diagram ............................................................................................................ 79
iv
3.6 Deployment Diagram ........................................................................................................... 79

3.7 Design Class Diagram ......................................................................................................... 80
3.7.1 Inheritance class diagram ............................................................................................. 82
3.8 Persistence Modeling (For OOD)........................................................................................ 83
3.9 Access Control and Security................................................................................................ 85
List of figures
Figure 1 Structure of the Organization (System Arch). ..................................................................... 18
Figure 2 Architecture of Proposed System ......................................................................................... 21
Figure 3 Data processing architecture of the proposed system.......................................................... 22
Figure 4 Essential Use case diagram of classroom scheduling system ............................................. 27
Figure 5 Essential User Interface Prototyping.................................................................................... 29
Figure 6 System Use case diagram of classroom scheduling system ................................................ 32
Figure 7 Sequence Diagram for Login ............................................................................................... 48
Figure 8 Sequence Diagram for Building Registration Information ................................................. 49
Figure 9 Sequence Diagram for Create User Account ....................................................................... 50
Figure 10 Sequence Diagram for Assign Instructor ........................................................................... 51
Figure 11 Sequence Diagram for Assign Room ................................................................................ 52
Figure 13 Sequence Diagram for Search Schedule ............................................................................ 54
Figure 14 Sequence Diagram for View Course ................................................................................. 55
Figure 19 Activity Diagram for Building Register Information ........................................................ 61
Figure 20 Activity Diagram for Assign Instructor ............................................................................. 62
Figure 21 Activity Diagram for Create Schedule............................................................................... 63
Figure 22 Activity Diagram for Searching Schedule ......................................................................... 64
Figure 23 Activity Diagram for Assign Room ................................................................................... 65
Figure 25 Collaborative diagram of login .......................................................................................... 67
Figure 26 Collaborative diagram of Building Registration ............................................................... 68
Figure 27 Collaborative diagram of create account ........................................................................... 69
Figure 28 collaborative diagram of class schedule ............................................................................ 70
Figure 29 collaborative diagram of Assign Course............................................................................ 71
Figure 30 Class diagram of the classroom scheduling System .......................................................... 72
Figure 31 Site map .............................................................................................................................. 75
Figure 35 Deployment diagram .......................................................................................................... 80
Figure 36 Design Class diagram ......................................................................................................... 81
Figure 37 Inheritance class diagram ................................................................................................... 83
Figure 38 Persistence Modeling (for OOD) ....................................................................................... 84
v
List of Table
Table 1Hardware development tool...................................................................................................... 7
Table 2 Software development tools .................................................................................................... 8
Table 4 Hardware Cost ....................................................................................................................... 11
Table 6 Faculty of Engineering and Technology Forms.................................................................... 16
Table 7 Faculty of Natural and Computational Sciences Forms ....................................................... 17
Table 8 login interface ....................................................................................................................... 28
Table 9 Room Registration interface .................................................................................................. 28
Table 10 Login for System Use Case Description. ........................................................................... 34
Table 11 Create User Account ............................................................................................................ 35
Table 12 Register building information.............................................................................................. 36
Table 13 Update user .......................................................................................................................... 37
Table 14 Create Class Schedule.......................................................................................................... 38
Table 15 View course.......................................................................................................................... 39
Table 16 Assign building .................................................................................................................... 40
Table 17 Assigns room ....................................................................................................................... 41
Table 18 Search Schedule ................................................................................................................... 42
Table 19 Assign course ....................................................................................................................... 43
Table 20 Assign instructor .................................................................................................................. 44
Table 21 View feedback ..................................................................................................................... 45
Table 22 print schedule report ............................................................................................................ 46
Table 24 Access control and security ................................................................................................. 85
Acronym
BHU……….......................................................................................Bule Hora University
CSS…………………………………………………………………Cascading Style Sheet
OOP………………………………………………………………..Object Oriented Programming
PHP………………………………………………………………..Hyper Text Pre-processor
UML………………………………………………………………Unified Modeling Language
HTML…………………………………………………………….Hyper Text Markup Languages
MYSQL……………………………………. ……………………My Structured Query Language
GUI………………………………………………………………Graphical User Interface
UI………………………………………………………………..User Interface
vi
Abstract
Internet is the most widely used over the world to access and search any websites. Technically; the
term Web-Based system refers to those applications or services that are resident on a server that is
accessible using a Web browser and is therefore accessible from anywhere in the world via the
Web. (U.S. Department of Labor 2012-13). This project is a web-based (online) for Bule Hora
university office of registrar scheduling staff. The system is mainly developed to replace the
manual system of the office to make it online class scheduling system, with the ability of Keep
records of Facility, Department, Building, Room, Course, Instructor, Student and Schedule
information and allows Update and Delete as needed by respected user. This also helps the office
from wastage of time, money, man power as well as workload.
vii
CHAPTER ONE
1.1 INTRODUCTION
Internet is the most widely used over the world to access and search any websites. Technically; the
term Web-Based system refers to those applications or services that are resident on a server that is
accessible using a Web browser and is therefore accessible from anywhere in the world via the
Web. (U.S. Department of Labor 2012-13). The project title is Online Classroom Scheduling
System for Bule Hora University Office of registrar spastically scheduling staff. This project is
preferred to improve the load of existing manual system by automation or computerization. As
there are many problems face human being throughout his/her life it is obvious to solve many of
the problems using computers. When saying this as the computer is the modern technology
problem solver any one can solve his/her problem by developing the software for the problem.
These proposals have prepared is also the precondition for solving the main problems of
classroom scheduling system for Bule Hora University that was implemented manually.
Therefore, this work that manually performed needs to be automated or computerized to reduce
the problems that happened. This proposal includes the profile of the office, the problems in the
office, our objective, scope of the project and feasibility studies are clearly specified. Finally, the
tools and techniques we will use and the schedule is summarized as possible as to finish the
project in the given time by using selected methodologies.
.
1.2 Background of Study

Classroom scheduling system is handled by classroom scheduling in coordination with the
classroom requesting office or department. Effective class and classroom scheduling is critical to
the academic mission of all the University. It enables students to take the classes they need in a
timely manner and contributes to ongoing cost containment efforts through efficient space
utilization and good stewardship of valuable institutional resource. Bule Hora University (BHU)
was established to play its part in the national efforts of bringing quality and excellence in
teaching-learning. Research, community services, administrative functions/good governance,
1
connecting the development of cultural and natural resources with technology and its
applications.Bule Hora University is one among the public universities established by the federal
democratic republic of Ethiopia to provide the higher education in the country through teaching
research and community service. The Classroom scheduling system in Bule Hora University is
practiced manually here from 107 rooms approximately till now. After preparing the Schedule for
students they store the detail information manually in the registrar office, then the scheduler report
the programs to departments and other university communities by posting on the announcement
board. The function of the Classroom scheduling system is to keep Track of student, course, class
and instructor’s information. This classroom scheduling staff works like University administrator
and the workers of department staff. Office of the Registrar is an office that consistently works to
provide quality student record information such as official transcript, medium of instruction,
enrollment and degree verification, preparation of academic calendar and class room scheduling
for the university.
1.3 Statement of Problem

Among the problem the following are the most severe ones:-
 It gives manually service.
 Class room optimization problem.
 Clash of classroom for students.
 Not user friendly.
 Manual data handling is more prone to error
 Existence of data duplication
Generally speaking the current class scheduling system of Bule Hora University is time
wasting and not efficient, so by organizing the above points we develop online classroom
scheduling system that solves the above mentioned problems
1.4 Proposed System

Depending on the problems identified above the following solution can be considered to address
the problems.
 Automating service given by the system to increase performance of the system.
2
 Develop more securing data.

 Make the system back up file to prevent loss of data
1.5 Objectives of the Project

1.5.1 General Objective
The main objective of this project is to develop online classroom Scheduling System for Bule Hora
University.
1.5.2 Specific Objectives

The specific objective of this project can be summarized as following:-
 To assign classroom online.

 To develop user friendly interface
 To provide year section (students), Instructors and Course schedule as report form.
 To search the classroom online.
 To secure system in the form of account, password and permission using different
algorithm
 To Store Faculty, Department, Building, Room, Year section (students), Instructors and
Course information and retrieve it when needed in report form.
1.6 Significance of the Developed Project

After this project is finished and properly used it gives incredible benefits to the scheduling staff,
Department (user) and students.
The Propose system has the following significance:-
 Students, Instructors and other users are able to search the information and see their
results online.
 The system provides all the information need for classroom scheduling.
 The administrator can add users, edit user information and delete user if it is needed.
 The system is Store, Update, and Retrieve the classroom schedule in safe and in reliable
manner .For security reason the system use user name and password for administrator,
scheduler, and system user (Department).
3
 Remove Classroom optimization problem.

 Reduce overlap in classroom scheduling.
 Reduce operation time.
 Minimize the work load of the scheduler by developing computerized system.
1.7 Beneficiary Group of the Project

This project is significant for the University especially for the Registrar by facilitating the day to
day activities and by improving the overall performance of the company. In addition to these:
Students
Scheduler
Instructors
Department(user) and other research workers will use the documentation of this project
as a resource for doing another improved system
1.8 Scope of the Project

This project is to develop web based classroom scheduling system, specifically for Bule Hora
University. In this system the following are included:
Classroom scheduling is only for Regular and weekend students of Bule Hora university
Assign Course.
Assign Instructor information.
See frequently asked questions (FAQ) to get how to help.
Register:-
 Faculty information.
 Department information.
 Building information.
 Room information.
 Course information.
 Student information.
 Instructor information.
Send feedback.
Create class schedule.
Search student’s course.
Assign Room for year and section (student).
4
Create User account.

Search the class schedule.
Provide backup mechanism in case of failure.
1.9 Limitation of the Project

The Project does not include:
 Tutorial class and summary
 Exam classes and extension.
 Night class
1.10 Methodology
1.10.1 . Data Collection Method
The methodology also refers to the overall approach that we use to do our final project. There are
many methodologies that we have to use to gather the necessary information for the new proposed
system. These are:-
Interview
It is the method of gathering information from the respondent in interview we communicate with
the Bule Hora University office of the Registrar Director and Scheduler and to identify the special
task what they have done to solve the problem of the existing system.
Observation
Finally we have observed the working environment to assure those requirements gathered using the
interview and existing document analysis are correct, this method of data collection is very
important because it help us to understand how the existing working environment is look like and
in addition to that it help us to decide how our system should be.
Analyzing Existing Document
In addition to the interview we analyze the existing document to gather the necessary information
for our project.
Questionaries’ forms
5
These mean that by preparing question to the scheduler gathering information from the registrar
directors.
1.11 System Development and Analysis Methodology

1.11.1 System Development methodology
We will use object-oriented methodology because of the following reason:

 It implements the concept of object orientation like inheritance, encapsulation, and
polymorphism.
 The ability to challenging the problem domains.
 to make simple communication among users, analysts, designers and programmers
 it also unaffected to change because it uses prototyping and Unified Modeling
Language(UML) tools that minimize development time
 Use case diagram, Activity diagram, sequence diagram, class diagram, data modeling and
deployment diagram
Above all the object-oriented methodology is selected because it is the current applicable models
that uses different models to analysis and design the project
1.11.2 System Analysis and Design Methodology
In the analysis and design of our project we are going to use object oriented analysis and designing
methodology. The methodology that we will use is prototyping because this methodology enables
us to do analysis, design and implementation concurrently. For the above reason we will use
prototyping and UML for analysis and design respectively.
1.12 System Testing Methodology

In order to deliver this system as well operated system we will test this project at implementation
phase by using different types of testing methodologies. Those testing methods are:
I. Unit testing: -we are going to test the independent module using this mechanism
of testing.
6
II. Integration testing: - using this type of testing method we are going to test the
modules which are independent and dependent to each other.
III. System Testing: -using this methods we will test the functionality of all modules
considering as a single system
1.13 System Development Tools

1.13.1 Hardware Development Tools:
Item no Hardware Capacity Specification

RAM
1 4GB Process data
Toshiba Core i3 PC To work the project virtually in

2 500GB
addition to desktop
Desktop computer
3 500GB To do overall activities
To transfer files from pc to

4 Flash memory 8 GB
Desktop and vice versa.
Table 1Hardware development tool
1.13.2 Software Development Tools:
Item no Software Specification

1 Microsoft word To write the documentation part.
2 VISIO UML To draw diagram
3 WAMP Server To make the website dynamic.
7
4 Dreamweaver cs6 To write code in a simple.
Table 2 Software development tools
1.14 System Implementation Tools

Database and Implementation Tools
The tools that we will use to accomplish the project are:
Server side scripting: PHP, we have selected PHP for server side scripting because it has the
following advantages; PHP has resource allocation machines and it can support object-oriented
programming.
Client side scripting: by considering the following characteristics we use java script-: can be
embedded in HTML page, its popular.
Database: MYSQL rises to become one of the most popular database servers in the world. This
popularity is because of the servers speed, robustness and flexible. MYSQL has arguable become
PHP most popular database counterpart.
Static webpage: HTML is highly flexible with CSS and JavaScript.
Window -7 operating system -: it has good Graphical User Interface (GUI) and also we are
familiar with it. It also support apache server to run on it.
Power point and MS-word-: for Documentation and presentation.
1.15 Feasibility Study

Once the team understands the problem found in the system, the next step is to conduct which high
level capsule version of the entered system and design process.
1.15.1 Economic feasibility
The computerized system takes care of the present existing system’s data flow and procedures
completely and should generate all the reports of the manual system besides a host of other
management reports. Depending on this we are going to determine benefits of this project by
dividing into two. Those are tangible and intangible benefits.
A) Tangible Benefits:
8
According to our determination the project we are going develop will provide the next benefits
as tangible benefits. Those are:
 Cost reduction and avoidance
 Error reduction
 Increase speed of activity
B) Intangible benefits:
The benefits that we have determined under economic feasibility as intangible benefits are:
 Reduce Resource Consumption
 Increase security
The system to be developed is economically feasible and the benefit is outweighing the cost. Since
this project already computerizes the existing system, by now the reduction of cost for materials
used in manual operation becomes beneficiary to the organization.
1.15.2 Operational feasibility
The system to be developed will provide accurate, active, secured service. And also it is plat form
independent i.e. it run’s in all operating system. Proposed projects are beneficial only if they can be
turned into information systems that will meet the organizations operating requirements. In the
existing manual system, the new system was considered to be operational feasible.
1.15.3 Technical Feasibility
The system is going to be developed by following the php language, html, java script, MySQL and
other language and we have the ability to develop this system without any difficulty since the team
has studied the required methodologies and tools. So the system will be technically feasible.
1.15.4 Organizational Feasibility
Organizational feasibility attempts to developing and implementing a new system, against the
benefits that would accrue from having the new system in place. This feasibility study gives the top
management the organizational justification for the new system. So that the new system was
considered to be organizationally feasible.
9
1.15.5 Ethical Feasibility
Ethical feasibility is a test to determine if the project is ethical, or even legal. Ethical feasibility
should be tested from both the organizational perspective, as well as the developer’s
perspective. The organization has a vested interested to develop applications that show they are
both professional and ethical. Therefore our project keeps all legal and ethical of the country and
the society.
1.16 Activity Plan/Time Table

The time allocated for the smooth flow of the project by the team members is described in the
following table.
2016 2017
No Task Name Start Finish Duration
Dec Jan Feb Mar Apr May Jun Jul
1 proposal 14/11/2016 23/11/2016 1.6w
2 Requirement gathering 24/11/2016 9/12/2016 2.4w
3 System anasis 1/12/2016 30/12/2016 4.4w
4 System design 2/1/2017 10/2/2017 6w
5 Implementation or code 13/2/2017 24/5/2017 14.6w
6 Test and recommendation 1/6/2017 31/7/2017 8.6w
Table 3 Time Table or Activity plan
1.17 . Cost Break Down Of the Project

This is for the budget invested to develop the system or total development cost of the system
through life of project. The tangible costs to be incurred in developing the system are:-
10
1.17.1 Hardware development cost
No Material Amount Unit price(Birr) Total price

1 PCi3 Toshiba 1 10,000.00birr 10,000.00birr
1 Paper (A4 ) 2 packet 180.00birr 180.00birr
2 Pen (lexi5) 5 5.00birr 25.00birr
3 Flash memory (8GB) 1 300.00birr 300.00bir
4 CD-RW 2 20.00birr 40.00birr
5 Copy - 200.00birr 200.00birr
6 Print - 500.00birr 500.00birr
7 Total 11245.00birr
Table 4 Hardware Cost
1.17.2 Software cost
No Material Price per unit
1 Microsoft office 2010 900
2 Visual paradigm 12.0 800
11
3 Rational Rose Enterprise Edition 700
4 wampServer 700
5 Notepad++ 10000
Total 13100.00 Birr
12
CHAPTER 2
2.1 Introduction to Business Area Analysis

Systems analysis is a process of collecting factual data, understand the processes involved,
identifying problems and recommending feasible suggestions for improving the system
functioning. This involves studying the business processes, gathering operational data, understand
the information flow, finding out bottlenecks and evolving solutions for overcoming the
weaknesses of the system so as to achieve the organizational goals. System Analysis also includes
subdividing of complex process involving the entire system, identification of data store and manual
processes. Systems analysis is an iterative process that continues until a preferred and acceptable
solution emerges.
2.2 Existing System Description

The BHU Registrar Directorate works its work by using manual approach that needs high cost as
well as low in speed to complete specific task. This directorate manages scheduler and system user
information proceeding through series of process. The works of this directorate is to find user who
need schedule; then the director of this directorate will discuss with dean directorate of academic
staff and administration staff how to students or teachers based on the level of education with
respect to department or field they have studied. First let us see how the registrar office prepare
Scheduling; the scheduler collect all course from each department and write it in Microsoft word,
then the scheduler prepare a table in Microsoft access for each department and sections, the table
have educational time (2:00-5:50 and 7:30-11:20), educational days (Monday – Friday). then
Scheduler creates a schedule by drag form list of courses and drop in to tables for the section that
he already created, when he finished this, he sends it to the faculty to verify it finally the schedule
distribute for all the department heads, and announce the schedule to all of the university
community by posting in announcement boards. In the register office there is a work division and
we described as the follow:
13
1. Registrar Director
The Registrar director manages and control over all function of the registrar and responsible for
collecting Schedule inputs and prepare schedule, the Scheduler typically accomplished by typing
information of college and course on the Microsoft Office Access:
 Assigning Building
 Assigning Room
 Verification of Schedule.
 Send Report to all respective departments
2. Vice Director
 placed beside Registrar director
 coordinate the activities of record officers

3. Record officer
The record officer responsible for the following responsibilities

 Registration
 Keeping records
 Generating report for registrar director.
2.2.1 Users of Existing System
The users of existing system are:

Registrar directorate: - this office uses the system to maximize the performance
of the organization by decreasing the expenses required to complete specific task.
Departments: - The departments use this system to assign course and instructor.
Students: -The students use this system to view schedule.
Instructors: -The instructors use this system to view schedule. ` .
2.2.2 Activities of the existing system

The major and fundamental functions of the existing BHU classroom scheduling system are the
following:
14
Preparing the schedule for each year and section.

Print Saved Schedule.
Assign :-
 Room Information.
 Instructor Information.
 Course information.
2.2.3 Problems of current system

Problems are undesirable situations that hinder the registrar from fully achieving its purpose, goals
or objectives. Assigning classrooms, instructors, courses and viewing schedules are done by
director but under director there is one person who helps to prepare the schedule that is the
scheduler. The staff has some problems like Clash of classroom, Assign instructor for more than
one year section (students) at a time, Assigning classroom more than its capacity, inefficient way
of using resource like class room and some related problems as follow:-
1. Absence of security:-The BHU classroom scheduling system is using paper to store schedule’s
information that can be accessed by anybody who may enter that office. The schedule’s secret
accessed by any person. Hence it has no security.
2. Use a lots of times: - To assign classrooms, instructors, courses and preparing the schedule
report.
3. Not user friendly: - The existing system is not user friendly because there is no simple and
formal way to generate schedule, the mechanism and the method of generating class room
scheduling is known by one person, if something happens on this person the staff can’t cover his
work.
4. Inability of sharing the data: -Data cannot be shared in the existing system. This means that no
two persons can use the same data in existing system. Also the two departments in a campus
cannot interact with each other without the actual movement of data.
5. Inability of modification of data: - As we say previously there is a lot of paper work because
all the transaction is done in printed paper, so this makes difficult or inability the modification.
6 Existence of data duplication: - In this system the same data will be saved by different users
because no such system that protect data from duplication
15
7. Presence of data loss: - The data in this system is not secured since it is saved by using paper or
manual approach useful information may lose unfortunately by different factors.
2.2.4 Forms and Reports Currently Used in the Existing System
Forms and reports are fundamental for the existence of different process to fill something or
different scheduling information. Some of The existing classroom scheduling system uses the
following forms and documents. Major Forms in existing system are:-
Faculty of Engineering and Technology Forms:-
No. Department Year and Expected Group Class Room Given Block Number Total no. of
Class Room
Given for each
Dept.
1. 9
Pre -Eng 1st (G1,G2,G3,---G20) LH,LH,LH,LH,R1,R5 021,032,033&036,126,114

2. R1,2,3 107 5
2nd (G1,2),3rd (G1,2,3,4)and R4 116
Civil 4th (G1,2,3) R5,6 112
3. 5
R4,5,6 107
2nd (G1,2,3),3rd (G1,2,3)and R3 116
Electrical 4th (G1,2) R6,7 114
4. 5
R1,2,3 109
nd rd R3 114
2 (G1,2,3),3 (G1,2,3) and
Mechanical 4th (G1) R8 116
5. 4
2nd (G1,2),3rd (G1,2) and 4th R4,5,6,7 109
CoTM (G1,2) R3 112
6. 2
R1 108
Hydraulics 2nd (G1,2), 3rd (G1,2) R4 114
7. 2nd (G1),3rd (G1) and 4th 2
Chemical (G1),5th (G1) R1,2 106
8. R1,2,3 110 5
1st (G1,G2), 2nd (G1,2),3rd R1 116
CS (G1,2,3), 4th (G1,2) R2,4 114
9. 1st (G1,G2), 2nd (G1),3rd R4,5,6 110 3
IT (G1,2),4th (G1) R4 114
10. 1st(G1,G2), 2nd (G1) & 3rd R1,2 112 2
IS (G1) R9 114
Table 5 Faculty of Engineering and Technology Forms
16
Faculty of Natural and Computational Sciences Forms:-

No. Department Year and Expected Group Class Room Block Number Total no. of Class
Given Room Given for
each Dept.
1. 3
1st (G1,G2,G3), 2nd(G1), 3rd R3 118
Biology (G1) R1,2 120
2. 3
1st (G1,G2,G3), 2nd(G1), R2 118
Chemistry 3rd(G1) R3,4 120
3. 3
1st (G1), 2nd(G1),3rd(G1), R5,6 118
Geology 4TH(G1) R4 119
4. 3
1st (G1,G2,G3), 2nd(G1), R1 118
Mathematics 3rd(G1) R5,6 120
5. 3
1st (G1,G2,G3), 2nd(G1), R4 118
Physics 3rd(G1) R5,6 119
6. 1st (G1,G2,G3), 2nd(G1), 3
Statistics 3rd(G1) R1,2,3 119
7. 1
Nursing 1st year (G1)
8.
Midwifery 1st year (G1) R1 114
Table 6 Faculty of Natural and Computational Sciences Forms
2.2.5 Structure of the Organization (System Arch)

The structure of the organization can be described either based on hierarchical or based on function
of the organization.The following shows the hierarchical top-down structure of Classroom
scheduling system of BHU:-
17
Figure 1 Structure of the Organization (System Arch).
2.3 The Proposed System

2.3.1 Description and Purpose of the Proposed System
The proposed system provides detail general information about the classroom scheduling system. It
enhances the class scheduling in adding, viewing and updating schedules system. To reduce the
work overload and increase quality distributes the functions to different sections based on the
relevance they have to the job. Such work division highly relieves the registrar from doing
redundant and tiresome jobs daily. It should also have the accuracy of information, timelines (both
in being up-to-date and available when required), easy of processing documents, easy of taking
out/insert data/information from/to database (for Registered users), easy of searching and viewing
the search result that can be save for any system user and providing good service for all.
The system provides the following Facilities
1. Faculty, Department, Building, Room, Course, Instructor, Student information registration.
2. Prepare Schedule by effectively assigning :-
18
1. Student - the year and section that takes the course.

2. Course - The course that is taken by students.
3. Time - The Education time (2:00-5:50 and 7:30-11:20).
4. Instructors - The one who teach the student.
5. Room - The place where the student grasp the knowledge.
3. Keeping records of Faculty, Department, Building, Room, Course, Instructor, Student and
Schedule information and allows Update and Delete as needed by respected user.
4. Search the schedule of:-

1. Student - To know when (the Day and Time), where (the Room) and by whom (the
Instructor) they have the schedule (class).
2. Instructors - To know when (the Day and Time), where (the Room) and to whom (the
Students (year and Section)) he have the schedule (class).
3. Room - To know when (the Day and Time), by whom (the Students (year and
Section)) and Instructor the room is reserved.
5. Retrieve the searched schedule as report that can be saved.
6. The Administrator of the system can post announcement to anonymous system users and the
system users can give comment for each announcement.
7. In order to communicate the four User levels we use:

1. Feedback - from anonymous user to the Admin.
2. Admin can Send and Receive notice to/from the Scheduler.
3. Admin can Send and Receive notice to/from the user (Department Heads).
4. The user (Department Heads) can Send and Receive notice to/from the
Scheduler.
8. The System will show the overall activities that are done in the system to the Admin by using
History Log function.
9. The system able to create account for the system users by providing all the required
information and update this information when it is needed, and this capability is given to the
Administrator of the system.
19
10. The system provide Backup mechanism, the administrator of the system can take a backup of
the systems database, and the system will save the backup in specified folder with backup
taking day and time.
Purposes of Proposed System

 It saves costs and energy of users.
 Very fast and accurate.
 No need of any extra manual effort.
 No fever of data loss.
 Very easy to find class schedule information.
 Save Time management in classroom scheduling of Bule Hora University office of
registrar.
 Prepare user friendly classroom scheduling system.
2.3.2 Architecture of Proposed System
The proposed system is expected to replace the existing manual system by an automate system.The
system will be host on a web server, where users are able to access it from a PC or laptop or mobile
device using a browser. This allows for the system to be accessible from different operating systemand
devices but it will also easily manageable. It will also decrease the schedulers effort when scheduling a
class for the whole year and section by allowing the schedule to select some options and fill the other
information, and then the system add the schedule when the scheduler press save button.
20
Figure 2 Architecture of Proposed System
21
2.3.3 Data processing architecture of the proposed system
HTTP Request
Internet Cloud
HTTP Request
Firewall
HTTP Request
Network Devices
Server Request/
Response
BHUOJTS Database
Figure 3 Data processing architecture of the proposed system
2.4 Requirement Determination

One of the first activities of an analyst is to determine the business requirements for a new system.
This section begins by presenting the requirements definition, a document that lists the new
system's capabilities. It then describes how to analyze requirements using business process
automation, business process improvement, and business process reengineering techniques and
how to gather requirements using interviews, questionnaires, document analysis, and observation.
22
2.4.1 Functional requirement
Functional requirements describe the interactions between the system and its Environment
independent of its implementation. The environment includes the user and any other external
system with which the system interacts. The system performs the following activities: -
Record Faculty, Department, Building, Room, Course, Instructor, Student and
Schedule information.
It allows Update, Delete and Stored information as needed by respected user.
Validate the data when the user tries to store

The system allows Search and Retrieve the information needed in Report formthat can
be saved.
Prepare schedule for each year and section by effectively assigning Room, Course,
Instructor without overlap.
The systems have a place to post notification to system users and the system users can
give comment for each announcement.
The System will show the overall activities that are done in the system to the Admin
by using History Log function.
The system able to create account for the system users by providing all the required
information and update this information when it is needed, and this capability is given
to the Administrator of the system.
2.4.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 .There are many non-functional requirements ranging
from user interface to security issues. Generally non-functional requirements of the system can be
viewed as follows.
2.4.2.1 Performances
 Speed: - the system should perform at optimum speed at normal circumstances (i.e.,
when networks and nodes are ok).
 Robustness: - The system should be tolerant of errors and produce error reports that are
simple to be understood by the users.
23
 Reliability: - The system should be reliable in generating schedule without any overlap.
 Scalability: - The system should be scalable in generating schedule without any overlap.
2.4.2.2 User Friendly Interface
Since there are potentially many users of this system, it will have different types of user
interface. It will include the necessary features for each user so the application will have a
user friendly interface for low knowledge of computer users, and simple and interactive
user interface components should be part of the system
2.4.2.3 Documentation
System administrators will receive project prepared documentation about the database schema and
documentation on the code of the system. This will help the system administrators on the
occurrence of problems to understand its structure and to facilitate maintenance of the system
easily.
2.4.2.4 Guide and Help
Frequently Asked Questions are included in the system and as help or tips hover action (when the
mouse placed on some buttons or links it have to show what the user can do with that) is should be
available for the end-users.
2.4.2.5 Security Issue
The system should be protected with different security features (techniques) on both the software
and hardware part.
 On software part: - on this part when the registered user wants to login firs he
has to select his/her privilege (means Administrator, Scheduler or User) then the
system will display login page to enter his user name and password. This protects
the system from any unauthorized access. Without Administrator, scheduler, and
User other users (anonymous system users) can’t add, edit, delete any data, but
they can view information they need by preparing query to the system and the
system will display the result as report...
 On hardware part: - the server is expected to be placed in a secured room.
24
2.4.2.6 Backup and Recovery

 The system should be holding a backup of the data.
 The system should be available any time without interruption back
2.4.2.7 Error handling requirement

 The system should have error handling mechanisms that is, as errors occur it should not stop
functionality of the system rather provide error manages and should guide the user through
what to do next.
 The system can run at any operating system and hardware (or it is platform).
2.5 Software Requirements Specification (SRS):-

A software requirements specification (SRS) is a comprehensive description of the intended
purpose and environment for software under development. The SRS fully describes what the
software will do and how it will be expected to perform. It defines how an application will interact
with system hardware, other programs and human users in a wide variety of real- world situations.
2.5.1 System Business Rule:-
Online online classroom scheduling system has its own business rule to give service for the
registrar and departments how it facilitates the service and the type of services which are
functional used by whom. The rules included are:-
BR#1: 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.
BR#2: Validate users Information: - if the user registered correctly then the system will validates
the user information and then authorized to use the system.
BR#3: Correct Information: -The user should also control the information that enter to the system
and come out of the system are correct.
BR#4: The Administrator 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.
BR#6: Uniqueness: A student (year and section), Instructor, Room, Faculty and Department must
have unique ID.
BR#7: Each course should have a unique course code
25
BR#8: The system must get input the list of Course, Instructors, Room and Year section (student)
for Scheduling
BR#9: The schedule always prepared before the beginning of each semester.
BR#10: System should provide various reports in accordance with request information i.e. (about
Students, Instructor, and Room schedule (weekly or for the semester).
BR#11: The report should be clear and summarized.
2.6 Essential Use Case

An essential use case describes the interaction between the user and the system at a high level of
abstraction. The goal of an essential use case is to convey the most important aspects of the user-
system interaction by focusing on the user’s intent and on the observable result of the system.
Since an essential use case describes only the most important information it represents a single
success scenario. The actors that interact with the system are the scheduler; user and administrator.
2.6.1 Actor Identification and Description
The following four actors are identified in classroom scheduling system:-

1. Administrator: - Administrator is a person who is responsible for observe the overall activities
in the system.
26
2. Scheduler: -Preparing the schedule for each year and section.
3. User (Department Heads):-Assign course, instructor and print schedule
4. System User (anonymous user):-view the printed report the schedule.
2.6.2 Essential Use Case Diagram
Figure 4 Essential Use case diagram of classroom scheduling system
27
2.7 Essential User Interface Prototyping
User Interface (UI) prototyping is an iterative development technique in which users are actively
involved in the mocking-up of the UI for a system. UI prototypes have several purposes:
 As an analysis artifact that enables you to explore the problem space with your
stakeholders.
 As a design artifact that enables you to explore the solution space of your system.
 A basis from which to explore the usability of your system.
 A potential foundation from which to continue developing the system
Login Details
Field Type Size Constrain Description

Username Varchar 12 Null User have to give his/her name
Password Varchar 10 Null User have to give the password
Table 7 login interface
Room Registration Details

Field Type Size Constrain Description
Buildingname Varchar 12 Null First Name
Roomname Varchar 10 Null Last Name
st
Description Varchar 12 Null 1 floor, 2nd floor…
Capacity/Max Number 10 Null 30,40,50…student
Student
Table 8 Room Registration interface
28
Figure 5 Essential User Interface Prototyping
2.8 Analysis Models

The System Analysis Model is made up of class diagrams, sequence or collaboration diagrams and
activity diagram. Between them they constitute a logical, implementation-free view of the
computer system that includes a detailed definition of every aspect of functionality. This model:
2.8.1 System Use Case Identification
The following are use cases used in the system:-

 Login
 Create account
 Search class schedule.
 View class schedule.
 Assign Instructor Information.
 Register :-
 Faculty Information.
 Department Information.
 Building Information.
 Room Information.
 Instructor Information.
 Student (year and section) Information.
 Assign course information.
 Delete course information.
29
 Create Class Schedule.

 Edit Schedule.
 Delete Schedule.
Actor Identification and Description
The following four actors are identified in classroom scheduling system:

1. Administrator: - Administrator is a person who is responsible for:-
 Register Faculty, Department, Building, Room, Course, Instructor, Student information
 Take a Backup of the system database.
 Create account for the system users and update the user information when it is required,
user management.
 Observe the overall activities that is done in the system by using History Log function
 post Announcement to system users
2. Scheduler: - Scheduler is the person who is register as Scheduler and having user name and
password his responsible for:
 preparing the schedule for each year and section and

 Make modification when required.
3. Department Heads:-
This user is Department Heads who have user name and password and they are responsible for:
 To submit the sleep (course for each department, each year for every semester, with
assign instructor and course information.
 Verification of the prepared schedule.
4. System User (anonymous user):-
This User is any users that want to access the system.

This user will not ask to enter user name and password.
The main function of this user is that:-
 Search the schedule.
 See frequently asked questions (FAQ) to get how to help.
30
 Send feedback to Administrator.
2.8.2 System Use Case Diagram
Use cases are used during requirements elicitation and analysis to represent the functionality
of the system. Use cases focus on the behavior of the system from external points of view. A
use case describes a function provided by the system that yields a visible result for an actor.
An actor describes any entity that interacts with the system.
Actor:-An actor is a human or machine entity that interacts with the system to perform meaningful
work.
31
Figure 6 System Use case diagram of classroom scheduling system
32
2.8.3 System Use Case Description
1. Login
Use case Name Login
Description
When user enters username and
password, it checks the input from
the database. If it is
Valid, it allows the user to access
and if not it returns to login form.
Extend Logout
Identifier UI-01
Actors involved administrator, Scheduler, User(Dep’t

head)
Precondition The user must be authorized user who

has valid user name and password
Basic course of action 1. The use case activated when the

user clicks on login link
2. The user enters username and
password
3. The authentication controller
validates the user information
4. The authentication controller sends
user information to the system
5. The system authorizes or verifies
the user whether authorized or not
6. The user enters into the main page
according to their privilege
7. The use case ends
33
Alternative course actions A3. If controller validate error and the

system display error.
A5. The use case continues to step 2
A6. If the user does not fill the correct
username and password then the system
display error message.
A7. The use case continues at step 2.
A8. Use case end.
Post condition User logged in to the system

Table 9 Login for System Use Case Description.
2. Create User Account
Use case Name Create User Account
Description
When the user fills the required information, it
checks the validity of the information. If user
information is valid it creates user account
Include Login
Identifier UI-02
Actors involved Administrator
Precondition The user must have privilege to create account
Basic course of action 1. The use case is start after the

administrator log in to the system
2. The use case activated when the user
clicks on create account link
3. The user enters the information
4. The authentication controller validates
the user’s information.
34
5. The authentication controller sends user

information to the database
6. The system displays successfully
created message.
7. Use case end.
Alternative course actions A4. If controller validate error and the system
display error.
A5. The use case continues to step 3.
A6. Use case end.
Post condition Administrator creates user account

Table 10 Create User Account
3. Register Building Information
Use case Name Register Building Information
Description When the user fills the required

information, it checks the validity of
the information. If enter information is
valid, it registers building information.
Include Login
Identifier UI-03
Precondition The user must have privilege to

register new building information.

Administrator log in to the system.
2. The use case activated when the
user clicks on entry link
3. The use case activated when the
user clicks on register building link
35

5. The authentication controller
validates the input
6. The authentication controller sends
user information to the database
registered message.
7. Use case end.
Alternative course actions A3. If controller validate error and it

displays error.
A7. Use case end.
Post condition Building information registered to the

database.
Table 11 Register building information
4. Update User
Use case Name Update User
Description When the user edits the required information,
it checks the validity of the information. If
user information is valid, it Update User
Include Login
Identifier UI-10
Actors involved Scheduler/User(Dep’t head)
Precondition The user must have privilege to Update User
Basic course of action 1. The use case is start after the scheduler
log in to the system.
36
clicks on update user link

4. The system validates the input
5. The system sends user information to
the database
updated message.
7. Use case end.
Alternative course actions A4. If controller validate error and it displays
error.
A7. Use case end.
Post condition The user will be updated

Table 12 Update user
5. Create Class Schedule

Use case Name Create Class Schedule
Description When the user creates the required
information, it checks the validity of the
information. If user information is valid, it
create class schedule.
Include Login
Identifier UI-5
Actors involved Scheduler
Precondition The user must have privilege to create class

schedule

scheduler log in to the system.
37
clicks on create class schedule link

the database
created message.
14. Use case end.
error.
A7. Use case end.
Post condition The schedule will be created

Table 13 Create Class Schedule
6. View Course
Use case Name View Course
Description The user should be able to view and filter the
schedule information detail using different
criteria.
Include Login
Identifier UI-6
Precondition The user must have privilege toView Course

scheduler/user (dep’t head) log in to the
system.
2.The use case activated when the user
clicks on View Course link
38
3.The user enters the information

4.The system validates the input
5.The system sends user information to
the database
message.
7. Use case end.
error.
A7. Use case end.
Post condition The course will be viewed.

Table 14 View course
7. Assign Building
Use case Name Assign Building
Description When the user assigns the required

assigns building.
Include Login
Identifier UI-7
Precondition The user must have privilege to assigns

building.
Basic course of action 1. The use case is start after the scheduler
log in to the system.
39
clicks on create schedule link

clicks on assigns building link
the database
message.
8. Use case end.
error.
A7. Use case end.
Post condition The building will be assigned.

Table 15 Assign building
8. Assign Room
Use case Name Assign Room

assigns room.
Include Login
Identifier UI-8
Precondition The user must have privilege toassigns Room.
40

clicks on create schedule link
clicks on assigns room link
the database
message.
8. Use case end.
error.
A9. Use case end.
Post condition The room will be assigned.

Table 16 Assigns room
9. Search Schedule
Use case Name Search Schedule
Description When the users search the required

search schedule.
Include Login
Identifier UI-9
41
Precondition The user must have privilege to search

schedule


clicks on search schedule link
the database
message.
7. Use case end.
error.
A9. Use case end.
Post condition The schedule will be searched.
Table 17 Search Schedule
10. Assign Course

Use case Name Assign Course

42

assigns course.
Include Login
Identifier UI-10
Actors involved User(Dep’t head)

course
Basic course of action 1. The use case is start after the user (Dep’t
head) log in to the system.
clicks on submit sleep link
clicks on assigns course link
the database
message.
8. Use case end.
error.
A12. Use case end.
Post condition The course will be assigned.

Table 18 Assign course
11. Assign Instructor
Use case Name Assign Instructor
43

assign instructor.
Include Login
Identifier UI-11

instructor
Basic course of action 1. The use case is start after the user (dep’t
head) log in to the system.
clicks on submit sleep link
clicks on assign instructor link
the database
message.
8. Use case end.
error.
A11. Use case end.
Post condition The instructor will be assigned.

Table 19 Assign instructor
44
12. View Feedback

Use case Name View Feedback
Description When the user views the required

views feedback.
Include Login
Identifier UI-12

course

administrator log in to the system.
clicks on views feedback link
the database
message.
7. Use case end.
error.
A10. Use case end.
Post condition The instructor will be assigned.

Table 20 View feedback
45
13. Print Schedule Report

Use case Name Print Schedule Report
Description When the user prints the schedule

prints schedule report.
Include Login
Identifier UI-13
Precondition The user must have privilege toprints

schedule report
Basic course of action 1. The use case is start after the User (Dep’t
head)log in to the system.
clicks on prints schedule link
the database
message.
7. Use case end.
error.
A10. Use case end.
Post condition The schedule will be printed.

Table 21 print schedule report
46
2.8.4 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. Bule Hora University Online
Classroom Scheduling System has the following sequence diagrams.
47
2.8.4.1. Sequence Diagram for Login
Figure 7 Sequence Diagram for Login
48
2.8.4.2. Sequence Diagram for Building Registration Information
Figure 8 Sequence Diagram for Building Registration Information
49
2.8.4.3. Sequence Diagram for Create User Account
Figure 9 Sequence Diagram for Create User Account
50
2.8.4.4. Sequence Diagram for Assign Instructor
Figure 10 Sequence Diagram for Assign Instructor
51
2.8.4.5. Sequence Diagram to Assign Room
Figure 11 Sequence Diagram for Assign Room
2.8.4.6. Sequence Diagram for Create Class Schedule
52
Figure 12 Sequence Diagram for Create Schedule
2.8.4.7. Sequence Diagram for Search Schedule
53
Figure 13 Sequence Diagram for Search Schedule
54
2.8.4.8 Sequence Diagram for View Course
Figure 14 Sequence Diagram for View Course
55
2.8.4.9 Sequence Diagram for Assign Course
Figure 15 Sequence Diagram for Assign Course
56
2.8.4.10 Sequence Diagram for Update User
57
Figure 16 Sequence Diagram for Update User
2.8.5 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.
58
2.8.5.1. Activity Diagram for login
Start
Browse Website
Click Login Link
Enter Username And Password

verify
invalid
valid
Display User Granted Page

End
Figure 17 Activity Diagram for Login
59
start
Browse website
initialize page
User Login
User Click On Create Button

valid
Enter Information Display Success Message
validate
invalid
End
Figure 18 Activity Diagram for Create User Account
60
Start
Browse Website
User Click On Building Link
User Enter Information
User click on register buttun

invalid
validate
valid
Display Success Message
End
Figure 19 Activity Diagram for Building Register Information
61
Start
Browse Website
User Click On Submit Sleep Button
User click on submit link

invalid
validate
valid
End
Figure 20 Activity Diagram for Assign Instructor
62
Start
Browse Website
User Clickon Create Schedule Button
Clickon Create Schedule Button
invalid
validate
valid
End
Figure 21 Activity Diagram for Create Schedule
63
Start
Browse Website
User Clickon Search Schedule
User Clickon Search Button
invalid
validate
valid

End
Figure 22 Activity Diagram for Searching Schedule
64
Start
Browse Website
User Clickon Create Schedule
Clickon Create Schedule Button
validate invalid
valid

End
Figure 23 Activity Diagram for Assign Room
65
Start
Browse Website
Clickon Submit Sleep
Clickon Submit Sleep Button
validate
invalid
valid

End
Figure 24 Activity Diagram for Assign Course
2.8.6 Collaboration Diagram

Collaboration diagram is the Unified Modeling Language diagram that describes the interactions
among objects in terms of sequenced messages. Collaboration diagrams represent a combination
of information taken from class, sequence, and use case diagrams describing both the static
66
structure and dynamic behavior of a system.A collaboration diagram is an interaction diagram

that emphasizes the structural organization of the objects that participate in an interaction. It
shows the same information as sequence diagram.
Figure 25 Collaborative diagram of login
67
Figure 26 Collaborative diagram of Building Registration
68
Figure 27 Collaborative diagram of create account
69
Figure 28 collaborative diagram of class schedule
70
Figure 29 collaborative diagram of Assign Course
2.8.7 Conceptual Class Diagram
We use class diagrams to describe the structure of the system. Classes are abstractions that
Specify the common structure and behavior of a set of objects. Objects are instances of classes that
are created, modified, and destroyed during the execution of the system. Objects have state that
includes the values of its attributes and its relationships with other objects. Class diagrams describe
the system in terms of objects, classes, attributes, operations and their associations.
71
Figure 30 Class diagram of the classroom scheduling System
72
CHAPTER 3
System Design
3.1 Purpose and Design Goals

The purpose of design is to determine how to build the system and to obtain information needed to
drive the actual implementation of the system. The focus is particularly on the solution domain
rather than on the problem domain. Object oriented design consists of transforming the analysis
model into the design model.
Design Goals
Some designed goals that we will achieve after the completion of this project:-
The system has an ability to detect invalid input by responding “wrong Input” message.
The system provides privileges to authorized user by giving account. In addition, the
system has a mechanism to prevent unauthorized users.
The system primarily designed to be used in many plat forms.
The system performs its functions well and thoroughly without waste of money and time.
Design goals inferred from non-functional requirements like:-

End user criteria
The system is compatible with every plat forms. Because, the software we used for Front
end is Dreamweaver. In addition to this, we get easily and the user has a chance to use and
learn more about this software.
Performance Criteria
Since the graphical user interface is very simple the users of this system may not face any
difficulty during their work and we implement some helping mechanisms to guide them during
their work.
73
Security Requirement
The system provides privileges to authorized user by giving account. The system has another
security keeping mechanism, which is called Session control mechanism.
Maintenance Criteria
 Modifiability
Our system is easily modifiable when there is need to upgrade the system functionality transactions
more than from the current state.
 Portability
Since the system is coded by using Dreamweaver it is portable from window plat form in to other
plat forms easily. I.e. the system primarily designed to be used in many plat forms.
 Readability
The source code of the system can be understood by any professional programmer.
3.2 Site Map

A site map is a visual or textually organized model of a Web site's content that allows the users to
navigate through the site to find the information they are looking for, just as a traditional
geographical map helps people find places they are looking for in the real world.
74
Figure 31 Site map
75
3.3 System Decomposition

The system decomposition is the process of breaking down entire system into simple manageable
tasks or subsystem. This can be accomplished hierarchically.
Figure 32 System Decomposition
76
3.4 Layering Class Diagram

A common architectural strategy, layering class model, is to layer the architecture of a system into
several layers. The various layers are represented by the rectangles and collaboration between
layers by the arrows.
77
Figure 33 Layering Class Diagram
78
3.5 Component Diagram

The Component Diagram helps to model the physical aspect of an Object-Oriented software
system. It illustrates the architectures of the software components and the dependencies between
them, those software components including run-time components, executable components also the
source code components.
Figure 34 component diagram
3.6 Deployment Diagram

The Deployment Diagram also helps to model the physical aspect of an Object-Oriented software
system. It models the run-time configuration in a static view and visualizes the distribution of
components in an application. In most cases, it involves modeling the hardware configurations
together with the software components that lived on.
79
Figure 35 Deployment diagram
3.7 Design Class Diagram

A class diagram shows a set of classes, interfaces, and collaborations and their relationships. We
use class diagrams to model the static design view of a system. Class diagrams are also the
Foundation for a couple of related diagrams: component diagrams and deployment diagrams.
80
Figure 36 Design Class diagram
81
3.7.1 Inheritance class diagram
Inheritance class diagram is class diagram that is inherited from design class diagram that have
common properties with each other. It is used to show the relation of two or more classes that have
common properties that are inherited from each other.
82
Figure 37 Inheritance class diagram
3.8 Persistence Modeling (For OOD)

Persistence modeling is the diagram that shows the relationship between the tables that
interrelated with each other. It is only used for object oriented database modeling; but for
83
relational database modeling we use Entity Relationship Modeling instead of Persistence to show
the relation of tables with each other.
Figure 38 Persistence Modeling (for OOD)
84
3.9 Access Control and Security
While entering data or in requesting the performance of certain functions error may occur which
could result in improper use of the system.
Access Controls provide ways to:-
 Insure that only the authorized user access the system.
 Validate the data for accuracy.
 Guarantee that transactions are acceptable.
 Determine that weather any necessary data have been omitted.
Actors Functionalities
Manage Info Register Feedback Gives Service
Admin Has authority to Register building, Send and view Manage user
create user room, dep’t. feedback account.
account.
Scheduler Has permission to Register schedule View feedback Create schedule.

login to his/her
account
User (Dep’t Has permission to --------------- View feedback Assign instructor

head) login to his/her and course.
Send feedback.
account and assign
instructor and
course.
Table 22 Access control and security
85
Chapter 4
Implementation
First phase of implementation is coding. Coding is the process whereby the physical design
specification created by the designers is turned in to working computer code by the programmer.
Modern language that used is Hypertext Preprocessor (PHP).The code is made simple in such a
way that another programmer can easily understand and work on that in future.
Sample code
Login Code
<?php include('index-nav.php');
//Start session
session_start();
Unset the variables stored in session
unset($_SESSION['id']);
?>
<?php include('header.php'); include('dbcon.php');?>
<body><div class="coat">
<div class="wrapper">
</br></br></br></br></br></br></br></br>
<div class="content"><h1 align="center"><imgsrc="img/kkk.gif" width="300"
height="226"></div
<div class="content"><h1 align="center"><font color="#000000" style="font-family:times
new roman"><i></i></h1><div id="form_wrapper" class="form_wrapper"><form
class="login active" method="POST" onSubmit="return check_info()">
<form class="Reset active" method="POST" onSubmit="return check_info()">
<h1 align='center'><embed src="http://www.satisfaction.com/cool-text-
maker/show.swf?baseURL=http://www.satisfaction.com/cool-text-
maker/&clickURL=http://www.satisfaction.com/cool-text-maker/&clickLABEL=Cool Text
Maker&flashLABEL=i&txt=Please Login
here!&backColor=6697728&textColor=13421772&backAlpha=100&textAlpha=100&effect1
=7&effect2=11&start1=1&start2=1" quality="high" bgcolor="#ffffff" width="320"
height="69" name="loader" align="middle" allowScriptAccess="sameDomain"
type="application/x-shockwave-flash"
pluginspage="http://www.macromedia.com/go/getflashplayer"
/></h1><div><label>UserName:</label><input type="text" name="UserName"
class="UserName_hover" id="span9001"/></div><div><label>Password:
</a></label><input type="Password"name="Password"class="Password_hover"
id="span9001"/></div><div class="bottom"><div class="remember"></div><button
class="btnbtn-primary" name="Login"><i class="icon-ok-sign icon-
large"></i> Login</button></input>
<button class="btnbtn-primary" name='reset'><input type='reset' value='Reset' />
86
<div class="clear"></div>
</input></div></form></table></br><div class="error">
<?phpif (isset($_POST['Login'])){
function clean($str) {
$str = @trim($str);
if (get_magic_quotes_gpc()) {
$str = stripslashes($str); }returnmysql_real_escape_string($str);
}$UserName=clean($_POST['UserName']);
$Password=clean($_POST['Password']);
$login_query1=mysql_query("select * from users where UserName='$UserName' and
Password='$Password' and User_Type='Admin'");
Password='$Password' and User_Type='Student'");
Password='$Password' and User_Type='Teacher'");
Password='$Password' and User_Type='Department Head'");
Password='$Password' and User_Type='Scheduler'");
$count1=mysql_num_rows($login_query1);
$row1=mysql_fetch_array($login_query1);
$row2=mysql_fetch_array($login_query2);$row3=mysql_fetch_array($login_query3);$row4
=mysql_fetch_array($login_query4);$row5=mysql_fetch_array($login_query5);$f=$row1['Fi
rstName'];$l=$row1['LastName'];$type=$row1['User_Type'];if ($count1 ==
1){$logout_query=mysql_query("select * from users where
User_id='".$row1['User_id']."'");$row=mysql_fetch_array($logout_query);$f=$row1['First
Name'];$l=$row1['LastName'];$type=$row1['User_Type'];mysql_query("INSERT INTO
history (data,action,date,user)VALUES('$f $l', 'Login', NOW(),'$type')")or
die(mysql_error())
87
USER INTERFACE PROTOTYPING
Homepage
88
Adminlogin page
89
Scheduler login page
90
User login page
91
Admin page
Scheduler page
92
User page
93
Reference:
1. http://creately.com/diagram/example/hhn6mvel/Subsystem+decomposition January 22, 2016
2. http://creately.com/blog/giagrams/uml-diagram-types-examples/ January 11, 2016
3. https://www.youtube.com/watch?v=FPB0Tw9jFE8 January 18, 2015
4. http://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-
blocks/system-design-and-development December 10, 2016
5. http://www.visual-paradigm.com/VPGallery/diagrams/Class.html December 28, 2016
6.
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&cad=rja&uact=8&sqi=
2&ved=0CDYQFjAG&url=https%3A%2F%2Ffanyv88.com%3A443%2Fhttp%2Fselab.hongik.ac.kr%2Fshow_data%2Feducati
December 21, 2016
7. https://en.wikipedia.org/wiki/Component_diagram December 21, 2016
8.https://www.google.com/webhp?client=aff-maxthon-
maxthon4&channel=t18&gws_rd=ssl#channel=t18&q=persistent+data+management January 9,
2016
9. (U.S. department of labor 2012-13)
10. E. Burke and W. Erben. Practice and Theory of Automated Timetabling, Third International
Conference, Germany, Springer Private Limited, August 2000
11. M. Marte. Models and Algorithms for School Timetabling, A Constraint-Programming

Approach, Ph.D dissertation, an der FakultätfürMathematik, Informatik und Statistik der Ludwig-
Maximilians-Universit ät München, July, 2002 .
94

Final

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final

Uploaded by

Copyright:

Available Formats

BULE HORA UNIVERSITY

FACULTY OF ENGINERING AND TECHNOLOGY

SUBMISSION DATE: 13/10/2009E.C

2.1 Introduction to Business Area Analysis .............................................................................. 13

3.6 Deployment Diagram ........................................................................................................... 79

1.2 Background of Study

1.3 Statement of Problem

1.4 Proposed System

 Develop more securing data.

1.5 Objectives of the Project

1.5.2 Specific Objectives

 To assign classroom online.

1.6 Significance of the Developed Project

 Remove Classroom optimization problem.

1.7 Beneficiary Group of the Project

1.8 Scope of the Project

Create User account.

1.9 Limitation of the Project

Analyzing Existing Document

1.11 System Development and Analysis Methodology

We will use object-oriented methodology because of the following reason:

1.11.2 System Analysis and Design Methodology

1.12 System Testing Methodology

1.13 System Development Tools

Item no Hardware Capacity Specification

Toshiba Core i3 PC To work the project virtually in

To transfer files from pc to

1.13.2 Software Development Tools:

Item no Software Specification

2 VISIO UML To draw diagram

3 WAMP Server To make the website dynamic.

4 Dreamweaver cs6 To write code in a simple.

Table 2 Software development tools

1.14 System Implementation Tools

1.15 Feasibility Study

1.15.1 Economic feasibility

1.15.2 Operational feasibility

1.15.3 Technical Feasibility

1.15.4 Organizational Feasibility

1.15.5 Ethical Feasibility

1.16 Activity Plan/Time Table

1 proposal 14/11/2016 23/11/2016 1.6w

2 Requirement gathering 24/11/2016 9/12/2016 2.4w

3 System anasis 1/12/2016 30/12/2016 4.4w

4 System design 2/1/2017 10/2/2017 6w

5 Implementation or code 13/2/2017 24/5/2017 14.6w

6 Test and recommendation 1/6/2017 31/7/2017 8.6w

Table 3 Time Table or Activity plan

1.17 . Cost Break Down Of the Project

1.17.1 Hardware development cost

No Material Amount Unit price(Birr) Total price

1.17.2 Software cost

No Material Price per unit

1 Microsoft office 2010 900

2 Visual paradigm 12.0 800

3 Rational Rose Enterprise Edition 700

Total 13100.00 Birr

2.1 Introduction to Business Area Analysis