GHION TECHNOLOGY COLLEGE

DEPARTMENT OF COMPUTER SCIENCES

PROJECT TITLE:- DISTANCE EDUCATION SYSTEM

Group name ID No
1. Abebaw Fetene ------------------------------ 001
2. Aderaw Menber -----------------------------
3. Alebel Andualem -----------------------------004
4. Alemu Getenet ---------------------------------
5. Asnake Gashaw --------------------------------0052

Submitted to:- Gezachew Melkamu(MSC)

January, 2022GC
Debere Markos, Ethiopia

i
 Acknowledgment
First of all, we would like to thank almighty God that permits us to do and enable us to be successful in
our final year project and to be complete without any problem as his permission. We also greatly thanks to
our advisor [Link] (MSc), who have given timely advice as well as encouragement to the
completion of our project and his continuous support in every phase of this project. Then we would like to
thanks Computer Science Department head and CDE officer who helps as by giving information about the
project. Finally, we would like to thank our classmates and friends.

i
 Abstract
Ghion College is one of the higher institutions involved in continuing and distance education. This project
is done in Ghion College continues and distance education. This document contains the brief description of
background information of the universities and project, method of data collection and analysis, description
of the existing system and modeling and design of the proposed system. This education system currently
has many problems,even if it is semi-automated system, because of the teaching and learning system works
manually. Due to thiswe are going to develop online system to support Teaching and learning processes
which means students can follow their education online through internet and get learning materials in the
system.

ii
Chapter one............................................................................................................................................................1
1. Introduction....................................................................................................................................................1
1.1. Background of the Project..........................................................................................................................1
1.2. Statement of theProblem.............................................................................................................................2
1.3. Objectives...................................................................................................................................................2
1.3.1. General Objective...............................................................................................................................2
1.3.2. SpecificObjectives..............................................................................................................................2
1.4. Scope of theproject.....................................................................................................................................2
1.5. Significance of theProject...........................................................................................................................3
1.6. Methodology of the Project........................................................................................................................3
1.6.1. Data GatheringMethod.......................................................................................................................4
1.6.2. DevelopmentTools.............................................................................................................................4
[Link]. SoftwareTools.................................................................................................................................4
[Link]. Hardware toolsused........................................................................................................................5
[Link]. Programming language...................................................................................................................5
1.7. FeasibilityStudy..........................................................................................................................................5
1.7.1. Economicfeasibility............................................................................................................................5
1.7.2. TangibleBenefits.................................................................................................................................6
1.7.3. IntangibleBenefit................................................................................................................................6
1.7.4. Technical feasibility...........................................................................................................................6
1.7.5. Operational feasibility........................................................................................................................6
1.7.6. Legalfeasibility...................................................................................................................................7
Chapter two...........................................................................................................................................................8
2. System analysis...............................................................................................................................................8
2.1. Overview of the existing system.....................................................................................................................8
2.1.1. ActorsintheExistingSystem.....................................................................................................................8
2.2. System requirementspecification................................................................................................................9
2.2.1. Functionalrequirement........................................................................................................................9
2.2.2. Non-functionalrequirement...............................................................................................................12
2.2.3. Businessrule......................................................................................................................................13
2.3. System requirement analysis....................................................................................................................13
iii
 2.3.1. Actor and Use case identifications..........................................................................................................13
[Link]. Use-case Diagram...............................................................................................................................16
[Link]. Use casedescription.........................................................................................................................18
2.3.3. Sequence diagram...................................................................................................................................36
2.3.4. Activity Diagram....................................................................................................................................46
2.3.5. Analysis Classdiagram...........................................................................................................................59
Chapter Three.......................................................................................................................................................65
3. System design.....................................................................................................................................................65
3.1. Design class diagram.....................................................................................................................................65
3.2. Physical data model.......................................................................................................................................67
3.3. State chart modeling Diagram.......................................................................................................................69
3.4. Collaboration diagram...................................................................................................................................79
3.5. Component diagram......................................................................................................................................88
3.6. Deployment Modeling...................................................................................................................................89
3.7. User interface................................................................................................................................................90

iv
Chapter one
 Introduction

Distance education is technology mediated learning either from distance or in physical classroom
setting (computer assisted learning). Distance education is a learning process created by interaction with
digitally delivered content, service andsupport.

Distance education is an umbrella term describing any type of learning that depends on or is enhanced
by electronic communication online using the latestICT.

Now days, technology brings unpredictable changes in our world. Computer science is one of the
major technologies implemented in our day to day life activities. Large companies and institutes have
used this technology to reduce their problems on their existing system and to increase accuracy,
productivity and reliability. GhionCollege isone of the governmental institutes that work in higher level
education. Therefore,it is necessary to use an automated record system (computerized system) to provide
reliableservice.

.1. Background of the Project

GhionCollege is one of the higher institutions involved in continuing and distance education. Continuing
and distance education mainly organizes activities for the society in the fields that have gained
importance on the improvement of individuals with a view of career building, improving professional
knowledge and skills, achieving new skills and supplying individual development needs. For this
purpose, centers have been established within this university through the principle of making continuing
and distance education accessible to everyone as a starting point for a lifelong learning process.
Each center which aims at providing continuing education, implement more flexible programs
compared to those executed in regular programs at higher education institutions. Owing to this fact,
continuing and distance education program of GhionCollege needsto be made accessible further for those
who cannot get regular education and be consolidated in such a way that quality education can take place.
In light of this, its provision has to be properly investigated and recommendations forwarded so that
v
timely measures can betaken that can assure qualityeducation.

GhionCollege distance education office handles its records manually. A manual record requires a number
of employees and takes a lot of time to give the needed service efficiently. Consequently, it kills time,
energy and economy. These manual system problems have initiated us to develop this new automated
system, or convert the manual system to computerized system.

This project will enable user to access data easier and faster. All information is stored in organized
manner to make searching and retrieving of data faster.

.2. Statement of the Problem

Ghion College of continuing and distance Education system currently has many problems because of
the teaching and learning system works manually. As we have analyzed the existing system has the
following problems:-It takes high cost to duplicate learning material,totake tutorial, give tutorial and
viewing grade reports consume time and cost, Overburden work for the University during providing the
service to the students like distributing materials, assignment in a manual way, Students don’t have the
opportunity to get update information on time i.e. since the system is manual based the information that
were distributed for students may be modified, deleted, or changed. Example, exam date and receiving
materials were make confusion.

