Wolaita Sodo University

School of Informatics
Department of Information technology
Project on Title: - Web based school management system Chora
School in Wolaita Sodo.
Group member ID No.
 Barnabas Beyene……………………IT/WE/068/11
 BantayehuAlange….………………..IT/WE/067/11
 AshenafiAbota………………………IT/WE/056/11
 BinayasBirhanu……………………..IT/WE/070/11
 Abele Tizazu………………………...IT/WE/009/11
 AsesbeAdisu…………………………IT/WE/052/11

Advisor: Mesele G

A Senior Project (Documentation)

Submitted to Department of information technology, school of informatics, Woliata Sodo
University, in Partial fulfillment for the requirement of the Degree of Bachelor Science in
information technology.

WSU, ETHIOPIA

FEB,2023

1
 Wolaita Sodo University
School of Informatics
Department of Information technology
Full name of the students
1. Barnabas Beyene
2. BantayehuAlange
3. AshenafiAbota
4. BinayasBirhanu
5. Abele Tizazu
6. AsesbeAdisu
This is to certify that the final year industrial project prepared by name of Barnabas Beyene,
Bantayehu Alange ,Ashenafi Abota , Binayas Birhanu, Abele Tizazu, Asesbe Adisu
titled:Web based school management system for Chora school Wolaita sodo and submitted in
partial fulfillment of the requirements for the Bachelor of Science Degree in information
technology complies with the regulations of the University and meets the accepted
standards with respect to originality and quality.

Signed by the Examining Committee:

Name Signature Date

Advisor: _____________________ ___________ _________

Examiner: _____________________ ___________ __________

Examiner: _____________________ ___________ __________

2
Table of Contents Page
Acronyms ..................................................................................................................................................... 4
CHAPTER ONE ......................................................................................................................................... 3
1. INTRODUCTION............................................................................................................................... 3
1.1 Background of Organization............................................................................................................ 3
1.2 Statement of the problem ................................................................................................................. 3
1.3 Objective ................................................................................................................................................ 3
1.3.1 General Objective ...................................................................................................................... 3
1.3.2 Specific Objective ....................................................................................................................... 3
1.4 Scope and Limitation of the Project ................................................................................................ 4
1.4.2 Limitation ................................................................................................................................... 4
1.5. Methodology for the project............................................................................................................ 4
1.5.1. Data collection method ............................................................................................................. 4
1.5.2. System Analysis and Design Methodology .............................................................................. 5
1.5.3. Requirements structuring and Data modeling tools .............................................................. 5
1.6 Feasibility analyses............................................................................................................................ 5
1.6.1. Technical Feasibility ................................................................................................................. 5
1.6.2. Operational Feasibility ............................................................................................................. 6
1.6.3. Economic Feasibility ................................................................................................................. 6
1.6.4 Schedule Feasibility.................................................................................................................... 6
1.8 Time table and word breakdown structures .................................................................................. 7
1.8.1 Time Schedule Breakdown............................................................................................................ 7
1.8.2 Team Composition ......................................................................................................................... 8
1.9 Development Tool and Technologies (Development Environment) ............................................. 9
1.10 Cost ................................................................................................................................................. 10
Total .................................................................................................................................................... 10
CHAPTER TWO ...................................................................................................................................... 11
2. OVERVIEW OF EXISTING SYSTEM ............................................................................................. 11
2.1 Description of the Existing System .......................................................................................... 11
2.2 Users of Existing System........................................................................................................... 12
2.3 Major Functions of the Existing System ................................................................................. 12
2.4 Practice to be preserved from the Existing System................................................................ 13
2.5 Business Rules of the Existing System..................................................................................... 14
2.6 Proposed Solution on New System .......................................................................................... 14
2.7 Drawbacks of the Existing System .......................................................................................... 14
CHAPTER THREE .................................................................................................................................. 15
SYSTEM ANALYSIS ............................................................................................................................... 15
3.1 Overview of the Proposed System ........................................................................................... 15
3.2 Proposed Solution to the New System ..................................................................................... 15
3.3 . Requirement Analysis ............................................................................................................ 16
3.3.1 Functional Requirements .................................................................................................... 16
3.3.2 Non Functional Requirement .............................................................................................. 16
3.4 Requirement Analysis ............................................................................................................... 17
3.5 Actors and Use Case Identification ......................................................................................... 17
3.5.1 System Use Case Diagram .................................................................................................. 17
3.5.2 Actor Specification ............................................................................................................. 17
3.5.3 Use case Identification ........................................................................................................ 18
3.5.4 Use Case Diagram of the Project ........................................................................................ 18
3.5.5 Use Case Description .......................................................................................................... 20
3.6 Class Diagram ........................................................................................................................... 27
3.7 Sequence diagram ..................................................................................................................... 29
3.8 Activity Diagram ....................................................................................................................... 34
CHAPTER FOUR..................................................................................................................................... 39
SYSTEM DESIGN .................................................................................................................................... 39
4.1 Design Goal ................................................................................................................................ 39
4.2 System Architecture.................................................................................................................. 39
4.3 Sub System Decomposition ...................................................................................................... 41
4.4 Access control and Security ..................................................................................................... 42
4.5 Collaboration Diagram ............................................................................................................. 42
4.6 Persistence Data Diagram ........................................................................................................ 45
4.7 Component Diagrams ............................................................................................................... 46
4.8 Deployment Diagram ................................................................................................................ 47
Reference ................................................................................................................................................... 49

Acronyms
OOSD. ------------------------Object Oriented System Development methodology.
OOA --------------------------Object Oriented Analysis.

4
OOD -------------------------Object Oriented Design.
UML-------------------------------Unified modeling language.