.3. Objectives
.3.1. General Objective

The main objective of this project is to develop online distance education management system for
Ghion College
.3.2. SpecificObjectives

To achieve the general objective, the proposed system accomplishes

 mnimize work complexity of the existing system
 minimize cost of copying or duplicating materials
 reduce wastage of time to submit assignments
 enable new applicants online applying

1.4. Scope of the project

The scope of our project is limited to Ghion College s University Campus of continuing and distance
education.
vi
 The following scopes are including in the project

 Uploadmodules.

 Downloadmodule.

 Uploadtutorial.

 Downloadtutorial.

 Uploadassignment.

 Downloadassignment.

 View courses present from department.

 View resultonline.

 Post announcement andinformation.

 Add, update and search studentinformation.

 Online examination, students take exam in way that the organization prepares exam center room but
the exam takes place online because all studentmaynot havecomputer.

 Prepare classschedule.

The following activities will not include in the automated system.

 Online payment.

 Studentregistration.

1.5. Significance of theProject

This system has the following benefits:

 Access student detail information throughinternet.
 Reduce resourcewastage.
 Support to distributeinformation.
 Easy to search and manages the studentinformation.
 Reduce employees workload.
 The proper files of employeesaccesseasily.

vii
 1.6. Methodology of the Project
In the system will use the iterative method for the development of the project because of its suitability to
develop a good and efficient system since it makes as backward and forward for solving error.

Figure 1: iterative model

1.6.1. Data GatheringMethod

There are different data gathering technique which helps us to understand the present systems general
activities and its procedures. We used three methodologies to gather the needed information. The
methods we use for data collection are:

 Interviewing: As a method for the collection of data about the activities of University of
continuing and distance education we use interviewing method to understand peoples who
belongs to the current system also we raised questions that helps us to develop the
newsystem.
 Direct Observation: We observe the current system and identify the problems regarding to
the working process .so it helps us as easy way to understand the system and to develop the
project. By observing their system structure, we design a project to solve theproblems.
 Document Analysis: we analyze some documents and forms found in the office to get

viii
 information about the currentsystem.
1.6.2. DevelopmentTools
[Link]. SoftwareTools

The software requirements are the instructional components used to develop a system. Software
requirement to develop system are as follows: -

 WAMP Server: manage servers setting. The reason of selecting WAMP server is they are
secure means they are not easily attack by virus when we compare to otherservers.
 Edraw max: used to draw different UML those are necessary to structure thesystem.

 Text editor: Notepad++, used to edit programming language php, html andcss.

 Operating System: Window 10, this operating system has new features that are not found in
window 7, for instance networkadapter.
 Browser:internet explorer or Firefox, baidu browser, chrome, used to searchinformation.

[Link]. Hardware toolsused

 PC: to perform our task like writing documentation andcodes.

 Flash disk: to store file temporarily and used to file transfer computer tocomputer.

 CD: to make back up files or storefiles.

 Mobile camera: to capture image that we need to theproject.

[Link]. Programming language
The programming language is: -

 PHP: used open source general-purpose scripting language that is especially suited for web
development. It is simple and robust programminglanguage.
 JS: to add interactivity to web page and the validation of thesystem.

 HTML: to manage the content of thesystem.

 CSS: is used to style the systempresentation.

 MYSQL: is used to store data in the system, open source and easy todevelop.

1.7. FeasibilityStudy

Feasibility study is the process of determination of whether or not a project is worth doing. There are many

ix
 types of feasibility study thoseare: -
1.7.1. Economicfeasibility

The system which we are going to develop will have economic benefit. Those economic benefits may
be tangible or intangible
1.7.2. TangibleBenefits

This is the concrete benefit that can be expressed in terms of birr. So, the system proposed to develop
will decrease a lot of birr that was expensive to buy and distribute hard copy document material. Also
reduce the loss of data that means if it reduces the loss of data it also reduces the cost of replacing the lost
data. For example,ifthe University has 2,000 students to handle these amount data there must be many
people to manage the data and a lot of paper. But after the system developed the data can be managed with
one person and in one computer in very shorttime.

 Easy filemanagement.
 Reduce cost for manual datamanagement.
 Easy update and retrieve on storedrecords.
1.7.3. IntangibleBenefit

Intangible benefits are those benefits that cannot be expressed in terms of birr. Intangible benefit that
the system will give is thefollowing:

 Properly ordered files of employees which have stability means it is not easilylost.
 Good service to theoffice.
 Little job burden to employee’soffice.
 Small response time and manyservices.
 Knowledge gain by projectdeveloper.
1.7.4. Technical feasibility

Technical feasibility determines whether the work for the project can be done with the existing
equipment, software technology and available users. Technical feasibility is concerned with specifying
equipment and software that will satisfy the user requirement.

This project is feasible on technical because the proposed system can run on any computer with internet
access so it would be technically feasible.
1.7.5. Operational feasibility
x
 Operational feasibility is a measure of how well the solution will work in the organization. Operational
feasibility is dependent up on the human resources available for the system. This online system for
distance education in Ghion College will attain its desired objectives. It can solve the problems in
distributing module and tutorials; therefore, it will minimize the amount of effort to do all through
manually.
1.7.6. Legalfeasibility

The system is legal feasible due to the following tasks: -

 The system will not have any conflict with the rule and regulation of Campus policy. The system
is legally acceptable since it respects Campus rule andregulation.

 Student and teacher have their own account to see their result and any one cannotviewand update
their result that not hasprivilege.

 Perform tasks effectively andefficiently.

xi
Chapter two

2. System analysis
2.1. Overview of the existing system

As we have observed in the data collecting phase, the main problems in Ghion College
continuing and distance education is wastage of resources during preparing, duplicating
and process of distributing modules.

In the system all task performs through face to face interaction between student, instructor and
administrator as follow: -distributing modules, giving tutorials and showing course results,
student came or physically appear to the university in the day that announced to get the
university. Collage schedule class, Student and teacher meet at classroom for the purpose of
teaching-learning process. Instructor prepare exam question and student take exam finally
teacher evaluate student result and submit grade to registered.