5
List of Tables
Table 1.1 Time Schedule .................................. ERROR! BOOKMARK NOT DEFINED.
Table 1.2 Team Composition............................ ERROR! BOOKMARK NOT DEFINED.
Table 1.3 Software Used ................................... ERROR! BOOKMARK NOT DEFINED.
Table 1.4 Hardware Used ................................. ERROR! BOOKMARK NOT DEFINED.
Table 1.5 Cost Estimation ................................. ERROR! BOOKMARK NOT DEFINED.
Table 1. 6 Total Students Of Chora School ......................................................................... 11
Table 3. 1use Case Description For Login........................................................................... 20
Table 3. 2 Use Case Description For Create Account ........................................................ 21
Table 3. 3 Use Case Description For Delete Account ........................................................ 21
Table 3. 4 Use Case Description For Insert Assessment .................................................... 22
Table 3. 5 Use Case Description For Insert Attendance ...................................................... 22
Table 3. 6 Use Case Description For Generate Report ....................................................... 23
Table 3. 7 Use Case Description For Add Comment.......................................................... 24
Table 3. 8 Use Case Description For View Comment ........................................................ 25
Table 3. 9 Use Case Description For Prepare Transcript.................................................... 25
Table 3. 10 Use Case Description For View Assessment .................................................. 26
Table 3. 11 Use Case Description For View Attendance ................................................. 26

i
List of Figures
Figure 3. 1 System Use Case Diagram ............................................................................... 19
Figure 3. 2 Class Diagram ................................................................................................... 28
Figure 3. 3 Login Sequence Diagram ................................................................................. 30
Figure 3. 5 Insert Assessment Sequence Diagram .............................................................. 31
Figure 3. 7 Insert Attendance Sequence Diagram .............................................................. 32
Figure 3. 11 Sequence Diagram For Prepare Report Card ................................................ 33
Figure 3. 2 Create Account Activity Diagram .................................................................... 35
Figure 3. 3 Activity Diagram For Login ............................................................................. 35
Figure 3.4 Activity Diagram For View Comment .............................................................. 36
Figure 3. 5 Activity Diagram For View Attendance........................................................... 38
Figure 4. 1 Architecture Diagram ....................................................................................... 41
Figure 4. 2 Sub System Decomposition .............................................................................. 41
Figure 4. 3 Collaboration Diagram For Login. ................................................................... 43
Figure 4. 4 Collaboration Diagram For Registration Users. ............................................... 44
Figure 4. 5 Collaboration Diagram For Insert Assessment................................................. 44
Figure 4.6 Persistence Diagram .......................................................................................... 45
Figure 4. 7 Component Diagram ........................................................................................ 47
Figure 4.8 Deployment Diagram ........................................................................................ 48

ii
 CHAPTER ONE
1. INTRODUCTION
1.1 Background of Organization
Web based school management system for wolaita sodo Chora School is a system in which
schools, from elementary to high school, can enter every detail and status of their students and
information about parents of the students is managed. The school administrator can assign
teacher for every subject and teachers can submit grades of their students. Parents can see status
of their students and can generate report about their children. Education plays an important role
in development of any country. Many of the schools try to increase education quality. One of the
aspects of this improvement is managing their students’ records and enable parents of the
students to check their children’s status. So, to make parents can follow their children’s status,
teachers to submit grades, and school administrator assign teachers for each subject, to ensure
quality of education, the chora school should implement school management system.

1.2 Statement of the problem

Chora school is burdened by cumbersome paper work and manual processes, and they find it
difficult to maintain records of their students and track the information they need. Parents also
don’t have access to follow status of their children from where ever they are using an online
system. By now, the education bureau has no way of gathering statistical data from each school
using a centralized database. Using web-based school management System automates academic
processes to save time and reduce staff overload as well as enable parents to check status of their
children.

1.3 Objective
1.3.1 General Objective
The main objective of this project to develop web-based school management system for Chora
school.
1.3.2 Specific Objective
The specific objectives of this project will include the following:

 Understanding and identifying the existing system problems

 Gathering requirement specifications
 Analyzing the system requirement.

3
  Designing the proposed system and subsystems according to the requirement
analysis.
 Implementing the system based on design.
 To deploy and testing the system

1.4 Scope and Limitation of the Project

1.4.1 Scope
The system will be developed in this project is school management system for wolaita sodo
chora school. This project undergoes a detailed study and requirement gathering on the problem
from wolaita sodo chora school. After the problem is studied in detail and all the required
information is gathered, design and implementation of a web-based school repository system for
wolaita sodo chora school will be done. The main focus of the project is keeping the information
of the students and parents. In addition to this the website will provide service like generating
report, parents can see status of their children, teachers can submit results of their student, school
administrator can assign teacher for each subject.

1.4.2 Limitation
The system will be limited to the web-based platform and does not include an instant mobile
application, and the system does not support local languages by now.

1.5. Methodology for the project

1.5.1. Data collection method
To get a precise data from customers the team has used the following fact-finding techniques.
There are two types of data collection these are secondary and primary data collections from
them we will used the

1.5.1.1. Primary data collection.

A) Discussion: -It will be done with other person who will use the system.
B) Interview: - to get the basic information and background information about the existing
management system, the team is going to interview staffs in education bureau and some
students and student parents about the services, which is given to them, and the problems
associated with that environment.
C) Observation: - direct observation is simple and we project team members physically
observe information that cannot maintain from the interview or others and also it is
important if they are unable to communicate with others because of the difficulties they

4
 have to the language.

1.5.1.2. Secondary data collections