Overburden of work on the university’s employee is also seen, since each course has its own
module to be distributed per student. Students also view result of the course such as quizzes,
tests by going back to their instructor. Such process leads students to waste their time, effort,
money and make them unsatisfied.

Generally, those problems can be defined as:

 Wastage of campusresources

 Time consuming because of some tasks operatedmanually

 Work overload on campus employees

 Less of students’satisfaction.
2.1.1. ActorsintheExistingSystem
Participants of existing system represent external and internal entities that interact with the system.

xii
1. DepartmentHead

 Responsibleforprepareclassschedule.

 Responsible for post notice.

2. Instructor

 Responsible forteach.

 Responsibleforprepareexamquestionanddistributeforstudent.

 Responsibleforgive, receive and show results of assignment and exam.

 ResponsibleforsubmitstudentgradetoCDE.
3. Student

 ResponsibleforcollectmodulesandcoursematerialsfromtheirCDE officer.

 Responsible for attendingclass.

 Responsiblefordoandsubmitassignmentfortheirinstructor.

 Responsible for takeexam.

4. CDEofficer

 Responsible for postnotice.

 Responsible for addadvertisement.

 Responsibleforgivemodulestotheirstudent.

2.2. System requirementspecification

A System Requirements Specification also known as a Software Requirements Specification .it

is a document or set of documentation that describes the features and behavior of a system or
software application. A Requirement is any function, constraint, or property that the systemmust
provide, meet, or satisfy in order to fulfill its purpose. So, we need to identify and understands
the problem of the existing system to develop the new system. We decide the following
functional and non-functional requirements of thesystem.
2.2.1. Functionalrequirement

xiii
 A functional requirement defines the capabilities of a system that must be able to perform
successfully. It is a statement of exactly what the system must do. The new system being the
following functional requirements: -

 Manage resources: - The system should enable to upload and downloadcoursematerials.

 Manage notice: - The system should enable to post and view notice.

 Manage assessment: - The system should enable to view and add result,upload,
activate, deactivate, give, submit, evaluate assignment, exam and quiz.

 Manage account: -The system should enable to create, update, activate, deactivate by user
account.

 Manage schedule: -The system should enable to postandview and schedule.

 Manage student: -The system should enable to view student’s status.

The following table shows functional requirement of the proposed system.

Table 1: FREQ manage resource

Requirement id FREQ-1
Source CDE officer, student and instructor
Requirement The system shall allow CDE officer, student and instructortomanage
resource
Description CDE officer, student, instructor manage resource in the system
Category manage resource
Priority High
Table 2: FREQ login

Requirement id FREQ-2
Source Department head, instructor, student, center admin, system administrator
and CDE officer
Requirement The system shall allow users to login
Description User login to the system to perform their task
Category Login

Priority High

xiv
Table 3: FREQ manage user account

Requirement id FREQ-3
Source System Admin
Requirement The system shall allow System Admin to manage user account
Description System Admin manage account in the system
Category
Manage users account (create, update, activate, deactivate and change
password).
Priority High
Table 4: FREQ manage schedule

Requirement id FREQ-4
Source Users
Requirement The system shall allow users to manage schedule
Description users manage schedule in the system
Category
Manage schedule (prepare, and view).
Priority High
Table 5: FREQ manage assessment

Requirement id FREQ-5
Source Students and instructors
Requirement The system shall allow Students and instructors to manage assessment
Description Students and instructors manage assessment in the system
Category
Manage assessment (upload,take, activate, deactivate, download, evaluate and
submit).
Priority High
Table 6: FREQ manage student status

Requirement id FREQ-6
Source Center admin
Requirement The system shall allow Center admin to manage students status
Description Center admin manage studentsin the system

xv
 Category
Manage students( view).
Priority High
Table 7: FREQ Add student result

Requirement id FREQ-7
Source Instructor
Requirement The system shall allow instructor addresult
Description instructor add student result to thesystem
Category Add result
Priority High
Table 8: FREQ Manage notice

Requirement id FREQ-8
Source All user
Requirement The system shall allow managenotice
Description All user manage notice (view, post) inthesystem
Category Manage notice
Priority High
Table 9: FREQ logout

Requirement id FREQ-9
Source Department head, instructor, student, center admin, system administrator
and CDE officer
Requirement The system shall allow all user to logout
Description All user leaves the system after finish his/her task
Category Logout
Priority High

2.2.2. Non-functionalrequirement

Non-functional requirements define how a system is supposed to be. Non-functional

requirements specify the system’s quality characteristics or quality attributes. These
requirements are additional features.

xvi
 The following are the non-functional requirement related with the system:
 Usability: - Since the service in the system doesn’t require special training and use
style sheet to add interactive user interface so that it is easy to learn and use.
 Availability: – Since the system reaches service through internet it is available in
everywhere.
 Performance: -Since we use php programing language to develop the system so
php is a powerful scripting language.
 Security: – The system will be secured as much as possible so that there is permissible
information flow. So, it is designed to be very secure by authenticates the user by
encrypt, decrypt user name and password.
 Portability: -The system is machine independent and software system independent soit
can be moved to different targetplatforms.
2.2.3. Businessrule
A business rule defines or constraints one aspect of the business that is intended to assert
business structure or influence the behavior of the business.
BR1: The teachers only upload assignment and exam only for his assigned course.
BR2: Every applicant must provide his/her educational report to register.
BR3: The students must have grade 12 exam result greater than 140 for registration.
BR4: Every student should pay his/her educational fee.
BR5: The students must attend class, do and submit assignment on time.
BR6: Any students who involve in the DMU university campus distance and continuing education should
have a unique ID.
BR7: instructors give course material for his assigned course.
BR8: instructors give exam, evaluate exam, give and receive all assessment, submit grade to register on
time.
BR9: department head and CDE officer must add notice on time.
BR10: CDE officer must distributemodule on time.

2.3. Systemrequirement analysis

System requirement analysis is an integral part of information systems design and is critical to
the success of interactive systems. It is now widely understood that successful systems and
products begin with an understanding of the needs and requirements of the users.
xvii
 [Link] and Use case identifications
Actor: An actor represents a type of users of the system or external system that plays a role in
one or more interactions with our system. An actor can be human, external and internal system.