a. Document Analysis: - Is used to gain some insight as to how the need for a system arises
to identify the part of the commission associated with the problem.
b. Reference books: -related written materials that support to the project and organizations
manual.
1.5.2. System Analysis and Design Methodology
In this project, the team used Object Oriented System Development methodology
(OOSD).
i) Object Oriented Analysis (OOA): During this phase the team used to Model the
functions of the system (use case modeling), Find and identify Organize the objects
and identify the relationship between them and finally model the behavior of the
objects.
ii) Object Oriented Design (OOD): during this phase, the team used to refine the use
case model to reflect the implementation environment, Model object interactions and
behaviors that support the use case scenario, and finally update object model to reflect
the implementation environment.
1.5.3. Requirements structuring and Data modeling tools
Since the team is being using an Object-Oriented System Development methodology,
for structuring requirements and for modeling the data the team used a Unified
modeling language (UML). The team used UML- diagrams for requirements
structuring as well as data modeling.

1.6 Feasibility analyses

The feasibility study is the preliminary study that determines whether a proposed system project
is financially, technically and operationally viable. The alternative analysis usually include as
part of the feasibility study, identifies viable alternatives for the system design and development.
1.6.1. Technical Feasibility

In this technical feasibility, we consider that our new system can be implemented with current
technology and also the customer can easily experience to use that technology.

5
1.6.2. Operational Feasibility
The new system can provide sufficient service for the parents and school. The system is
operationally feasible as it very easy for the end users to operate it. The system must correct
match with the operation performed in existing system. The users (teacher, record office, student,
parent and admin) can operate the system with little training. So we can say that it is
operationally feasible.

1.6.3. Economic Feasibility

This feasibility checks whether the system can be developed with the available funds. Economic
feasibility identifies that whether the new developing system is economically feasible or not. The
proposed system must feasible with the available fund.

1.6.4 Schedule Feasibility

Schedule Feasibility is the time frames in which works needs to be performed within a given
time.

Schedule feasibility concerned with analyzing the expected completion date of the project and
the constraints that may bring change to this date. It is very important to note that the testing
process can be done through the lifetime of the project to handle the errors.

1.7 Significance of the project

Significance of this project is listed below:
 It will help system users especially Chora schools to know the importance of using school
data record management tools to minimize the time and cost when it used.
 It will narrow the gap of communication between Parents and school. When the project
completed and implemented, parents will retrieve their children reports in easy manner.
 Since users will use the system across the internet, all information recorded can be submitted
and report generated from online. Therefore, there will be less paper consumption and less
human power to calculate students result.
 The development team will learn some new web development technologies and will develop
skills of working in a group
 The costs for management process will be reduced.
 It will enable parents to have access about status of their children
 Avoiding data loss because of improper data storage

6
 1.8 Time table and word breakdown structures
1.8.1 Time Schedule Breakdown
The project schedule is the tool that communicates what work needs to be performed, which
tasks need to be worked on and the time frame in which that task needs to be performed. The
project schedule should reflect all of the work associated with delivering the project on time.
Here is the schedule using a Gantt chart.

Activities Time
January January February 5, February 18, March May
10,2023- 15,2023 2023- 2023- 2,2023 – 17,2023-
January -February 3, February February 28, May May
14,2023 2023 17, 2023 2023 16,2023 25,2023

project Proposal
Requirement
Specification
System Analysis
System Design
Implementation
Testing

7
 1.8.2 Team Composition

The following are the types of tasks and as well as the responsibility each of us can have.
Task Breakdown: -
Project Web based school management system for Chora wolaita Sodo.
title
No Student’s name Id no. Phone Role & Responsibility

1. Barnabas Beyene IT/WE/068/11 +251922992769 Project manager

2. Bantayehu Alange IT/WE/067/11 +251938669860 -

3. Ashenafi Abota IT/WE/056/11 +251916198487

4 Abel Tizazu IT/WE/009/11 +251923474417 -

5. Asebe Adisu IT/WE/052/11 +251964044228 -

6 Binayas Birhanu IT/WE/070/11 +251949026999 -

8
 1.9 Development Tool and Technologies (Development Environment)
We will use different types of software and hardware tools to build the website.

1.9.1 Software used

Item no Software Uses
1 Operating System To process all the work
(Window)
2 PHP, JAVASCRIPT programming language
3 WAMPP server To provide response for user, to provide
MySQL for creating and manipulating databases
4 Microsoft To write document
Word Office 2021
5 Web browser To run the system or test the code
6 E-drawmax, UML Drawing UML diagrams.

7 Notepad++, Sublime To write the code

Text
8 HTML, PHP, Java Client side and server-side implementation
Script, CSS

9
1.9.2 Hardware requirements
Item no Hardware Capacity Uses

1 Flash Disk 32 GB To store data

2 Stationeries (pen, paper) writing all necessary documentations

3 Printer 4 For printing documentation

4 Desktop or Personal Computer 929 GB To do all activities

1.10 Cost
The following Table shows the estimated cost for our project.
No Material Amount Price per unit Total price
1 A4 size paper 2 Dozen 250Birr 500Birr
2 Pen 10 20Birr 200Birr
3 Flash disk 2 (16GB each) 400Birr 800Birr
4. For Print 100 sheets 1 Birr 100Birr
5 Desktop computer 1 (4RAM) free Free
Total 1600.00 birr

10
 CHAPTER TWO
2. OVERVIEW OF EXISTING SYSTEM
2.1 Description of the Existing System
In the existing system, the parents are informed about the students all activity in the school two
times in a year in the report day. The academic calendar has two semesters where in each
semester the school prepares one report card at the end of the first semester and another report
card at the end of the second semester. The report cards in both semesters contain the same basic
information including the score of the student in each subject, attendance showing absence and
presence, comments of the teachers that may include the students’ general conduct, misbehavior,
competence, class activity, and achievements to be encouraged.
In the beginning of academic calendar students and teachers or other employee are must
manually registered by record officers before class or other tasks begin to prepare the students
transcript, to fill attendance of student and to perform other tasks related with students. When the
students want to transfer another school or graduated in that school the record officer must
prepare transcript for students. The teachers transfer their students mark assessment out of 60%,
final out 40% and total out 100%. In the first semester the report information is reported by the
teachers to parents by sending for their children’s by adding assessments of the students and
his/her comment and the parents can see and give comment and send back to teachers.
In the second semester the report cards are reported to the parents on parent-teacher day which is
prepared one times in a year and the parents are required to come to the school compound.
 chora school has the following student information