Use case: Use case is interactions between actor and a system, to achieve a goal. Derive from the
scenarios that completely represent the future system. This is primarily done in the form of a
scenario that describes a sequence of steps. A use case is drawn as a horizontal ellipse on a UML
use casediagram. The use case diagram shows the overall activities of these system users. The
diagram consistssystemboundaries.
Table 10: Actor identification

No Name of actor Description

1 Instructor Login, upload and download (assignment, exam, and tutorial), add student
result, view schedule and notice, logout

2 Student Login, download (assignment, tutorial and module), view (schedule,

location, advertisement, course result and notice), submit assignment, and
take exam, logout.

3 System admin Login, (create, update, activate, deactivate) account, logout.

xviii
4 Department head Login, prepare schedule and module, (view, post) notice, logout.

5 CDE officer Login, post (notice, advertisement), distribute module, logout.

6 Center admin Login, view (schedule, notice), logout.

xix
Use case identification

 Viewadvertisement  Downloadvideotutorial

 View location  Uploadvideotutorial

 View notice  addschedule

 Login  Updateaccount

 Viewresult  Activate useraccount

 Post notice  Deactivate useraccount

 Upload module  Activateexam

 Download module  Deactivateexam

 Uploadexam  Add studentresult

 Createaccount  Takeexam

 Upload assessment  Viewschedule

 Download assessment  logout

 View student status

 Add advertisement

[Link]. Use-case Diagram

are Identifying the activities that mainly performed on the proposed system is the basic thing in
modeling a new system. Use case diagrams graphically describe system behavior (use cases).
These diagrams present a high-level view of how the system is used as viewed from an outsider’s
(actor’s) perspective. From the identified use cases and actor, the use case diagram of the system
is shown below.

A use case diagram contains four components.

Boundary: -which defines the system of interest in relation to the world around it.
Actors: -usually individuals involved with the system defined according to their roles.
Use cases: -which the specific roles played by the actors within and around thesystem.
20
 Relationships: - between the actors and the Usecases.

Figure 2: Use case Diagram

21
 [Link]. Use casedescription
Use case description describes in detail about the use case and actors in the use case diagram,
it includes the name of use case, description about the use case, the name of the actor who act on
the use case, what precondition before the actor acts on the use case, post condition after the
actor acts on the use case, basic course of action which describes the interaction between the
actor and the system when the actor acts on the use case, and finally alternative course of action.

The following table shows use case description of the system.

Table 11: Use case description of login

Use case number UC 01

Use case name Login

Actor Department heads, center administrators, instructors,

students, CDE officer and system Administrator
Description Checking the intended user is authorized or not

Precondition The user must have username and password

Post condition The users successfully login.

Basic course of action User action System response

[Link] user opens the system

2. The system displays the login
3. The user enters user page.
name and password
4. The system checks the
then click login button
username andpassword.
6. End use case. 5. The system opens the userpage.

Alternative course of action If the username and password is invalid, the system displays an
error message, then go back to step 3 of basic course of action.

22
Table 12: Use case description of logout

Use case number UC 02

Use case name Logout

Actor Department head, center administrators,instructor, students,

CDE officer and system Administrator
Description After doing any private activity in the system the user logout
from the system.
Precondition The user should be in private page.

Post condition The user is in public page.

Basic course of action User action System response

1. The user clicks the

2. The system displays the login
logout button.
page.
3. End use case.
Alternative course of action If connection is failing, try again.

Table 13: Use case description of download module

Use case number UC 03

Use case name Download module

Actor Student

Description Downloading module

Precondition The student must be login and the module must be uploaded
before
Post condition The student successfully downloading module

Basic course of action User action System response

1. The student clicks

2. The displays the module
module link.
option.
3. The student select and
click “download” link. 4. The system downloads

23
 5. End use case. module

Alternative course of action If there is no module uploaded before, the system display
“there is no module in the system” message.
Table 14: Use case description of view notice

Use case number UC 04

Use case name View notice

Actor All user

Description The users look all the information added by the Department
head and CDE officer in the system.
Precondition The notice must be posted before

Post condition The user observes the notices.

Basic course of action User action System response

[Link] user opens the

2. The system displays the home
system
page.
3 The user clicks on
view notice link. 4. The system displays available
5. the user views the notice that is posted by the
posted notice Department head and CDE officer.

6. End usecase.

Alternative course of action If connection is failed before open the notice, the system displays
connection fail. Then turn back to step 3 basic course of action.

Table 15: Use case description of take exam

Use case number UC 05

Use case name Take exam

Actor student

Description The students take exam added by the instructors

24
 Precondition The user must be login in the system

Post condition The user evaluates the exam.

Basic course of action User action System response

[Link] user opens the

2. The system displays the student
system
page.
3 The user clicks on
take exam link. 4. The system displays available
5. The user views the exam if the exam uploaded by
exam. instructor active.

56. Endusecase.

Alternative course of action If connection is failed before open the exam link, the system
displays connection fail. Then turn back to step 3 basic course of
action.
Table 16: Use case description of view advertisement

Use case number UC 06

Use case name View advertisement

Actor student

Description The users look all the information added by CDE officer in the
system.
Precondition The advertisement must be posted before

Post condition The user observes the advertisement.

Basic course of action User action System response

[Link] user opens the

2. The system displays the home
system
page.
3 The user clicks on
view advertisement 4. The system displays available
link. advertisement.
[Link] user view the posted
25
 advertisement

6. 6. End usecase.

Alternative course of action If connection is failed before open the advertisement, the system
displays connection fail. Then turn back to step 3 basic course of
action.
Table 17: Use case description of view student

Use case number UC 07

Use case name View student

Actor Center administrator

Description The users look all the information added in the system.
Precondition The student must be come to the center.

Post condition The user observes the student.

Basic course of action User action System response

[Link] center admin

2. The system displays the center
opens the system
admin page.
3 The user clicks on
view student link. 4. The system displays student.
65. thecenter admin view
student.

7. 6. End usecase.

Alternative course of action If connection fails,try again.

Table 18: Use case description of view location

Use case number UC 08

Use case name View location

Actor All user

26
 Description The users look all the information added by the Department head
and CDE officer in the system.
Precondition The location must be posted before

Post condition The user observes the location.

Basic course of action User action System response

[Link] user opens the