Table 1. 6 total students of chora school

No Gender No of student
1 Male 880

2 Female 750

3 Total 1630

11
 2.2 Users of Existing System
Users represent external entities that interact with the system they manage and perform the
system functionally. Due to this we will deal only with persons involved on those services or
persons who have responsible for this work. The major users or players and their responsibilities
in the existing system are the following: -
 Parent: -is someone who has a clear responsibility about their children. They can be a
father or mother of the students and they can take the responsibility of their children.
Teacher: - a person who teaches and evaluates his/her students and can process student
mark or data and anything that are related to student.
 Student: - Are the major family of the school who are learning in the school by their
teacher.
 Record officers: - Are a person who keeps record of students and prepare transcript
when students want. To prepare the transcript, they check rosters of each and every of the
student.
 Homeroom teacher: - He/ She have a responsibility of managing their class students.
Director: - a person he/she generate time table and assign home room teachers for each
and every class and post news for schools when appear.
2.3 Major Functions of the Existing System
In the existing system major functions are done manually by the employers. Major functions of
the existing system are the following: -
 Registration: - the record officer registers students and staff members when in each
academic year begins and the record officers want to update the student’s information
they search manually and update using papers and pens.
 Fill attendance and Assessment: - the home room teacher fills daily attendance or
absence or presentence of the students and their assessments and also their status to
parents.
 Transferring marks of students: - subject teachers generate result card of their student and
they send for home room teachers of the students mark as assessment with 60%, final with
40% and total with out of 100%.
 Preparation of report card: - To give the report card for student in the semester the home
room teacher fills student mark that come from each teacher for first and second semester

12
 then makes average mark, conduct and rank of a student for First and second semester and
give comment based on the student academic status.
 Transcript preparation: -Transcripts are generated by the record officer. A student may
request transcript when he/she wants to transfer to other school or when he/she has
completed/graduated from the school and needs to join higher education or for some other
purpose.
 Assign the teachers for each class: - the director is a person he/she manages and assigns the
teachers to each and every class when the academic year is just begin and it generate time
table for all class.
 Generate Time table: - the director and also generate time table for each and every class
when the academic calendar begins.
 The school prepare meeting at the end of the academic year.
 The teachers take student’s attendance with a paper.
 The home room teacher give report cared to the student at the end of the academic year and
recorded officer prepare report card manually.

2.4 Practice to be preserved from the Existing System

This project will come up with a solution that can minimize the problems of the system in the
organization and enable the system to be effective and be efficient for the users. But some
information laid a foundation to develop the proposed system.
 Major Functions of the Existing System that are conducted currently are also preserved
like:
 Registration of Students
 Managing the students
 Fill attendance and assessment
 Preparations of report card
 Generate time table
 Transferring mark of students
 Transcript preparation
 Assign the home teachers for each class

13
 2.5 Business Rules of the Existing System
Business rules explain the organization policies and rules that govern their day-today Activities.
Br1: All users must have legal personal information to use the system.
Br2: The parent to be a member he/she must have their own children in that school.
BR3: The student’s registration can be applied by legible record officer.
BR4: The student’s attendance must be taken in each class.
BR5: If parent want to contact the school affairs they can share their ideas to them.
BR6: All students must attend in any assessment time later to view his result.
2.6 Proposed Solution on New System
The new system addresses the problems of the existing system by supporting the parent follow
up student system with web-based technology by providing well organized, flexible and effective
means of communication. This includes:-
 Changing the manual system in to web-based system without affecting the structure
of the organization.
 Developing easily accessible information/documents that is clear to users when
accessing data at any time.
 Avoiding wastage of time during searching of student information.
 To avoid redundancy of records in the working system as the proposed system
provides mechanisms to sort files in database system.
 Control unauthorized access by providing authentication and authorization.
2.7 Drawbacks of the Existing System
Reliability: Students data may not capture in time and in accurately so it would contain errors
and it is difficult to get correct information from different individuals.
Performance (Response Time): During the information accessing time, the system response
time takes long period because of the manual system.
Security: Since the existing system is manual it is not secure that there is no authentication
mechanism for checking the information that is collected from the individual.
Service: In the existing system information is transferred orally by any individuals because
parent and school communication is very poor. Redundancy of information is the major problem
for the school.

14
 CHAPTER THREE
SYSTEM ANALYSIS
3.1 Overview of the Proposed System
The proposed system is a Web-based parent and school communication system that we going to
develop by using PHP language. The static page is designed by using HTML for the layout of the
web page, Java Script for validation and CSS for more attractive Web site while the server-side
programming will be done by using PHP and using MYSQL as a database. The major actors or
players of the system are, admin (as a director), student, teacher, parent and Record officer are
login to the system by using their user name, password and user level to login to the system, they
perform different tasks performed in the existing system in the secured and advanced manner by
using new technology. Our system performed different tasks such as the admin (as a director)
controls all activities of the school, Record officer can, generate transcript, update reports and
students’ detail and prepare final report. The Admin manage account (i.e., create, update,
activate, deactivate, delete the user account), the Admin can view change password, view
feedback and the teacher can add attendance of the student, view report and add comment for
parents. The parents can view report of their student, see attendance, see student result and add
comment. To access the service where registered parents, have access to students’ profile and get
information on the student in concern uploaded by the teacher.

3.2 Proposed Solution to the New System

 The parents who have an account to access the students’ data and get information on
the student in concern uploaded by the teacher.
 Giving awareness for the parents how they easily use the system in order to follow up
their students.
 As much as possible setup many wireless router connections in the school compound in
order to address internet connection for staff members of the school.
 Telling the parents, the use of internet service saves their time, money and power of
coming directly to the school to follow up their student.

15
3.3. Requirement Analysis
3.3.1 Functional Requirements
Functional requirements describe what the system will do and specify behavior or function. And
also functional requirements drive the application architecture of a system. A requirement
specifies a function that a system or component must be able to perform. Functional
requirements specify specific behavior or functions. The functional requirements of the proposed
system are listed as follows:-
 Create user accounts.
 view students information
 Update user account
 Assigning teacher
 Assign course
 Generate report
 Delete user account
 Insert attendance
 View attendance
 Give comment
 View comment
3.3.2 Non-Functional Requirement
Non-functional requirements cover all the remaining requirements which are not covered by the
functional requirements. They specify criteria that judge the operation of a system, rather than
specific behaviors. The non-functional Requirements expected to be provided by proposed
systems are:
User Interface and Human Factors: The interface of the proposed system is simple to
understand; easy to use and user-friendly interface and users of the system easily use and
perform their task. To design better user interface we design beautiful buttons, check boxes,
menus and others by using bootstrap frame work.
Security Issues: The system is much secured based on the username and password for all user
activity. Nobody can access the system without the authorized person and the passwords are not
visible cannot access any one because of the passwords are encrypted by MD5 algorithm.