2. The system displays the home
system
page.
3 The user clicks on
view location link 4. The system displays available
5. the user view the location
posted location

66. End usecase.

Alternative course of action If connection is failed before open the notice, the system displays
connection fail. Then turn back to step 3 basic course of action.

Table 19: Use case description of view Result

Use case number UC 09

Use case name View result

Actor Students.

Description The user looks result added by the instructor in the system.

Precondition The user must have user name and password and the result
must be added before.
Post condition The user access and know the result.

Basic course of action User action System response

1. The user login to the

2. The system displays the
system.
student page.
3. The user click on
view result links. 4. The system displays
27
 5. The user view
available result that is
result.
added by the instructor.
6. End usecase.

Alternative course of action If result is not added, the system displays the message “there
is no result available”.
Table 20: Use case description of Add notice

Use case number UC 11

Use case name Add notice

Actor Department head and CDE officer

Description Posting of notice in the system

Precondition Department head and CDE officer must be login to the system

Post condition The notice successfully posts in the system.

Basic course of action User action System response

1. The user clicks post

2. The system displays notice
notice link.
post area.
3. The user attaches notice
and click add notice button. 4. The system posts notice
5. End use case.
Alternative course of action IF connection fails, try again.

Table 21: Use case description of Add advertisement

Use case number UC 12

Use case name Add advertisement

Actor CDE officer

Description Add advertisement in the system

Precondition CDE officer must be login to the system

Post condition The advertisement successfully posts in the system.

28
 Basic course of action User action System response

1. The user clicks post

2. The system displays
advertisement link.
advertisement post form.
3. The user attaches
advertisement and click 4. The system posts
add advertisement button. advertisement
5. End use case.
Alternative course of action IF connection fail, try again.

Table 22: Use case description of create account

Use case number UC 13

Use case name Create account
Actor System Administrator
Description The system administrator creates user account to students,
instructors, CDE officer and department head to give
authorization.
Precondition Users registered to the system
Post condition Users account Created.
User Action System Response
Basic course of action 1. The system Administrator 2. The system display system
login to the system administrator home page.
[Link] system administrator
4. The system display creates
click on create account link
account form.
5. System Administrator Fill
7. The system displays create
createsaccountform.
successful message.
6. click on createbutton
8. End of use case.

29
 Alternativecourse action If the system administrator fills incorrect information, the system
displays error message, and go back to step 5 of basic course of

Table 23: Use case description of deactivate user account

Use case number UC 14

Use case name Deactivate user account

Actor System administrator

Description The system administrator block accounts of the dept head,

students, center admin,CDE officer and instructors if there is
any inconvenience.
Precondition The administrator must login to the system.

Post condition Protect user account from unauthorized access

User action System response

Basic course of action

1. The system admin clicks 2. The system displays activated
deactivateaccountlink account.
3. The system admin 4. The system deactivates user
select account and clicks account.
on deactivate button.
5. End use case.
Alternative course of If the search result is empty or if the user enters incorrect
action keyword in the search box the systems lets the user to try again
and back to step 4 in basic course of action.

30
Table 24: Use case description of activate user account

Use case number UC 15

Use case name Activate user account

Actor System administrator

Description The system administrator unblocks or activate user accounts of

the department head, students, center admin, CDE officer and
instructors
Precondition The administrator must login to the system and the account of
user deactivate before.
Post condition Successfully activate user account

User action System response

[Link] system admin clicks

Basic course of action [Link] system displays deactivated
deactivate account link
account
3. The system adminselect
deactivate user account 4. The system activates user
and click activatebutton account
5. End use case.

Alternative course of action If connection fails, try again.

31
Table 25: Use case description of activate exam

Use case number UC 16

Use case name Activate exam

Actor Instructors

Description The instructors activate exam of the students,

Precondition The instructors must login to the system
Post condition Successfully activate exam

User action System response

[Link] instructors clicks

Basic course of action [Link] system displays activated exam
manage exam link
button
[Link] activated exam
button [Link] system displays uploaded exam
5. The instructors select
6. The system activates exam
activate exam and click
activatebutton
7. End use case.

Alternative course of action If connection fails, try again.

32
Table 26:Use case description of upload exam

Use case number UC 16

Use case name Upload exam

Table
Actor Instructors
27: Use
Description The instructors upload exam of the students case
Precondition The instructors must login to the system
Post condition Successfully upload exam

User action System response

[Link] instructors clicks

Basic course of action [Link] system displays upload exam
manage exam link
button
[Link] upload exam button
5. The instructors fill and [Link] system displays forms of exam
click activate form and
6. The system upload exam
click upload button
7. End use case.

Alternative course of action If the data not insert, return A 3 and try again.

description of deactivate exam

Use case number UC 17

Use case name Deactivate exam

33
 Actor Instructors

Description The instructors deactivate exam of the students

Precondition The instructors must login to the system
Post condition Successfully deactivate exam

User action System response

[Link] instructors clicks

Basic course of action [Link] system displays activated exam
manage exam link
button
3. click activated exam
button 4. The system displayexam
5. The instructors select
[Link] system deactivate
exam and click deactivate
exam
button
7. End use case.

Alternative course of action If connection fails, try again.

Table 28: Use case description of Add student result

Use case number UC 18

Use case name Add student result

Actor Instructor

Description Add course result of the student in the system

Precondition The instructor must have user name and password

Post condition The instructor successfully adds course result of the student
in the system
Basic course of action User action System response

[Link] instructor login to the

2. The system displays the
system
instructor home page.
3. The instructor clicks add
result link. 4. The system displays the
5. The instructor fills the result form.

34
 course information and fills 6. The system add result to
each student result, then student
Click “add” button.
7. End use case.
Alternative course of action If user misses some information, system generates error
message and back to step 5 to try again.
Table 29: Use case description of upload module

Use case number UC 19

Use case name upload module

Actor CDE officer

Description uploading module for the student

Precondition The CDE officer must have user name and password.

Post condition The CDE officer successfully uploading module.

Basic course of action User action System response

[Link] CDE officer login to

2. The system displays the
the system
CDE officer home page.
3. The user clicks module
Upload link. 4. The system displays the
form.
5. The user fills the
6. The system uploads
information of learning
modules and other learning
Material and click materials
“upload” button.
7. End use case.

Alternative course of action If user miss some information about module, the system
displays error messages and back to step 5 to try again
Table 30: Use case description of upload assessment

Use case number UC 20

35
 Use case name upload assessment

Actor Instructor and student

Description Uploadingassessment.

Precondition The instructor and student must have user name and password.

Post condition The instructor and student successfully uploading assessment.

Basic course of action User action System response

[Link] instructor and student

2. The system displays the
r login to the system
user home page.
3. The user clicks assessment
Upload link. 4. The system displays the
form.
5. The user fills the
6. The system uploads
information and click
assessment
“upload” button.

7. End use case.

Alternative course of action If user miss some information about assessment, the
system displays error messages and back to step 5 to try
again
Table 31: Use case description of download assessment

Use case number UC 21

Use case name download assessment

Actor Instructor and student

Description Downloading assessment.

Precondition The Instructor and student must have user name and password.

Post condition The Instructor and student successfully downloading

assessment.
Basic course of action User action System response

36
 [Link] user login to the
2. The system displays the
system
user home page.
3. The user clicks assessment
Download link. 4. The system displays the
form.
5. The user fills the
6. The system download
information and click
assessment
“download” button.

7. End use case.

Alternative course of action If user miss some information about assessment, the
system displays error messages and back to step 5 to try
again
Table 32:use case description of download module

Use case number UC 22

Use case name download module

Actor Student

Description Downloading module.

Precondition The student must have user name and password.

Post condition The student successfully downloading module.

Basic course of action User action System response

[Link] user login to the

2. The system displays the
system
user home page.
3. The user clicks module
Download link. 4. The system displays the
form.
5. The user fills the
6. The system download
information and click
module
“download” button.

37
 7. End use case.

Alternative course of action If user miss some information about module, the system
displays error messages and back to step 5 to try again
Table 33: Use case description of upload video tutorial

Use case number UC 23

Use case name upload tutorial

Actor Instructor

Description Uploading tutorial.

Precondition The instructor must have user name and password.

Post condition The instructor successfully uploading tutorial.

Basic course of action User action System response

[Link] instructor login to the

2. The system displays the
system
user home page.
3. The user clicks tutorial
Upload link. 4. The system displays the
form.
5. The user fills the
6. The system uploads
information and click
tutorial
“upload” button.

7. End use case.

Alternative course of action If user miss some information about tutorial, the system
displays error messages and back to step 5 to try again
Table 34: Use case description of download video tutorial

Use case number UC 24

Use case name download tutorial

Actor student

Description Downloading tutorial.

38
 Precondition The student r must have user name and password.

Post condition The student successfully downloading tutorial.

Basic course of action User action System response

[Link] student login to the

2. The system displays the
system
user home page.
3. The user clicks tutorial
Download link. 4. The system displays the
form.
5. The user fills the
6. The system downloads
information and click
tutorial
“download” button.

7. End use case.

Alternative course of action If user miss some information about tutorial, the system
displays error messages and back to step 5 to try again
Table 35: Use case description of update account

Use case number UC25

Use case name Update account

Actor System admin

Description The system updates account.

Precondition The System admin must have user name and password.

Post condition The System admin successfully update account.

Basic course of action User action System response

[Link] System admin login

2. The system displays the
to the system
System admin page.
3. The System admin clicks
tutorial 4. The system displays the
Update link. form.
6. The system updates
5. The user fills the
39
 account.
information and click
“update” button.

7. End use case.

Alternative course of action If user misses some information about account, the
system displays error messages and back to step 5 to try
again.
Table 36: Use case description of Add schedule

Use case number UC 26

Use case name Add schedule

Actor Department head

Description Department head add schedule in the system

Precondition Department head must be login to the system

Post condition The schedule successfully posts in the system.

Basic course of action User action System response

1. The Department
2. The system displays
head login to the
Department head page.
system
3. The Department head 4. The system displays form.
click add schedule button.
.6. The system add schedule
5. The Department head fill
successfully.
form and click add button.
7. End use case.
Alternative course of action IF connection fail, try again.

2.3.3. Sequence diagram

A sequence diagram is an interaction diagram that shows how objects operate with one another and
in what order. It is a construct of a message sequence chart.

40
A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and
classes involved in the scenario and the sequence of messages exchanged between the objects
needed to carry out the functionality of the scenario. Sequence diagrams are typically associated
with use case realizations in the Logical View of the system under development. Sequence
diagrams are sometimes called event diagrams.

A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that
live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order
in which they occur. This allows the specification of simple runtime scenarios in a graphical
manner. The following figure shows the sequence diagram.

Figure 3: Sequence diagram for View schedule

41
Figure 4:Sequence diagram for View result

Figure 5: sequence diagram for login

42
Figure 6:Sequence diagram for View notice

Figure 7:Sequence diagram Upload tutorial

43
Figure 8:Sequence diagram for Upload module

Figure 9:Sequence diagram for Upload assessment

44
Figure 10:Sequence diagram for Update account

Figure 11:Sequence diagram for Logout

45
Figure 12:Sequence diagram for Download tutorial

Figure 13:Sequence diagram for Download module

46
Figure 14:Sequence diagram for Download assessment

Figure 15:Sequence diagram for Deactivate account

47
Figure 16: Sequence diagram for Deactivated exam

Figure 17:Sequence diagram for Create account

48
Figure 18: Sequence diagram for Add advertisement

Figure 19:Sequence diagram for Active account

49
Figure 20:Sequence diagram for Active exam

Figure 21: Sequence diagram for Add notice

50
Figure 22:Sequence diagram for Upload exam
2.3.4. Activity Diagram
UML Activity diagrams are used to document the logic of a single operation or method, a
single use case (may be the basic course of action or the alternate course of action) or the flow of
a logic of a business process. They are the object oriented equivalent of flow charts and data flow
diagrams in the structured development approach.

Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency. In the Unified Modeling Language, activity
diagrams are intended to model both computational and organizational processes (i.e.
workflows). Activity diagrams show the overall flow of control.

Activity diagrams are constructed from a limited number of shapes, connected with arrows. The
most important shape types:

 rounded rectangles representactions;

 diamonds representdecisions;

 bars represent the start (split) or end (join) of concurrentactivities;

 circle represents the start (initial node) of theworkflow;

51
  An encircled circle represents the end (finalnode).