16
Performance Consideration
1. Response Time- Upon request for user inquiry the system under normal condition should
display results as quickly as possible.
2. Processing Time- Since the system is developing with efficient programming language and
database upon request for user’s Activities; the system under normal condition should `process
the request as quickly as possible by using multi-tier architectures.
3. Concurrent - Processing: the system can support multiple users at a time.
Error Handling and Validation: The system will check user inputs to the system to handle
error. It handles and show error by showing the error message when the user enters invalid
input. We handle these errors in client side by using java script validation. We use front end
validation to reduce the loading time of pages.
Quality issues: Since the system is used for a follow up process it is more related with resource
control of the high school so it should be accurate, robust and reliable.
3.4 Requirement Analysis
Systems Requirement Analysis gives the professional systems engineer tools to set up a proper
and effective analysis of the resources, schedules and parts that will be needed in order to
successfully undertake and complete any large, complex project.
3.5 Actors and Use Case Identification
 Actors: -An actor represents a type of users of the system or external systems that the
system interacts with. An actor is a user of the system playing a particular role.
 Use cases: -A use case describes the sequence of events of some types of users, called
Actors, using some part of the system functionality to complete a process.
3.5.1 System Use Case Diagram
Use case diagram is one of the unified modeling languages (UML) which represents user’s
interaction with the system and depicting the specifications of a use case. As we know actors are
persons or users that use the system. Those are may be external entity or internal entity. In our
system we have five actors that use this system.
3.5.2 Actor Specification
This project has the following actors:
 System Admin(as a director)

17
  Teacher
 Record Officer
 Parent
 Student
3.5.3 Use case Identification
 Login
 Manage account
 Delete account
 Update account
 Create account
 Insert assessment
 Insert attendance
 Add comment
 View comment
 View assessment
 View attendance
 View report card
 Some important elements of use cases diagrams are:
 Use case: Use cases are used to represent high-level functionalities and
how the user will handle the system.
 Actor: The actor is an entity that interacts with the system. A user is the
best example of an actor.
 Different lines: Shows the relationships and dependencies clearly in the diagram.
 Subsystem: A place in which use cases are performed.
3.5.4 Use Case Diagram of the Project

18
Figure 3. 1 System use case diagram

create
account update
inset accont
assessment
delete
logout
account
<<extend>>
<<extend>>

<<extend>>
insert
attendance
<<include>> manage
<<extend>> account
set assign
assessment teacher Admin
<<include>>
Teacher <<include>>
<<include>> <<include>>
view
assign course
assessment
<<include>> <<include>>

login
<<include>>
give comment
<<include>> add calander
<<include>>

Parent view <<include>> <<include>>

comment
<<include>> add student

<<include>>

view report
add parent
card
Student
Record
add course officer

prepare
report card

H.room teacher

19
 3.5.5 Use Case Description
Table 3. 1Use case description for login.

Use case name Login

Use case id 01
Participating Actor All use
Pre- condition All users must have user name and password.
Flow of events Step 1. The user clicks the login link.
Step 2. The system displays login page for users.
Step 3. The users enter username and password.
Step 4. The system checks the validity of user
name and password.
Step 5. The user logs in to the system.
Use case ends.
Post- condition The user login to the system successfully.
Alternative course of action Step 1-4 remains the same.
The user didn't type the correct username and
password, or do not have an account.
4.1. The system displays incorrect username
and/or password message.

20
 Table 3. 2 Use case description for Create Account

Use case name Create Account

Use case id 02
Participating actor Administrator.

Pre- condition The system admin must login to the system.

Flow of events Step 1. The administrator clicks create account link.
Step 2. The system displays create account form.
Step 3. The admin fills the required information and click create button.
Step 4. The system validates the entered information.
Step 5. The system saves user account. Use case ends.
Post- condition User account created successfully.
Alternative course of Step 1-4 remains the same
action If the admin fills invalid information
4.1. The system displays error message and try again
Table 3. 3 Use case description for Delete Account

Use case name Delete Account

Use case id 03
Participating actor Administrator.
Pre- condition The system admin must login to the system.
Step 1. The system admin clicks on the delete user account link.
Flow of events Step 2. The system displays delete user account form.
Step 3. The system admin enter username and click search user
button.
Step 4. The system checks the validity of username.
Step 5. The system deletes user account from database.
Use case ends.
Post- condition The system admin successfully deletes user account.
Alternative course of action Step 1-4 remains the same
if searched user account doesn't exist in the database.
4.1. The system displays user account doesn’t exist in database.

21
Table 3. 4 Use case description for Insert assessment

Use case name Insert Assessment

Use case id 04
Participating Teacher
actor
Pre- condition A teacher must login to the system.
Step 1. The teacher clicks insert result link.
Flow of events Step 2. The system displays insert result form.
Step 3. The teacher enters student id and click search button.
Step 4. The system displays student information.
Step 5. The teacher fills student mark.
Step 6. The system checks and validates inserted mark.
Step 7. The system store results in the database. use case ends.
Post- condition Student result successfully saved in database.
Alternative course Steps 1-6 remain the same.
of action If the teacher inserts invalid student result.
6.1: The system displays error message incorrect result.
Table 3. 5 Use case description for Insert Attendance

Use case name Insert Attendance

Use case id 05
Participating actor Teacher

Pre- condition Teacher must login to the system.

Step 1. The teacher clicks the insert attendance link.
Flow of events Step 2. The system displays inset attendance form.
Step 3. Teacher insert student id and clicks search button.
Step 4. The system displays student information.
Step 5. The teacher records the attendance.
Step 6. The system checks the recorded attendance.
Step 7. The teacher inserts student’s attendance. Use case ends.
Post- condition Student attendance successfully saved in database.

22
Alternative course Steps 1-6 remain the same.
of action If the teacher insert invalid student attendance.
6.1: The system display error message incorrect attendance.

Table 3. 6 Use case description for Generate report

Use case name Generate report

Use case id 06
Participating actor Record officer/ teacher

Pre- condition Must login to the system by using their accounts.

Step 1. They click generate report link.
Flow of events Step 2. The system display report generates form.
Step 3. Record officer and the teacher fill the
report form and click generate button.
Step 4. The system checks the validity of the
report.
Step 5. The report generates successfully.
Use case ends.

Post- condition Report Generated Successfully.

Alternative course of action Steps 1-4 remain the same.
If the report form is not filled properly.
4.1 The system displays filled incorrect data.

23
Table 3. 7 Use case description for Add Comment

Use case name Add Comment

Use case id 07
Participating actor Parents and Teacher.

Pre- condition They must login to the system.

Step 1. They click give comment link.
Flow of events Step 2 The system displays give comment form.
Step 3. They enter their name and fill their
comment.
Step 4. The system checks the validity of data.
Step 5. They give comment successfully.
use case end.

Post- condition The user gives comment successfully.

Alternative course of action If the user enters invalid username or doesn’t
exist on the database.
Steps 1-4 remain the same.
4.1 display error message and Give Comment
Again.

24
 Table 3. 8 Use case description for View Comment

Use case name View Comment

Use case id 08
Participating actor Parents, Teachers, and students

Pre- condition They must login to the system.

Step 1. They click view comment link.
Flow of events Step 2. The system displays view Comment Page.
Step 3. They enter student id and click search button.
Step 4. The system display view comment form.
Step 5. They view Comment successfully.
use case end.
Post- condition The users successfully view the comment.
Alternative course of action If the user enters invalid id or doesn’t exist in the database.
Steps 1-4 remain the same.
4.1 The system displays error message and display view Comment Again.

Table 3. 9 Use case description for Prepare transcript

Use case name Record student and parent

Use case id 9
Participating actor Record officer

Pre- condition The Record officer must login to the system.

Step 1. Record officer click add student or parent link
Flow of events Step 2. The system displays add student or parent page.
Step 3. The Record officer fill student or parent information and click submit button
Step 4. The system checks the validity of data.
Step 5. Record is successfully added. Use case end.

Post- condition The Record officer successfully record students and parents.
Alternative course Step 1-4 remains the same. If the Record officer fills invalid data and or doesn’t exist on
of action the database.
4.1 The system displays error message and fill data again.

25
Table 3. 10 Use case description for view assessment

Use case name view assessment

Use case id 10
Participating actor Parents and students

Pre- condition They must be login to the system.

Step 1. They click view Result link.
Flow of events Step 2. The system displays the result form.
Step 3. They enter the id number and click search button.
Step 4. The system checks the validity of entered id.
Step 5. The user clicks view result button.
Step 6. The users successfully view result. Use case ends.
Post- condition The students and the parents successfully view the result.
Alternative course of action If they enter incorrect id or id does not exist in the database.
Steps 1-4 remain the same.
4.1 The system displays error message enters the correct id.
Table 3. 11 Use case description for View Attendance

Use case name View Attendance

Use case id 11
Participating actor Parents

Pre- condition The parents must be login to the system.

Step 1. The user clicks view attendance link.
Flow of events Step 2. The system displays the attendance form.
Step 3. The user enters the id number of students and searches.
Step 4. The system checks the entered id number.
Step 5. The users successfully view attendance.
Use case ends.
Post- condition The parents successfully view attendance by using this system.
Alternative course of action If the parents enter incorrect id or it does not exist in the database.
Steps 1-4 remain the same.
4.1 The system displays error message.

26
3.6 Class Diagram
Class Diagram gives the static view of an application. A class diagram describes the types of
objects in the system and the different types of relationships that exist among them. This
modelling method can run with almost all Object-Oriented Methods. A class can refer to another
class. A class can have its objects or may inherit from other classes. UML Class Diagram gives
an overview of a software system by displaying classes, attributes, operations, and their
relationships. This Diagram includes the class name, attributes, and operation in separate
designated compartments.
 The purpose of the class diagram can be summarized as:
 Analysis and design of the static view of an application
 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 The following diagram shows the overview of this project class diagram:

27
 USERS
ACCOUNT
-id varchar
+user name string 1 1
has +fname string
-password string
+lname string
+role varchar
+age int
+login () +sex varchar
+logout ()

ADMIN RECORD OFFICER TEACHER PARENT STUDENT

1 *
* *
+assign teacher () +record student() coment -view attendance() coment
-add assessment() -view assessment()
+assign course () 1 +record parent() -add atendance() -view assessment()
1 +give comment() +view comment()
+manage account() +set section () +add coment() -view attendance()
1 +view comment()
1 +view comment() 1
1 view 1 1
1 1 1 1
prepare
add
*
* *
* ATTENDANCE view
REPORT CARD * view
COURSE +date varchar view
asign +date varchar -student id varchar ASSESSENT
-course code +st name string +course name string
varchar -st id varchar add/view +date varchar
-insert attendance()
+course name +prepare report card() view/add1 -student id varchar *
-view attendance()
varchar +course name string
+course type vchar add * +teacher name
+section varchar +grade varchar
+assign course() +section varchar
+teach course() SECTION -insert assessment()
COMMENT * -view assessment()
-section id varchar view
* +section name string * -user id varchar *
+date varchar
+assign section() +add comment()
+view comment()

Figure 3. 2 class diagram

28
3.7 Sequence diagram
A sequence diagram in a unified modeling language (UML) is a kind of interaction diagram that
shows how processes operate with one another and in what order. It is a construct of a Message
Sequence Chart. 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
typically are associated with use case realizations in the Logical View of the system under
development.
 The followings are important elements of sequence diagram.
 Actor: a type of role played by an entity that interacts with the subject.
 Lifeline: A lifeline represents an individual participant in the Interaction.
 Activations: A thin rectangle on a lifeline) represents the period during which
an element is performing an operation.
 Message: A message defines a particular communication between Lifelines of
an Interaction.
 Return message: Return message is a kind of message that represents the pass
of information back to the caller of a corresponded former message.
 Self-message: Self message is a kind of message that represents the invocation
of message of the same lifeline.

29
Figure 3. 3 Login Sequence diagram

log in
login login form database main page
user homepag controller
<<link>> <<UI>> <<DB>> <<UI>>
<<control>>

1:open()

2:click login link

3 request

4:display login form

5:enter username and password 6.submit

self check

7 if invalid

8: valid 9 successful

check data

10 if false data

30
Figure 3. 4 Insert assessment sequence diagram

insert ass link

teacher insert assessment database
teacher assessment controler
page<<UI>> link<<link>> <<DB>>
form<UI>> <<validate>>

1browse page

2. click link

3 request

4.display assessment form

5.insert result
6 submit

7.if invalid()
8 if valid()
9 invald please try
check availability

10 successfuly inserted

31
Figure 3. 5 Insert attendance sequence diagram

insert insrt att link

teacher database
teacher attendan attendance controller()
page ce link form<<UI>> <<validates>>
<<DB>>

1.browse page()
2 select

3 request

4 display the attendance form

5.insert attendance
6 submit

self check

7 if invalid 8 if valid

check availability
9 invalid try again

10 inserted suuceesfully

32
Figure 3. 6 Sequence diagram for prepare report card

prepare report preparet report database

record officer
card report card controller <<DB>>
officer page<<UI>>
link<<link>> form<UI>> <<validate>>

1.browse page

2. select link

3 request

4.display form()

5.fill the card form

6 submit

6.1 if invalid
7 if valid/save
chck data

8 successful

33
3.8 Activity Diagram
Activity diagram is another important diagram in UML to describe the dynamic aspects of the
system. It is basically a flowchart to represent the flow from one activity to another activity. The
activity can be described as an operation of the system. The control flow is drawn from one
operation to another. Activities are states that represent the execution of a set of operations.
Activity diagrams are similar to flowchart diagrams in that they can be used to represent control
flow (i.e., the order in which operations occur) and data flow. It is a diagram that can shows the
flow of information activities using, flow controls. The completion of these operations triggers a
transition to another activity.
Activity diagrams are constructed using limited number of shapes connected with arrows.
 The most important shapes used to construct activity diagram are:
 Rounded rectangles represent action.
 Diamond shape represents the decision.
 A blue circle represents the initial state.
 An encircled black circle represents the end of activity.

34
Figure 3. 7 Create account Activity diagram

Activity
diagram for browse admin page
create
account
Actor
click create acount admin,record
link officer

display the form

fill the form

Please fill correct input

click on submit
button

invalid

yes

account created
successfully

Figure 3. 8 Activity diagram for Login

35
 Activity open home page
diagram for
login
click login link

display form

enter user name

and password
Actor all user

submit

invalid

valid

succssefully login to
system

Figure 3.4 Activity diagram for view comment

36
 Activity
Actor
diagram for
teacher,
view
browse page parent,
comment
student

display user page

click view comment

link

display view
comment form

select user type

click view button

invalid

yes

view

37
Figure 3. 59 activity diagram for view attendance

Activity
diagram for Actor
view teacher,
browse page
attendance parent,
student

display user page

click view
attendance link

display view
attendance form

fill student info

click view button

invalid

yes

view

38
 CHAPTER FOUR
SYSTEM DESIGN
4.1 Design Goal
System design is the transformation of the analysis model into a system design model. The
design phase is the interface between the requirement specification and the implementation part.
One of the importance’s of this phase is to clarify specifications as it clearly represents the blue
print of the actual system.
The purpose of designing is to show the direction how the system is built and to obtain clear and
enough information needed to drive the actual implementation of the system. It is based on
understanding of the model the software built on. The objectives of design are to model the
system with high quality. Implementing of high-quality system depend on the nature of design
created by the designer. If one wants to change to the system after it has been put in to operation
depends on the quality of the system design. So, if the system is design effetely, it will be easy to
make changes to it.
 We identified the following design goals in our project:
 Availability: the system is available at any time on any operating system. The
system should be available for twenty-four hours of a day so that it is available
for user.
 Security: The system should also be designed to prompt the user with
password and user name. This provides security in such a way that
unauthorized users can not have access to the system’s resources and
information.
 End user: The system should provide user friendly and self-explanatory
graphical user interface that eases the interaction of the user with the system.
 Performance: The response time of the system should be efficient which is
faster and accurate.
 Usability: With the increasing exposure of people to computer applications in
the home as well as somewhere to increase the usability of the system.

4.2 System Architecture

The existing system doesn’t use any computerized system to provide service and it is started with

39
the traditional file processing. Hence there is no system architecture, but the proposed system
architecture determines the type of interactions that the components are going to have. The
architecture that does this work uses Client/Server architecture. In this type of architecture the
server is responsible to receive a request from the client and respond to the request, whereas the
client is responsible to interact with that of the users of the system. The server does two types of
work. The first type is a web server, which is responsible to receive browsers’ request through
http protocol and give response to them accordingly. Whereas the second type of server is a
database server, which is responsible to provide the requested database services to the web
server. The database server is generally responsible for modification and insertion of data to the
database. It can only communicate with the web server. The client side is a web browser which
receives requests from the user of the system and responds to the request by communicating with
the web server. If the user has a request on data, the browser passes the request to the web server
then the web server pass the request to the database server.
 The following below figure shows the client server architecture for the project.

Data response

Data request

Data base

Sever machine
sever

internet

Client computer
Client computer

40
Figure 4. 1 architecture diagram

4.3 Sub System Decomposition

In order to simplify and minimize the complexity of the solution domain, our system has been
divided into some subsystems. In dividing the system, we decompose the system based on the
function that the system does. This means we divide the system functionally. The reason that we
divide based on the function is since each subsystem have its own function. . The goal of the
system decomposition is to reduce the complexity of design model and to distribute the class of
the system in to large scale and cohesive components.

Parent and school

Communication system

Admin Record
Techer Parent Student
officer

Insert Give
Record assessment comment View
parent assessment
Manage
account
View
Insert attendance
attendance
Record
student
Assign
course

Assign
teacher

Figure 4. 2 sub system decomposition

41
 4.4 Access control and Security
The proposed system follows multi user system. In multi user system, different actors have access to
different functionality and data. Then it must have: -
 Confidentiality: Only authorized person can see the information. Private data is kept
private; personal privacy is respected.
 Integrity: There are limits on who can change the data in this system.
 Availability: The system is available at all times to authorized users.

Table 4. 1 Access control and security table

Operation

Actor Account Result Attendance Report card

Admin Create ---- ---- ----

Update
Delete

Record officer - ---- ---- prepare

Teacher - Insert Insert ----

Update

Parent - View View view

Student - View View View

4.5 Collaboration Diagram

Collaboration diagrams are used to show how objects interact to perform the behavior of a
particular use case, or a part of a use case. Along with sequence diagrams, collaboration is used

42
by designers to define and clarify the roles of the objects that perform a particular flow of
events of a use case. They are the primary source of information used to determining class
responsibilities and interfaces.
Figure 4. 3 collaboration diagram for login.

5.submit

2.select login form

1.user visit IU() homepage Login form

3.display login form

4.Fill username and password

7.try again Coll

diagram
user for login
6.validate

9.access

Login
database
controller
8.successfuly login

43
Figure 4. 4 Collaboration diagram for registration users.

Figure 4. 5 Collaboration diagram for insert assessment

44
 4.6 Persistence Data Diagram
For persistent data management, we use MYSQL, a popular open source RDBMS. This database
keeps track of detailed information of the school members. We have identified the following
relationships between the system classes.
Figure 4.6 persistence diagram

45
 4.7 Component Diagrams
Component diagram is a diagram that represents components in the system, the relationship between
components, and provides an interface.
Systems may be built from components in component-based architecture. Component diagram
shows how objects (classes) in our system will grouped together and form components. The
components interact with each other either in giving service to other components or requesting
service from other component. Component diagrams are particularly useful with larger teams.

46
 Application
Client machine Database server
server

security
Manage account

Assign teacher

admin
Assign course persistance

Record Record student

officer
Record parents
teacher
Database
Add course

parent Set section

student Insert assessment

View assessment

View comment

View attendance

Figure 4. 76 component diagram

4.8 Deployment Diagram

Deployment diagram depicts a static view of the run time configuration of processing nodes and the
components that run on those nodes. In other word deployment diagram shows the hardware for your
system, software installed on your hardware, and the middleware used to connect the disparate
machines to one another. Using deployment diagram we can show the structure of the run-time
system.

47
 Application
server query
Data server

eee response

Manage
account
Persistence
user Assign data
teacher

Assign
course

Client browser Record

User interface student

Record
parent

Add database
course

Set
section
Insert
assessment

View
assessment

View
comment

View
attendance

Figure 4.8 deployment diagram

48
 Reference
[1] Object Oriented Systems Analysis and Design Using UML v2, (4th Edition), John

Wiley & Sons, 2012.

[2] Bernd Bruegge and Allen H. Dutoit, Object-Oriented Software Engineering Using

UML, Patterns, and Java, 3rd Edition, Prentice Hall, 2010.

Martin Fowler, UML Distilled A Brief Guide to the Standard Object Modeling

49