The following figure shows activity diagram of each activity in the system.

Figure 23:Activity Diagram for Login

Figure 24:Activity Diagram for deactivate account

52
Figure 25:Activity Diagram for create account

Figure 26: Activity Diagram for Upload module

53
Figure 27:Activity Diagram for view result

Figure 28:Activity Diagram for Account update

54
Figure 29:Activity Diagram for Activate exam

Figure 30:Activity Diagram for Add advertisement

55
Figure 31:Activity Diagram for Add result

Figure 32:Activity Diagram for deactivate exam

56
Figure 33:Activity Diagram for download assessment

Figure 34:Activity Diagram for Download tutorial

57
Figure 35:Activity Diagram for Post schedule

Figure 36:Activity Diagram for View advertisement

58
Figure 37:Activity Diagram for Take exam

Figure 38: Activity Diagram for View location

59
Figure 39:Activity Diagram for View schedule

Figure 40:Activity Diagram for Logout

60
Figure 41:Activity Diagram for Upload exam

Figure 42:Activity Diagram for Upload tutorial

61
Figure 43:Activity Diagram for Upload assessment

Figure 44:Activity Diagram for View notice

62
Figure 45:Activity Diagram for Add notice

Figure 46:Activity Diagram for Download module

63
Figure 47:Activity Diagram for Activate account

2.3.5. Analysis Classdiagram

A class diagram describes the structure of a system by showing the system's classes, their
attributes, operations (or methods) and the relationships among objects Class diagrams can also
be used for data modeling. Class itself represented as a box with name, attributes, andmethods.

Class diagram used for describe the static view of thesystem, show the collaboration among the
elements of the staticview, describing the functionalities performed by thesystem and construction of
software applications using object-orientedlanguages.

Class diagram has three components.

 The top component contains class.

 The middle components contain the attributes.

 The bottom component contains the operations the class canexecute.

64
The following table shows class name, attribute and operation.
Table 37: Class analysis

Object Attribute Data type and length

CDE officer Officer_id Varchar (50)
First_name Varchar (50)
Last_name Varchar (50)
Sex Varchar (10)
Age Int
Birth _date Varchar (50)
Phone_number Int
Email Varchar (50)
Object Attribute Data type and length
Instructor Instructor_id Varchar (50)
First_name Varchar (50)
Last_name Varchar (50)
Sex Varchar (10)
Age Int
Birth_ date Varchar (50)
Phone_number Int
Email Varchar (50)
Education_level Varchar (50)
Object Attribute Data type and length
System admin Administrator_id Varchar (50)
First_name Varchar (50)
Last_name Varchar (50)
Sex Varchar (10)
Age Int
Birth_date Varchar (50)
Phone_number Int
Email Varchar (50)

Object Attribute Data type and length

Student Student_id Varchar (50)

65
 First_name Varchar (50)
Last_name Varchar (50)
Sex Varchar (10)
Age Int
Birth_date Varchar (50)
Phone_number Int
Email Varchar (50)

Object Attribute Data type and length

Center admin Center administrator_id Varchar (50)
First_name Varchar (50)
Last_name Varchar (50)
Sex Varchar (10)
Age Int
Birth_date Varchar (50)
Phone_number Int
Email Varchar (50)

Object Attribute Data type and length

Department head Department_id Varchar (50)
First_name Varchar (50)
Last_name Varchar (50)
Sex Varchar (10)
Age Int
Birth_date Varchar (50)
Phone_number Int
Email Varchar (50)

object Attribute Data type and length

module Module_id Varchar (50)
Module_name Varchar (50)
Course_name Varchar (50)
Department_name Varchar (15)
Semester Int
66
 File Text
object Attribute Data type and length
notice Notice_id
Title Varchar (50)
Body Varchar (50)
Message Varchar (50)
Date Date

object Attribute Data type and length

schedule Schedule_id Varchar (50)
Section_name Varchar (50)
Year Varchar (50)
Semester Int
Course_name Varchar (50)
Instructor_name Varchar (50)
Date Date

object Attribute Data type and length

account User_id Varchar (50)
User_name Varchar (50)
Password Varchar (50)
Role Varchar (50)
Status Varchar (50)
Instructor_name Varchar (50)
Date Date

object Attribute Data type and length

result Student_id Varchar (50)
Department_name Varchar (50)
Course_id Varchar (50)
Year Varchar (50)
Semester Int
Value Int
object Attribute Data type and length
67
exam Exam_id Varchar (50)
Instructor_id Varchar (50)
Center admin_id Varchar (50)
Course_name Varchar (50)
Time allow Int
Value Int
Date Date

assignment Assignment_id Varchar (50)

Instructor_id Varchar (50)
Course_name Varchar (50)
given_date Date
Value Int
submission_date Date
File Text

advertisement advertisement_id Varchar (50)

Title Varchar (50)
Message Text
Address Varchar (50)
Phone_no Int
Date Date

68
Figure 48: Analysis class diagram

69
Chapter Three
3. System design
Systems design is the process of defining elements of a system like modules, architecture, components and
their interfaces and data for a system based on the specified requirements. It is the process of defining,
developing and designing systems which satisfies the specific needs and requirements of a business or
organization.

3.1. Design class diagram

The class diagram represents the static view of an application. Class diagram is not only used for
visualizing, describing and documenting different aspects of a system but also for constructing executable
code of the software application. The class diagram describes the attributes and operations of a class and
also the constraints imposed on the system. The class diagram shows a collection of classes, interfaces,
associations, collaborations and constraints. A class diagram in the Unified Modeling Language (UML) is a
type of static structure diagram that describes the structure of a system by showing the system's classes,
their attributes, operations (or methods), and the relationships among objects.

70
Figure 49: design class diagram

71
Table 38: user class description

Attribute name Data type Description

User_id Varchar (20) Represent the User identifier number that identify user
uniquely
First_name Varchar (20) Represent the User first name
Last_name Varchar (20) Represent the User last name
Sex Varchar (10) Represent the User gender or sex
Phone_number Int Represent the User phone number
Email Varchar (20) Represent the user email address
age Int Represent the user age
Table 39: assessment class description

Attribute name Data type Description

assessment _id Varchar (20) Represent the assessment identifier number that identify
user uniquely
Course_name Varchar (20) Represent the course name
Submit_date Date Represent the assessment submit date
Value Int Represent the value of assignment
given_date Date Represent the given_date assessment
file Varchar (200) Represent the file of assessment
Table 40: account class description

Attribute name Data type Description

User_id Varchar (20) Represent the User identifier number that identify user
uniquely
User_ name Varchar (20) Represent the User username
Password Varchar (20) Represent the User password
Role Varchar (10) Represent the User role in the system
Status Varchar (20) Represent the User status which is allowed or not

3.2. Physical data model

Physical data model represents how the model built in the database. A physical database model shows all
table structures, including column name, column data type, column constraints, primary key, foreign key,
and relationships between tables. Features of a physical data model include: Entities become tables in the
72
physical database. Attributes become columns in the physical database. Select an appropriate data type for
each of the columns and size. Unique identifiers become columns that are not allowed to have NULL
values. Specification all tables and columns. Foreign keys are used to identify relationships between tables.

73
Figure 50: physical data model

3.3. State chart modeling Diagram

State chart diagram shows the object undergoing a process. It describes the flow of control from one state
to another state. States are defined as a condition in which an object exists and it changes when some event
is triggered. So, the most important purpose of State chart diagram is to model life time of an object from
74
creation to termination. The following figure shows the state of the objects that corresponding use cases.
Some of them are: -

Figure 51:State chart Diagram for create account

Figure 52: State chart Diagram for activate account

75
Figure 53:State chart Diagram for upload tutorial

Figure 54:State chart Diagram for upload module

76
Figure 55:State chart Diagram for upload exam

Figure 56:State chart Diagram for upload assessment

77
Figure 57:State chart Diagram for update exam

Figure 58:State chart Diagram for post notice

78
Figure 59:State chart Diagram for logout

Figure 60:State chart Diagram for login

79
Figure 61:State chart Diagram for download tutorial

Figure 62:State chart Diagram for download module

80
Figure 63:State chart Diagram for assessment

Figure 64:State chart Diagram for deactivate exam

81
Figure 65:State chart Diagram for deactivate account

Figure 66:State chart Diagram for add notice

82
Figure 67:State chart Diagram for add advertisement

Figure 68:State chart Diagram for activate exam

83
 3.4. Collaboration diagram
Collaboration diagram is the same as sequence diagram, but more focused on showing the collaboration
(communication) of objects rather than the time sequence. The collaboration diagram is an interaction
diagram emphasized the structural organization of the object that participate in an interaction collaboration
mode is the object and link that are meaningful within an interaction and also used to show the
implementation of an operation. It consists of a collection of objects that work together to perform a task.
The collaboration diagrams the message flow between object in the following manner.

Figure 69:Collaboration Diagram for view result

Figure 70:Collaboration Diagram for view notice

84
Figure 71:Collaboration Diagram for upload tutorial

Figure 72:Collaboration Diagram for upload module

85
 Figure 73:Collaboration Diagram for
upload exam

Figure 74:Collaboration Diagram for upload assessment

86
Figure 75:Collaboration Diagram for update account

Figure 76:Collaboration Diagram for logout

87
Figure 77:Collaboration Diagram for login

Figure 78:Collaboration Diagram for download tutorial

88
Figure 79:Collaboration Diagram for download module

Figure 80:Collaboration Diagram for download assessment

89
Figure 81:Collaboration Diagram for deactivate exam

Figure 82:Collaboration Diagram for deactivate account

90
Figure 83:Collaboration Diagram for create account

Figure 84: Collaboration Diagram for add notice

91
Figure 85:Collaboration Diagram for view result

Figure 86:Collaboration Diagram for activate exam

92
Figure 87:Collaboration Diagram for activate account

3.5. Component diagram

Component is a physical and replaceable part of the system that confirms to and provides the realization of
a set of interfaces. Component model shows the structural relationship between the component of the
system. It also provide physical view of the system and it focus on a set of compnents and the structural
relationship among them. Its purpose is to show the dependencies thats the software has on other
software component.

93
Figure 88: component diagram

3.6. Deployment Modeling

These diagrams are used to visualize the topology of the physical components of the online distance
education system where the software components are deployed. So deployment diagram are used to
describe the static deployment view of the system. Deployment diagram consist of nodes and their
relationships.
The purpose of deployment diagrams can be described as: −

 Visualize the hardware topology of a system.

 Describe the hardware components used to deploy software components.
 Describe the runtime processing nodes.

94
Figure 89: Deployment diagram

3.7. User interface

User interface design or user interface engineering is the design of computers, appliances, machines, mobile
communication devices, software applications, and websites with the focus on the user's experience and
interaction. The goal of user interface design is to make the user's interaction simple and efficient as
possible, in terms of accomplishing user goals what is often called user-centered design. Good user
interface design facilitates finishing the task at hand without drawing unnecessary attention to it.

95
Figure 90: Login page interface for CDE management system

96
Figure 91: Admin page interface for CDE management system.

97
Figure 92: User interface for Home page

98
 APPENDIX
Deployment diagram: - diagrams are special diagrams used to focus on software components and hardware
components
Action: -An action is the fundamental unit of behavior specification and represents some transformation or
processing in the modeled system, such as invoking a method of a class or a sub activity.
Activity: -diagram: a diagram that describes procedural logic, business process and work flow supporting
parallelism.
Activity: - carrying out behavior in a State machine diagram.
Actor: -a role that a user takes when invoking a use case. Also see actor modeling.
Class: -the primary declarative construct of Object-Oriented Programming; a cohesive unit of Attributes
and Operations; a compile-time template for an Object
Class diagram: -a type of static structure diagram that describes the structure of a system by showing the
system's classes, their attributes, and the relationships between the classes. Diagram-a visual representation
of a subset of features of a UML Mode
Sequence diagram: -describes the Messages sent between a number of participating Objects in a Scenario.

99
 Reference
1. [Link] UML-diagram.
2. [Link] Login Form with HTML & CSS - Login form
Design with Source Code - Html Login Page Design.
3. How to develop class diagrams what constraint it
includes[Link]
520fd83b300b.
4. How to develop class diagrams what constraint it
includes[Link]
520fd83b300b.
5. How to differentiate analysis class diagram and design class diagram
[Link]
6. [Link]
7. [Link] php.
8. [Link]

100