Professional Documents
Culture Documents
School Management System
School Management System
UNDER GUIDANCE OF
Ermiyas Birihanu Belachaw (MSc)
BY
Name Id
i
Approval Form
This is to confirm that the project report entitled Ras ZeSellasie School management system
submitted to Wolkite University, College of Computing and Informatics department of Software
Engineering in partial fulfilment of the requirement for the award of the degree of Bachler of
Science in Software Engineering is an original work carried out by Alemayehu Bogale, Solomon
Bekele, Mekonin Aklilu and Lemi Tasew under my guidance. The matter embodied in this
project is reliable and is genuine work done by the student and has not been submitted whether to
this University or to any other University/Institute for the fulfilment of the requirement of any
study.
______________________ _______________________
______________________ _________________________
______________________ __________________________
ii
Acknowledgements
First of all we would like to thank GOD keeping us healthy to do this project. Next thanks to
our advisor Mr. Ermiyas Birihanu for his advising, guiding and gives necessary comments until
the completion of the documentation of the project. And also we would like to say thanks
Department officer Joseph Wondwosen for his support and adjusting different facilities for the
development of this project documentation. Deeply we would like to say thanks for Wolkite Ras
ZeSellasie School Director Sisay Desu Kiraga for giving us full information about how the
current system work. Finally thanks to group members and other peoples who support us for our
project document completion.
iii
Table of Contents
Approval Form .............................................................................................................................................. ii
Acknowledgements ...................................................................................................................................... iii
List of figure ............................................................................................................................................... vii
List of table ................................................................................................................................................ viii
Abbreviations ............................................................................................................................................... ix
Abstract ......................................................................................................................................................... x
CHAPTER ONE ........................................................................................................................................... 1
1. INTRODUCTION OF WHOLE PROJECT PROCESS ....................................................................... 1
1.1. Introduction ................................................................................................................................... 1
1.2. Background of Organization ......................................................................................................... 1
1.3. Background of the project ............................................................................................................. 2
1.4. Statement of the problem .............................................................................................................. 2
1.5. Objective of the Project................................................................................................................. 3
1.5.1. General Objective ................................................................................................................. 3
1.5.2. Specific objective................................................................................................................... 3
1.6. Feasibility of the Project ............................................................................................................... 3
1.6.1. Operational Feasibility ......................................................................................................... 3
1.6.2. Technical feasibility .............................................................................................................. 4
1.6.3. Economic feasibility .............................................................................................................. 4
1.6.4. Political feasibility ................................................................................................................ 5
1.6.5. Schedule feasibility ............................................................................................................... 5
1.7. Scope of the project ...................................................................................................................... 5
1.8. Significant of the Project............................................................................................................... 6
1.9. Target beneficiary of the project ................................................................................................... 6
1.10. Methodology ............................................................................................................................. 6
1.10.1. Method of data collection ..................................................................................................... 6
1.10.2. System development methodology ......................................................................................... 7
1.10.3. Development Tools ................................................................................................................ 7
1.11. Systems Analysis and Design Approach................................................................................... 8
1.11.1. Limitation of the project ........................................................................................................ 8
1.11.2. Risks & contingencies ........................................................................................................... 8
iv
1.11.3. Assumptions and constraints ................................................................................................. 8
1.12. Team Decomposition ................................................................................................................ 9
1.13. Project Schedule...................................................................................................................... 10
CHAPTER TWO ........................................................................................................................................ 11
2. DESCRIPTION OF THE EXISTING SYSTEM ................................................................................ 11
2.1. Introduction ................................................................................................................................. 11
2.2. Overview of current system ........................................................................................................ 11
2.3. Organization structure ................................................................................................................. 12
2.4. Users of Current system .............................................................................................................. 13
2.5. Major functions of the Current System ....................................................................................... 13
2.6. Existing System Workflow structure .......................................................................................... 14
2.7. Reports Generated in the existing System .................................................................................. 15
2.8. Forms and other documents of current system ........................................................................... 16
2.9. Bottlenecks of the existing system .............................................................................................. 16
2.9.1. Performance ........................................................................................................................ 16
2.9.2. Input and Output ................................................................................................................. 17
2.9.3. Security and Controls.......................................................................................................... 17
2.9.4. Efficiency............................................................................................................................. 17
CHAPTER THREE .................................................................................................................................... 18
3. PROPOSED SYSTEM ....................................................................................................................... 18
3.1. Introduction ................................................................................................................................. 18
3.2. Product Overview ....................................................................................................................... 18
3.3. User Classes and Characters ....................................................................................................... 20
3.4. Functional Requirements ............................................................................................................ 20
3.5. Non Functional Requirements .................................................................................................... 21
CHAPTER FOUR:...................................................................................................................................... 23
4. SYSTEM ANALYSIS ........................................................................................................................ 23
4.1. System Models ............................................................................................................................ 23
4.1.1. Use Case model................................................................................................................... 23
4.1.2. Use Case Description.......................................................................................................... 25
4.1.3. Scenario .............................................................................................................................. 39
4.2. Object model ............................................................................................................................... 41
v
4.2.1. Data dictionary ................................................................................................................... 41
4.2.2. Analysis level class diagram ............................................................................................... 45
4.3. Dynamic Model .......................................................................................................................... 47
4.3.1. Sequence Diagram .............................................................................................................. 47
4.3.2. Activity Diagram ................................................................................................................. 56
4.3.3. State Diagrams.................................................................................................................... 59
CHAPTER FIVE ........................................................................................................................................ 63
5. System Design .................................................................................................................................... 63
5.1. System Overview ........................................................................................................................ 63
5.2. Design Considerations ................................................................................................................ 63
5.2.1. Design Goals ........................................................................................................................... 63
5.2.2. Design Trade-offs.................................................................................................................... 65
5.3. Architecture of the System.......................................................................................................... 66
5.4. Subsystem Decomposition .......................................................................................................... 68
5.5. Hardware/Software mapping ...................................................................................................... 70
5.6. Persistent data management ........................................................................................................ 71
5.7. User interface design................................................................................................................... 72
5.8. Object Design.............................................................................................................................. 74
5.8.1. Interface documentation guidelines .................................................................................... 74
5.8.2. Class interfaces ................................................................................................................... 76
Appendix ..................................................................................................................................................... 79
References ................................................................................................................................................... 83
vi
List of figure
Figure 2.1: Organization Structure ............................................................................................... 12
Figure 2.2: existing system Work flow structure diagram ............................................................ 15
Figure 3.1: Product overview ........................................................................................................ 19
Figure 4.1: use case model ............................................................................................................ 24
Figure 4.2: Class diagram ............................................................................................................. 46
Figure 4.3: Registration sequence diagram ................................................................................... 47
Figure 4.4: Account sequence diagram ......................................................................................... 48
Figure 4.5: Login sequence Diagram ............................................................................................ 49
Figure 4.6: Attendance sequence diagram .................................................................................... 49
Figure 4.7: Timetable Sequence Diagram .................................................................................... 50
Figure 4.8: Student discipline record sequence diagram .............................................................. 51
Figure 4.9: various report Sequence diagram ............................................................................... 52
Figure 4.10: Resource sequence diagram ..................................................................................... 53
Figure 4.11: View Report sequence diagram ................................................................................ 54
Figure 4.12: Generate grade report sequence diagram ................................................................. 55
Figure 4.13: Admin side activity diagram .................................................................................... 56
Figure 4.14: teacher side activity diagram .................................................................................... 57
Figure 4.15: other user activity diagram ....................................................................................... 58
Figure 4.16: Registration state machine diagram ......................................................................... 59
Figure 4.17: login state machine diagram ..................................................................................... 60
Figure 4.18: Generate various content state diagram.................................................................... 61
Figure 4.19: Attendance record state machine diagram................................................................ 61
Figure 4.20: Resource record state machine diagram ................................................................... 62
Figure 5.1: Architecture diagram of the system............................................................................ 67
Figure 5.2: System decomposition diagram.................................................................................. 70
Figure 5.3: Deployment diagram .................................................................................................. 71
Figure 5.4: Persistent data management ....................................................................................... 72
Figure 5.5: Main Home page User Interface ................................................................................ 73
Figure 5.6: User Home Page User Interface ................................................................................. 74
vii
List of table
Table 1.1: Cost estimation .............................................................................................................. 4
Table 1.2: Team decomposition...................................................................................................... 9
Table 1.3: Project Schedule .......................................................................................................... 10
Table 2.1: User of current system ................................................................................................. 13
Table 3.1: User class and characters ........................................................................................... 20
Table 4.1: Use case description .................................................................................................... 39
Table 4.2: Data dictionary............................................................................................................. 45
Table 5.1: class interface............................................................................................................... 78
viii
Abbreviations
SMS………….. School Management System
OS………………Operating System
XAMPP ………..X (“cross”-platform), Apache HTTP server, MySQL, PHP and Perl
PC……………….Personal Computer
PHP……………..Hypertext Preprocessor
KG……………… Kindergarten
IT …..Information technology
ix
Abstract
The aim of this industrial project is to develop automated School management system for
Ras ZeSellasie elementary school. The project is web based that develop by PHP at the front end
and MySQL at the back end based on three tire architecture.
The methodology used in this project is Object oriented system analysis and design
methodology and software development model methodology. The system is developed based on
software development life cycle (SDLC) which includes requirement analysis, system analysis,
system design, implementation, testing and maintenance.
The main functionality of the system is student registration, grade report, transcript generating,
report generating, notice posting, attendance recording, timetable and exam schedule generating,
discipline recording and resource managing. The project organized by the chapter. Each chapter
contents the sub contents of the project. The chapters are Introduction of whole project process,
Description of the Existing System, Proposed System, System Analysis, System Design,
Implementation, Testing Plan and Conclusion. Thus, we need to develop RSMS which is a
versatile and complete end-to-end school management software with precision engineered to
enhance the administrative efficiency of educational institutions.
x
CHAPTER ONE
1
The society participation in this school is very high that helps in different sectaries like fulfilling
facilities that needed for the school rather than government. Discipline committee also selected
from community those gives advice and come to assembly for some decision and judgements.
The school has different clubs like HIV clubs, sport clubs, min media clubs etc.
According to the Ras ZeSellasie school mission statement, the school seeks to produce
generation who’s elegant, responsible, and wiser and who trust on hard-working, and also create
intellectual students with a safe, healthy learning environment. Good management and fast data
transfer are one important aspect of that learning environment, since almost all students,
teachers, unit leaders and admin director had spent a lot of their times doing their day-to-day
activities on that environment.
However, The Ras ZeSellasie elementary school uses the manual based management system,
due to this it has the number of problems such as: it takes a lot of man power to do tasks,
resources, time, and space when managing the system, Searching the data from the number of
files which is difficult, data records are stored on papers that may be damage and redundant,
report generation is very weak, and others time table producing, exam scheduling manual that
take resource and time, also the manual file handling system task time when updating student,
teacher and employee information and school resource files.
2
1.5. Objective of the Project
The objective of this project work is presented here under in terms of general and specific
objectives.
The existing system is clearly understood in statement of problem the next step is to conduct
the feasibility study, which is a high level capsule version of the entire System Analysis and
Design process. The objective is to determine whether the proposed system is feasible. The five
tests of feasibility have been carried out:
3
1.6.2. Technical feasibility
Technical feasibility is the measure of practicality of the specific technical support and the
availability of technical resources and expertise to use the system. The proposed system can be
easily maintained and repaired without requiring high Experts or technical supports, because the
system will be installed in adaptable technology’s and the employee of the organization have
some knowledge about technology by providing training and help how to use the system and can
use the system easily . So the system is technically feasible
4
1.6.4. Political feasibility
The project built without violating rules and regulations of the governments as well as the
organization. The system being built is for the sake of service of the organization, so that the
project is legally feasible.
Scope In:
Registration of the Student, Teacher and administrative staffs
Attendance
Class time table
Exam scheduling
Grade report/ generating transcript
Resource managing
Discipline record
Post notice
Scope Out:
Library management
One to five group management
Club management
Fee management
5
1.8. Significant of the Project
After this project is finished and properly used it gives great benefits to employees and
customers of the institution.
Developer Team: -To developers the system will add new knowledge, get problem solving skill
then graduate with it.
Users of the system: -Teachers, students, admin and every employers can be benefit from the
system that the system will save their times and workload, reduce data redundancy, reduce
complexity and get easy access
1.10. Methodology
1.10.1. Method of data collection
There are different methods of data collection methods. From those we used the following
methods respectively to collect data from the organization.
6
Direct Observation: we had directly observed the school to get the right information
about the organization and also understand by viewing how the existing system works.
Interview: we had asked some question and interviewed the manager and another
employee of the organization and we have got enough and reliable data which is
important to do the project. Before making an interview, we prepared a number of
questions related with our project.
Document analysis: we had analyzed the manual resources of the organization how the
current system operates and we reviewed different projects respective with student
management system.
7
Documentation: Microsoft office 2016
Designation: Edraw Max and Enterprise architecture for designing
UML diagrams.
Storage: MySQL for the database back end
Coding: PHP, HTML, CSS, stylesheet front end
Risks
Virus may attack the file.
File may be corrupted and backup data loss when system crash
If miss installation or configuration with the development tools occur.
If internet service is not available
Contingencies
We use antivirus and firewall to avoid virus attacks
The team uses different back up techniques through our daily activity
in the project development as a solution.
The development tools not working so Re-configure the setup.
Team Uses optional way out of the campus for internet service.
8
Assumptions
We will finish this project with the given schedule which planned in
section 1.13 below.
We use the development tools in the listed section 1.10.3 above.
The internet service may available in the campus at all days.
The adviser have great role for the success of this project.
There should be enough facilities from the college.
We will suggest how to configure full setup on client and server.
Constraints:
We should have to finish the project based on given schedule
Group member should have to attend in project development activities
The end product of the project should meet the proposal
The advisor should have to give more than enough advice and
direction.
9
1.13. Project Schedule
The project is developed according to the schedule planed that shown in table 1.3 below:
10
CHAPTER TWO
Wolkite Ras ZeSellasie elementary school management system is focus on the registration of
students, teacher and other administrative staffs, managing students and the data exchanges of
reports between the offices of the school. The offices of the school include the director office,
teacher office, resource office, and record office and so on. the school management system is
manual. Due to this the system requires different materials like paper, pen, binder, shelfs etc.
Which waste time, labors and costs.
Generally the system is not more developed with computerized system so we going to develop
automated system for the school. In this chapter we were discussed overview of the current
system, organizational structure, users of the current system and major functionalities exists in
the current system and users.
11
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. Students and teachers are almost
depending on school timetable for their day-day activities.
Director
Unit Leader of
Grade 1-4
Liebrary
HR Manager
Unit Leader of
Grade Coordinetor
Grade 5-8 Vice
Director /Record
Course
officer
Course
Grade Coordinetor
Grade one Club
Labaratory
Liebrary
Amharic
English
Amharic
Grade Six Amharic
Grade Three
Basic Science
English
Grade Four English
Grade Seven
Maths
Biology
Biology
Civic
Civic
Social Science
Social Science
Chemistry
Sport
Art Physics
Sport
Music
12
2.4. Users of Current system
Users are persons who are react in the environment of school. Those persons have directly
interacted to the system. This persons are performs some actions like registering students,
recording discipline , preparing student marks, recording student attendance, producing time
tables, managing student information, generating reports, and so on. So the table 2.1 below
describes the users of current system.
Registering the students every beginning of the year: They fill the appropriate
information on the forms with attaching photos and submit to record officers then
Record officer checks whether valid or not.
Preparing reports
13
Preparing transcripts or grade report: Teachers submit the student marks to record
officers and record officers organizes the student marks, after organizing prepare
transcript, then the students take the transcripts
Managing student information: Teachers gives exams, tests, assignments, etc. to the
students after collecting student marks and organize he calculates and prepare marks,
then students takes mark from their teachers
Recording the students that has the discipline cases: Students fill the forms, discipline
committee checks it, and then discipline committee stores the student information finally
students take warring letter from school.
Attendance taking: Homeroom teacher take attendance daily, then reports to record
officer, finally semester attendance is checked whether students seat for exam or not.
Managing library, laboratory systems and human resources.
14
Figure 2.2: existing system Work flow structure diagram
15
Annual Report on student registration and skill.
Semester report teaching learning process
Daily Report on student attendance.
Annual Report on new student registration and skill.
Student registration form: It is the form that used to register students of the school
that includes section, name, gender, age, parent name, address, phone and signature
shown in appendix 1.1.
Report form: It’s the form that contain Ras zeSellasie school staff workers job
performance report includes name of worker, sex, age, date limitation for
performance, evaluation criteria and status level shown appendix 1.2.
Attendance form: Is the form that homeroom teacher use to check whether the
students are present or absent in the class. It contains the attributes like student name,
sex, age, week, date, semester and year shown appendix 1.3 picture.
Time table form: Is the form that used to show weekly class schedule of the school
shown in appendix 1.4.
Grade report form: This form describes the student grade report that used to report
student’s grade of the year that contains student name, mark, average and sex shown
in appendix 1.5
16
2.9.2. Input and Output
Input
Data is not captured in time to be useful.
Data is not accurately captured – contains errors.
Data is captured redundantly – same data is captured more than once.
output
Lack necessary and relevant information.
Sometimes Information is not in a useful format like registering user
information.
Information is not timely to its subsequent use
2.9.4. Efficiency
Waste of time
Data is redundantly input or copied.
Data is redundantly processed.
Information is redundantly generated.
Unavailability of staff’s on time.
Waste of materials and suppliers
Effort required for tasks is excessive.
Materials required for tasks are excessive.
17
CHAPTER THREE
3. PROPOSED SYSTEM
3.1. Introduction
In this chapter the proposed system is described such as product overview, user class and
characters, functional requirements and nonfunctional requirements. Each elements described
one by one how they are functions to develop the proposed system.
In response to raised problem, our project proposes to investigate several options for making
the school more hospitable. We plan to carry out almost all-inclusive participatory modules into
options for school starting from registration up-to discipline record management, but we may not
cover all of them. We will also consider less expensive ways to mitigate some or all of the
problems noted above by creating simple and easy user-interactive School Management System.
18
e
notic Student
vie view
Administrator Cr ort
ea w e rep
te rep grad
Ge
Ac
co
or
t view
ne un ister
r t R eg
Ge a t ule
ne e tim ch ed
rat eta e x am S
eE ble view table
xa Time
Re
gis po m
s View
st c
ter n o h ed u
Us tic
ers e le
Record attendance
prepare Grade Report
View Exam schedule
u rce
reso view notice
ag e
Man t View Timetable
or
vi
rep Teacher
ew D i
Vi
e
vi
rat
ew
st
ew
ne
ud ipli
Ge
st
en n e
sc
ud
tm
co
en
ar
Employee m
ti
k
m
nf
en
o
t
Parent
Algorithm: -There are many algorithms that are used to create school management in general.
For instance genetic algorithm, but we use our own algorithm for creating timetable and others
19
3.3. User Classes and Characters
The proposed system has its own user classes and its character. The user classes and their
characteristics are described in the table 3.1: below.
Users Responsibility Technical skill
Directors/Admin Viewing reports, create Ability to work on different
accounts, manage exam in the past and should have
Schedule and timetable and computer skill.
Register users
Teacher Prepare Grade report, Record Should have diploma or BSC
attendance, and View notice,
timetable and exam schedule
Students View Grade report, Should learned KG school or
Discipline, notice, timetable should have above 6 age
and exam schedule
Employee Manages school properties or Ability to work on different
resource and generate report office
Parent View their students Ability to manage or take
information, Grade report and care their children
discipline
Table 3.1: User class and characters
The functional requirement of the Ras ZeSellasie School describes the function of the system.
This system is useful for obtaining effective and efficient service of the school.
The functional requirements should be complete and consistent. Completeness implies that all
the user requirements are defined and consistency implies that all requirements are specified
clearly without any contradiction definition.
Functional requirements
20
Record attendance: To records the student attendance to check student presence
and absence.
Generate reports: To generate reports of the school activity weekly, monthly and
annually to verify school functionality.
Generate timetable: To show class timetable of the school how to follow during
education time.
Generate exam schedule: To prepare schedule for the exam time.
Records discipline: To record the discipline case of the student.
Generate Grade report: To prepare grade report of the student.
Post notice: To inform school members what is going to care out.
Managing resources.
Recording student marks
3.5. Non Functional Requirements
The nonfunctional requirements relate to system attributes such as reliability and response time
and they can arise due to user requirements. Here below we list down the possible non
functionalities with related to this SMS system.
Security
Security requirements are important factors in this system as classified data will be stored in the
database. User validation will be done during login to insure that the user is valid and that the
user only has access to his or her permission data. General users will only have access through
the user interface.
Usability
The system will have consistent interface formats and button sets for all forms in the application,
will have a form based interface for all data entry and viewing formats, and will generate reports
that are formatted in a table and that should look like the existing manual report formats for user
friendliness, so the user interface is easy to use.
Maintainability
The system is developed by using high level and dynamic web development language as a result
the system will be easily maintained by the developer or other authorized trained person.
21
Efficiency
The web-based system should have easy and efficient code manipulation and have clear database
thus the response time should be very small i.e. not more than 5 seconds.
Reliability requirements:
The system robust enough to have a high degree of fault tolerance. For example, if the user
enters a wrong password or username or a value too large, the system should identify the invalid
input and produce a suitable error message.
Integrity
Only system administer has the right to change system parameters, such as creating account. The
system should be secure and must use encryption to protect the databases.
Performance
More effective when compared to the manual approach, resulting in fast accomplishment of task
with in some amount of time [Performance / Response time].
Availability
The system doing 24 hours in every day unless there is no internet connection but the system
shall not crash whenever internet connection is not available
22
CHAPTER FOUR:
4. SYSTEM ANALYSIS
4.1. System Models
To produce a model of the system which is correct, complete and consistent we need to
construct the analysis model which focuses on structuring and formalizing the requirements of
the system. Analysis model contains three models: functional, object and dynamic models. The
functional model can be described by use case diagrams. Class diagrams describe the object
model. Dynamic model can also be described in terms of sequence, state chart and activity
diagrams. For the purpose of this project we have described the analysis model in terms of the
functional model and dynamic models using use case, sequence diagrams, Activity diagram,
State diagram and class diagram.
Finally in this chapter we discuss functional, object and dynamic model with perspective of data
we gathered from the school.
4.1.1. Use Case model
The use case model is model that describes the requirement of the system in diagrammatic form
based on UML language. It describes the relationship between the actors of the system and use
case of the system. Figure 4.1: below shows the use case model of the system.
23
uc New usecase
Record
Attendance Generate
GradeReport
Record
marks
View
Timetable Student
View Exam
Schedule
Teacher
View Notice
Logout
Record
resource «extend» View
GradeReport
Update
resource Login
Manage
Resource
View Student
Delete Information
«include»
resource
Generate Registration
Report
Employee
View Discipline
Case
Post Notice
Create Exam
Schedule
Comment
Parent
Manage
ExamSchedule
Delete Exam
schedule
Generate
Exam
View Report Schedule
Add Stud_data
Update
Admin Student data
Delete
timetable
Manage
Timetable
Manage
Account Generate
timetable
Manage
Discipline Create
Delete timetable
account
Create Delete
Update
account discipline
account Update
Record
discipline discipline
24
4.1.2. Use Case Description
The use case description is used to detail description of the use case what and how the use case
works in order to perform user and system functionality. It can described in table 4.1 below.
25
UC_0 Login Description: To authenticate user to get into the system. Provides log in
2 forms to verify whether the user is authorized or not
1: User click login link 5: System verify the user name and
password
3: User fill the user name and
password with selecting user type 6: System display user home page
UC_0 Logout Description: It helps user to get out from the system
26
3 Actor: Student, Teacher, Parent, Admin and Employee.
Alternative flow: 2.1: If system stay login after logout, check network
then try again to logout
Additional notes: User should not forget logging out from system after
logged in.
UC_0 ViewTimet Description: It displays the class routine timetable for the user
4 able
Actor: Student, Teacher
Normal flow:
Additional notes: User can’t modify the time table except administrator
UC_0 ViewExam Description: It displays the posted exam schedule for the user
5 Schedule
Actor: Student, Teacher
27
Normal flow:
Alternative flow: 2.1: If system does not display exam schedule, check
if network is available. Try again
UC_0 ViewGrade Description: It displays student total mark and grade report for the user
6 Report
Actor: Student, Teacher, Parent, Record officer
UC_0 ViewDiscip Description: It displays students discipline status for the user
28
7 line Actor: Student and Parent
UC_0 View Description: It displays the students detail information for the user
8 Students
Actor: Student, Teacher and Parent
Information
Pre-condition: User should have logged in to system
link form.
29
Alternative flow: 4.1: If student id error system display error message
and return to step 3.
UC_0 Manage Description: To record, update and delete students discipline cases
9 Discipline
Actor: Admin
1.1: Admin click discipline link 1.4: System display discipline form
1.3: Admin select record option 1.6: System verify the information
2.1: Admin click discipline link 2.4: System query discipline case
registered student
2.3: Admin select update
2.6: System display student
2.5: Admin select student discipline
2.7: Admin edit data and click 2.8: system verify the information
update button
2.9: System update the data
3: Delete Discipline
3.2: System display the option
30
3.1: Admin click discipline link 3.4: System display discipline case
registered student
3.3:Admin select delete
3.6: System display conformation
3.5: Admin select student and
request.
click delete button
3.8: System delete from the list
3.7: Admin conform
Additional notes: Other user does not manage discipline except record
officer. Priority medium.
UC_1 Manage Description: To record, update and delete students detail information’s
0 Student
information
Actor: Admin
31
option 2.2: System display option
1.5: Admin fill the form and 2.4: System display recorded list
click record button
2.6: System display the data
2. Update
2.8: System verify the filled form
2.1: Admin click student data
2.9: System request conformation
button
2.11: System update the data.
2.3: Admin select update option
2.12: system update the data.
2.5: Admin select the from list
3.2: System display option
2.7: Admin edit and click
update button 3.4: System display list to delete
3. Delete 3.1: Admin click 3.8: System delete data from the list
student data link
Additional notes: Other user does not manage student’s data except
32
Adminstrator. Priority medium.
UC_1 Manage Description: To create, generate, update and delete school exam
1 ExamSched schedule
ule
Actor: Administrator
1.3: Admin select create option 1.6: system verify each time
1.5: Admin fill and add form until 1.8: system request confirm
finish 1.10: System stores in data base
33
button
Additional notes: Other user does not manage exam schedule except
administrator. Priority high
UC_1 Manage Description: To create generate, update and delete class timetable
2 Timetable
Actor: Administrator
1.3: Admin select create option 1.6: system verify each time
1.5: Admin fill and add form until 1.8: system request confirm
finish 1.10: System stores in data base
34
2.1: Admin click timetable link timetable
Additional notes: Other user does not generate time table except
administrator. Priority high
UC_1 View Description: To view various reports from record officer, resource
3 Report manager even teacher.
Actor: Administrator
35
1: Admin click view button 2: System display report type
Additional notes: Other user probably does not see the report types
except administrator
2.1: Employee click resource link 2.6: system verify and request
confirm
2.3: Employee select update option
2.7: system update the data
2.5: Employee select list, edit and
click update button 3.2: System display option
36
3. Delete 3.8: system delete list from
database
3.1: Employee click resource link
1.5: Admin fill the form and click 1.7: system stores account
create button information on database
37
link 2.4: System display list
2.5: Admin select from list and click 2.8: system delete selected list
delete button from database
38
Additional notes: Both Teacher and Employee can generate reports
UC_1 Record Description: To record students absence and presence and submit result
7 Attendance to record officer
Actor: Teacher
1.5: Teacher file check box until 1.6: system verify the data
finish all students of class and click
1.7: system record the attendance
save button
4.1.3. Scenario
Scenario is a set of actions performed to achieve a goal under some conditions. A scenario is
an instance of use case describing a concrete set of actions.
Scenarios are used as examples for illustrating common cases; their focus is on
understandability, and a set of actions performed to achieve a goal under some conditions. So, it
will be described below as follows.
Actors involved: Bereket as student, Melkamu as teacher, Mamo as parent, Bedru as Employee
and Sisay as Administrator.
39
Ato Sisay login to the system as Admin, then click on registration link and select user type to
register, the system display registration form, next Sisay enter Bereket’s, Melakus, Mamo’s and
Bedru’s information depending on user type, then system verify the user information and store
the data into database. Even Sisay register himself as he registered others.
Login: - To authenticate user to get into the system. Provides log in forms to verify whether the
user is authorized or not. Bereket visit the page and Select user type, then Fill the user name and
password and click login button, then System verify the user name and password, finally System
display home page
Logout: - It helps user to get out from the system. Mamo, Sisyay, Bereket, Bedru and bereket
click logout button, then System process close and display login page.
After logged in Melkamu visit timetable link, System display option, then Melkamu click view
button, System display timetable.
ViewExamSchedule: - It displays the posted exam schedule for the user
After Bereket logged in visit exam schedule link, System display option, then Bereket click view
button, System display exam schedule.
ViewGradeReport: - It displays Bereket’s total mark and grade report for Bereket, Mamo, also
for Melkamu. Bereket after logged in visit grade report link, System display option, then Bereket
click view button, System display Bereket’s grade report.
Sisay clicks record student data button, System display the forms to fill, then Sisay fill the form
and click add record button, System verify and register new record of the students, finally
System display success message. On the other hand Sisay Update recorded student information
by clicking update record button, then System display update form, then Sisay fill the form and
click update button, finally System update the data and gives success feedback. Also Sisay delete
recorded information by clicking delete record button, then System display conformation
message, then Sisay conform message, finally System delete record and display success message
ManageResource: - To create, record, update and delete resource
Bedru click resource link, System display option to select, then Bedru select from the options
such as ether record, update or delete. If Bedru select record option system display resource
40
form, then Bedru fill the form and click record button, then system verify the information and
add to database.
CreateAccount: - To create accounts for the users
Sisay click create account link, System display account form, then Sisay fill the form and click
create button, System displays conformation dialog, next Sisay then conform the dialog box,
finally System store account information and display feedback message back to Sisay.
GenerateReport: - To generates various reports
Bedru visit generate report link, System displays items type to generate, then Bedru Select items
and click on generate report button, finally System display generates items.
Sisay clicks Discipline link and select option that he wants to perform, If he select record
discipline link the system display the form to fill, then Sisay fill the form and click record button,
The system verify the form and request conformation, then Sisay conform it, finally system
stores the discipline information on the database. Even Sisay follows this step to perform other
operations.
41
Phone Int Not Null It stores mobile number.
Address Varchar(20) Not Null It stores students address.
Father Name Varchar(20) Not Null It stores students father
name
Mother Name Varchar(20) Not Null It stores students mother
name
Sex Varchar(20) Not Null It stores students sex or
gender
Age Int Not null To stores students age
Birth day Date Not null To stores students birth date
Date Date Not Null It stores registration date
42
Department Varchar(30) Not null Stores teachers graduated
filed
Date Date Not Null It stores registration date
Table Name: Attendance
Primary key: AttId
Foreign key: StudId
Description: used for marks students attendance in order to checks students absence or presence.
Field Name Data type Constraint Description
AttId Int Primary key It stores registered
attendance id
StudId Int Foreign key It stores foreign key of
students
StudentName Varchar (30) Not null To stores students name
Time Time Not null Stores attended time
Day Date Not Null It stores attended day
Week Int Not null To stores attendance week
Table Name: Timetable
Primary key: TTId
Foreign key:
Description: used to generate all the information about timetable.
Field Name Data type Constraint Description
TTId Int Primary key It stores tome table id
Day Date Not Null It stores day of time table
Subject Varchar(30) Not Null It stores subject.
Teacher varchar(10) Not Null It stores subject teacher.
StartTime Time Not Null To stores class starts time.
EndTime Time Not null To stores class ends time
Grade Varchar(30) Not null To store students grade
Section Varchar(5) Not Null It stores section
Semester Varchar(20) Not Null Stores semester
Date Date Not Null It stores time table date
Table Name:ExamSchedule
Primary key: ScId
Foreign key:
Description: used to arrange exam schedule of the school.
Field Name Data type Constraint Description
ScId Int Primary key It stores registered teachers
id
Date Date Not Null It stores first name.
Time Varchar(30) Not Null It stores last name.
Subject numeric(10) Not Null It stores mobile number.
Section Varchar(20) Not Null It stores teachers address.
43
Grade Varchar(5) Not Null It stores teachers sex or
gender
Examiner Varchar(20) Not Null Stores mirage status
Table Name: Discipline
Primary key: DId
Foreign key: StudId
Description: used to record all the information about discipline.
Field Name Data type Constraint Description
Did Int Primary key To stores disciplines id
StudId Int Foreign key To stores students id
StudentName Varchar(30) Not null Used to store students name
Date Date Not Null It stores first name.
Time Time Not Null It stores last name.
Case numeric(10) Not Null It stores mobile number.
Punishment Varchar(20) Not Null It stores teachers address.
Table Name: Resource
Primary key: RId
Foreign key:
Description: used to record all the information about resource.
Field Name Data type Constraint Description
Rid Int Primary key To stores resources id
ResourceName Varchar(30) Not Null To stores resource name.
44
Lname Varchar(30) Not Null Stores parent last name
Adders Varchar(30) Not Null Stores parent adders
Phone Int Not Null Stores parent phone number
Job type Varchar(30) Not Null Stores parent job type
Table Name: Employee
Primary key: EmpId
Foreign key:
Field Name Data Type Constraint Description
EmpId Int Primary key Stores committee id
Fname Varchar(30) Not Null Stores committee first name
Lname Varchar(30) Not Null Stores committee last name
Adders Varchar(30) Not Null Stores committee adders
Phone Int Not Null Stores committee phone
number
Job type Varchar(30) Not Null Stores committee job type
Table Name: mark
Primary key: marId
Foreign key: StudId, SubId
Field Name Data type constraint description
marId Int Primary key To store mark id
SubId Int Foreign key To stores subject id
StudId Int Foreign key To stores student id
StudentName varchar Not null To stores student name
Subject varchar Not null To store subject name
Test double Not null To stores test result
Assignment double Not null To stores assignment result
Exam double Not null To stores exam result
Total double Not null To stores total mark result
average double Not null To stores all marks average
Table 4.2: Data dictionary
Analysis level class diagram is conceptual modeling of the system, so it can described in figure
4.2 below.
45
class SMSClassDiagram
User
+ FirstName: S tring
+ LastName: S tring
+ MName: S tring
+ Age: int
+ Gender: S tring
Subject + Phone: int
+ Address: S tring
- SbjectId: int
+ UserName: S tring
- Subject Name: String
- password: S tring
+ AssignToTeacher(): boolean
asign + Register(): Void
Teach
+ Login(): Void
View
*
Admin
S tudent Parent Employee
- AdminId: int Teacher
- Field: S tring - EmpId: int
- BirthDay: int - Parent_ID: int
- Filed: S tring - Filed: S tring
1 + CreateAccount(): void - Grade: int - Jop: S tring 1
- Tr_ID: int
+ Manage(): void - S ection: S tring + ManageResource(): void
+ View(): boolean
+ ViewReport(): void + ManageGradeReport(): void + S tudId: int + GenerateReport(): void
+ Comment(): void Manage
+ RecordDiscipline() + RecordAttendance(): void
+ View(): boolean 1
Generate + view(): boolean 1
1 * Generate 1..*
1 * 1..*
View * 0..1 *
1..8 View Resource
Record 0..* Report
Record 1..
Prepare
+ Date: date
Timetable * 1..* - RcId: int
Discipline - item: double
Attendance - report_type: S tring
+ Name: S tring
- BreakTime: time + comment: S tring GradeReport + year: date
- att_id: int + Category: S tring
+ Date: date + Date: date + Date: date
+ day: S tring - Description: S tring - type: S tring
+ Day: S tring - Decision: S tring - Description: S tring
- Grade: int - GrId: int - status: S tring
- Description: S tring - DcId: int - Category: S tring
- S ection: int + Grade: int - RcId: int
- EndTime: time - Case: S tring - Name: S tring
+ S emester: S tring + Mark: int
+ Grade: int + S tudId: int - RpId: int + create(): void
- status: int + S ection: S tring view
+ Room: S tring + S tudentName: S tring + delete(): void
- studId: int + S emester: int + clear(): void
+ S ection: S tring - year: date + record(): void
+ S tudentName: S tring - S tudId: int + create(): void
- S tartTime: time + update(): void
+ Clear(): void + year: date + S tudentName: S tring + Delete(): void
+ S ubject: S tring
+ Delete(): void + S ubject: S tring 1 + generate(): void
- TT_Id: int + edit(): void
+ Tr_Id: int + Record(): void + Clear(): void
+ Record(): void
+ update(): void + Delete(): void
+ Add(): void + update(): void
A + Generate(): void
+ Delete(): void 1 1 + update(): void
+ Generate()
+ Update(): void View
1
Assign
Class
- RoomId: int
*
- Room: S tring 1
ExamS chedule
1..8 + AddClass()
- ES _ID: int
+ examiner: S tring
1 1..*
+ Add(): void
+ Delete(): void
+ Generate(): void
46
4.3. Dynamic Model
4.3.1. Sequence Diagram
Sequence diagram is emphasizing the time ordering of the message and emphasize the structural
organization of the object. They are helpful to identify the missing objects that are not identified
in the analysis object model.
Registration Sequence Diagram
The figure 4.3: below Sequence diagram used to how to register all users like students, teacher,
parent and Employee even Admin of the school.
sd Dynamic model
Admin
Registration<Link> Registration<Form> Registration<Controler> DataBase<DB>
ClickLink
(1)
HandleRequest
(3)
DisplayForm
(4)
FillForm(5)
ClickRegisterButton
(6)
RequestVerfication
(8)
Conform
(9)
verify
If Invalid (10)
(11)
I valid save
(12)
Success
(13)
feedback
(14)
47
Account Creation Sequence diagram
The figure 4.4 below show the step of how to create user account.
sd Dynamic Model
Admin
AccountLinck<UI> AccountForm<UI> Account<Controler> AccountDatabase<DB>
ClickLinck
(1)
HandleRequest
(2)
DisplayForm
(3)
FillForm
(4)
ClickCreate
(5)
HndleCreationRequest
(6)
Verify
(7)
Invalid
(8)
Save
(9)
Feedback
(10)
48
sd Dynamic Model
User
Login<Button> LoginForm<UI> LoginControler UserPage<UI> LoginDatabase
ClickButton
(1)
HandleRequest
(2)
AllowForm
(3)
FiillAccountInfo
(4)
ClickLogin
(5)
HandleLogin
(6)
Verify
(7)
InvalidInput
(8)
Validinput
(9)
Verify
(10)
InvalidAccount
(11)
DisplayUserHome
(12)
sd Dynamic Model
Teacher
Attendance<Button> AttendanceForm<UI> Attendance<Controler> Database<DB>
ClickButton
(1) HandleRequest
(2)
loop AllowForm
(3)
TickAttendance
(4)
HandleTick
(5)
Ticked
(6)
SaveAttendance
(7)
HandleSaving
(9)
Verify
(10)
Save
(11)
Successful
(12)
49
Timetable Sequence diagram
The figure 4.7 below describes how to add and generate timetable of the school.
sd Dynamic Model
Administor
TimeTableLinck<UI> TimetableForm<UI> Timetable<UI> Timetable<Controler> DataBase<DB>
Clicklinck
(1)
HandleRequest
(2)
loop
DisplayForm
(3)
FillForm
(4)
ClickAdd
(5)
HandleAdd
(6)
DisplayConformation
(7)
Conform Verify
(8) (9)
invalid
(10)
AddT oDB
(11)
Success
Successful (12)
(13)
ClearForm
(14)
ClickGenerate
(13)
HandleRequest
(14)
RequestQuery
(15)
Verify
(16)
Invalid_NoEntery
(17)
Query
(18)
DisplayOverview
(19)
Conformation
(20)
Confirm
(21)
GenerateT imetable
(22)
50
sd Dynamic Model
Admin
DisciplineRecordLink<UI> DisciplineRecordForm<UI> DisciplineRecord<Controler> Database<DB>
ClickLink
(1)
HandleRequest
(2)
DisplayForm
(3)
FillForm
(4)
Add
(5)
HandleForm
(6)
Verify
(7)
IfNotValid
(8)
IfValidConfirmationRequest
(9)
confirm
(10)
handleConformation
(11)
SaveTo
(12)
Verify
IfNotValidDB_error (13)
(14)
Success
(15)
Feedback
(16)
51
sd Dynamic Model
user
ReportLink<UI> ReportForm<UI> Report<UI> Report<controler> Databse<DB>
ClickLink
(1)
HandleRequest
(2)
DisplayForm
(3)
FillForm
(4)
Add
(5)
HandleForm
(6)
Verify
(6)
IfNotValid
(8)
ConformRequest
(9)
Confirm
(10)
HandleConformation
(11)
SaveTo
(12)
Verify
(13)
IfDB_Error
(14)
Success
(15)
Feedback
(16)
option
(17)
ClickGenerate
(18)
HandleGenerate
(16)
RequestQuery
(17)
Verify
(18)
IfDB_Error
(19)
Query
(20)
GenerateReport
(21)
52
sd Dynamic Model
Employee
ResourceLink<UI> ResourceForm<UI> Resource<Controler> DataBase<DB>
ClickLink
(1)
HandleRequest
(2)
DisplayForm
(3)
FillForm
(4)
Add
(5) HandleForm
(6)
ConfirmationRequest
(8)
confirm
(9)
HandleConfirmation
(10)
Verify()
Invalid()
SaveTo
(11)
Verify
(12)
DBError()
Success
(13)
FeedBack(14)
53
sd Dynamic Model
user
View Contents<Link> View Content<UI> View Content<Controler> DataBase<DB>
ClickLink
(1)
verify
(5)
DB_Error
(6)
Query
(7)
DisplayContents(8)
54
Grade Report
sd Dynamic Model
Teacher
GradeReportLink<UI> GradeReportForm<UI> GradeReport<UI> GradeReport<Controler> Database<Db>
ClickLink
(1)
HandleRequest
(2)
DisplayForm
(3)
FillForm
(4)
*ClickAdd
(5)
HandleAdd
(6)
REquestConfirmation
(7)
Confirm
(8)
HandleConfirmation
(9)
Verify
(10)
Not Valid
(11)
SaveToDataBase
(12)
Verify
(13)
If_Error
(14)
If_Success
(15)
Feedback
(16)
Option
(17)
Select&Click_Generate
(18)
HandleGenerate
(19)
RequestQuery
(20)
Query
(21)
Display Grade
Report(23)
55
4.3.2. Activity Diagram
Activity diagrams are flow diagrams used to represent the data flow or the control flow
through a system. The activity diagram show parallel behavior of the different event and
activities. Behavior in several use case iteration can be shown swim line between them.
Administrator side activity diagram
The figure 4.13 below describes how administrator perform his/her functionality such as creating
account, managing timetable, managing exam schedule, viewing reports and post notice.
Display error
message
Invalid
Click login link Fill Login Click logoin
form button Validation
Start
Valid
Admin home
Click Account
link Click click Registration Click Dicipline
Link
Timetable/Exam Link
Click Notice link
Schedule link
link
Valid
Timetable/Exam
Schedule Report viewed User
Discipline
Registered
Managed recorded
Logout
End
56
Teacher side activity diagram
The figure 4.14 below describes how teacher cares out their activities such as
recording attendance, preparing grade report and viewing notice, timetable and exam
schedule.
Displat error
message
Invalid
Valid
Teacher home
Fill Form
Select view
fill Attendance type
form
Invalid
Validate
Valid
Invalid
Attendance Validate
recorded
Valid
Mark added
Logout
End
57
Other user activity diagram
The figure 4.15 below activity diagram describes how student view time table, exam schedule,
grade report and notice, parent view student discipline, student grade reports and comment and
Employee manage resources and generate grade report.
Start
Valid
User Type
Content Viewed
Click comment Generate
button Add Update
Update Delete
Add
Comment
Attached
Report managed
REsource managed
Logout
END
58
4.3.3. State Diagrams
State are used to represent the behavior of nontrivial objects. A state chart diagram is a view of a
state machine that models the changing behavior of a state. State chart diagrams show the
various states that an object goes through, as well as the events that cause a transition from one
state to another.
The common model elements that state chart diagrams contain are:
States
Start and end states
Transitions
Entry, do, and exit actions
Registration state machine diagram
stm Dynamic M odel
Registration
Link
Oncl i ck
Registration
Form
FILL
Form
Register button
active
Oncl i ck button
Inval i d
Display Error
Is Val i d message
val i d
Registered
59
Account creation state machine diagram
stm Dynamic Model
Login Link
[Onclick link]
Login Form
[Fill Form]
login button
[Onclick button]
Is Display Error
Invalid
Valid?
Messege
Valid
DB
authentication
Not authenticated
Authenticated User home page
Display Error
Authentication
messege
60
Generate Timetable, Exam schedule, transcript and report
stm Dynamic M odel
Ge ne ra te Link
OnCl i ck
Form
Fi l l Form
Ge ne ra te Button
OnCl i ck Button
Val i d
Ge ne ra te d
End
Attendance
Linck
OnCl i ck
Attendance
Form
Check Box
Save Button
OnCl i ck button
Attendance
Recorded
61
Resource record state diagram
stm Dynamic M odel
Record
resource Link
Start
OnCl i ck
Rsource Form
Record Button
Val i d
Resource
recored
end
62
CHAPTER FIVE
5. System Design
Systems design is the process of defining the architecture, components, modules, interfaces,
and data for a system to satisfy specified requirements. Systems design could be seen as the
application of systems theory to product development. In the previous chapter, we have
identified the functional and non-functional requirements of the system and produced the
analysis model. The following are discussed in this chapter: design goals, system architecture,
Subsystem decomposition, deployment, database design and object mainly, others also included.
RSMS uses a client-server architecture; the back-end service is based around Microsoft
Xampp Server with some business logic handled by a custom PHP Framework module. The
client application is also built with, and handles almost all of the data manipulation and reporting
workload. SIMS is a modular application, the core offering covering storing basic school data
with modules available to handle (among other things) registration, the recording of
achievements and sanctions and the management and documentation of examinations scheduler.
Performance Criteria
Response time: The part of the system to be used for the record should have a fast response time
(real time) with maximum throughput.
63
Throughput: The system performs a number of tasks at given period of time do to efficient way
of design.
Memory: The system should not be taking up too much space in memory, about 2-4G memory is
enough to run the system.
Dependability criteria
The school needs the system to be highly dependable as it is expected to be used by non-IT
professionals. The system should be robust and fault tolerant. Furthermore, as the system is
handling sensitive data of the school, high emphasis should be given with regards to security, as
there are subsystems to be accessed through web.
Robustness: The system able to survive invalid user inputs such as character instead of number,
and case sensitive for upper cases and lower cases do to validation design.
Security: System use backup by using additional database server do to maybe system crash and
virus attacks.
Fault tolerance: If the system cased error it gives warring message to shows error that may
affect execution of program. This indicates the system not crash if it had an error.
Maintenance criteria
The system should be easily extensible to add new functionalities at a later stage. It should also
be easily modifiable to make changes to the features and functionalities.
Extensibility: The system is easy to add functionality and new class of the system do to easily
way of coding.
Modifiability: As the system coded with considering understandability of the system the
functionality of the system easily modified.
Readability: In the code system developed by putting comments on each lines, so easy to
understand.
64
End User Criteria
Usability: Usability is the extent to which a product can be used by specified users to achieve
specified goals with effectiveness, efficiency and satisfaction in a specified context of use. From
the end users’ perspective, the system should be designed in such a way that it is easy to learn
and use, efficient and having few errors if any.
Reusability Vs Usability: The RSMS will be able to use some or all the aspects of the
preexisting system modules in other projects with little to no modification. The system have
better user interface so it’s more usable for its target user. Default values for the parameters must
be chosen so that they are a good choice for the majority of the users.
Functionality Vs Scalability: The RSMS adapts well to increasing data or number of users
with handling such functionality that is easy to learn and operate. The User interface for this
system will be simple and clear. RSMS system is easy to use i.e. it doesn’t require special
training.
Performance Vs Portability: The system should have good performance i.e. fast response
time. In portability, the system should be machine independent so it can be moved different plat
forms.
65
Security Vs Usability: There is strong user name and password in order to secure the system.
It is designed to be secure login feature which authenticates the user by means of a user name
and password with which user will be able to login to his/her respective pages and use the system
as required without affecting the usability of the system which interrupts users feeling to the
system.
The data tier maintains the applications data such as student data, teacher data, timetable data
etc. It stores these data in a relational database management system (RDBMS).
The middle tier (web/application server) implements the business logic, controller logic and
presentation logic to control the interaction between the application’s clients and data. The
controller logic processes client requests such as requests to view student’s result, to record
attendance or to retrieve data from the database. Business rules enforced by the business logic
dictate how clients can and cannot access application data and how applications process data.
A web server is a program that runs on a network server (computer) to respond to HTTP
requests. The most commonly used web servers are Internet Information Server (IIS) and
Apache. The web server used in this system is IIS. HTTP is used to transfer data across an
Intranet or the Internet. It is the standard protocol for moving data across the internet.
The client tier is the applications user interface containing data entry forms and client side
applications. It displays data to the user. Users interact directly with the application through user
interface. The client tier interacts with the web/application server to make requests and to
retrieve data from the database. It then displays to the user the data retrieved from the server.
66
Request/Response
HTTP
Request/Response
Transaction
67
5.4. Subsystem Decomposition
A subsystem decomposition, the activity of identifying subsystems, their services, and their
relationships to each other. Subsystem decompositions will help reduce the complexity of the
system. The subsystems can be considered as packages holding related classes/objects. The
RSMS under consideration is decomposed into subsystems as shown in figure 5.2. These
subsystems are further decomposed into other subsystems. The major subsystems identified as
following. Users also classified in to the following roles.
Account subsystem: it holds every users account to authenticate them. Contain the following
components
Login: authenticates a user to grant access based on the role of the user.
Logout: exit and stay out the user from the system.
Registration subsystem: subsystem optimization of student’s others registration to any subjects
available. In this part, all information related to student’s necessary for registration will fetched.
This information is not limited to Student profile information, it also included parent
information, and addresses information, academic, teacher’s information, admin information,
other staff’s information and emergency person. Contain the following components
68
Manage attendance: teacher controls student attendance status
Report: subsystem generates reports to parents, students and teachers to facilitate viewing
students’ status and course achievement online or may be discipline report from discipline
committee to view students discipline case. It has the following components
Manage resource: resource manager controls every new, used and outdated resources.
Participant subsystem: used to control an information of every user and describe their
relationship with another subsystem. Contain the following components
Student Information System: this is for students, after login they can view all their profile
information, manipulate their information subject details and ID.
Teacher: this is for teachers, after login they can view all their profile information, manage
student grade information, subject details and attendance.
Employee: this is for other staffs, after login they can view all their profile information, manage
resource.
Parent: this is for parent, after login they can view all their profile information, view students
information details and grade.
Notice: it is one of the sub system that administrator creates and post it, other users view the
notice like students, teacher, and parent.
69
Report Substem View Subsystem
Grade
report
Generate view
report report access
Extend Exam
Timetable
schedule
Registeration
Subsystem Account Resourc Discipli
subsystem e ne
Admin
Extend Extend Login Logout Manage Manage
resource discipline
Register Manage
user user
lo
gi
n
Attendance Participants
subsytem
Student Employee
Manage Veiw status
attendance teachs
70
Application Server
Registration
Account
Login
Attendance
Data Base Server
Client Computer
Timetable
Exam
Web Schedule Data Base
Browser
HTTP MYSQL
Notice
Resource
Chrome,
Mozilla Firefox
Report
Discipline
Grade Report
Student Data
71
User<<Table>>
UId<<primary Admin<<Table>>
key>>
FirstName
MName AdminId<Primary key>
LastName UId<Foreign key>
Age
Gender Field
Phone
Address
Username
Password
Student<<Table>>
Parent<<Table>>
Teacher<<Table>>
StudId<primary key>
Parent_ID<primary
TR_ID<primary key> key>
UI<foreign key>
UId<foreign key>
UId<Foreign key>
Grade
Job
field
Section
Birthday
Employee<<Table>>
Resource<<Table>>
Class<<Table>>
EmpId<primary key>
RcId<primary key> RoomId<primary
UId<foreign key> key>
item StuId<foreign key>
Field
Name Room
Category
type
status
date
Attendance<<Table>>
GradeReport<<Table>>
att_id<primary key>
GrId<primary key>
StudId<foreign key>
StudId<foreign key>
Grade Semester
Section Grade
Semester Section
Status Subject
StudentName mark
StudentName
Year
Description
72
Menus: links or buttons that help user what they want to preforms. Each menus depends on user
home page except main home page which is common for all users. For example in admin home
page account, login, view, timetable, notice and exam schedule links found, in record officer
home page registration, report, discipline, student information and grade report links found and
so on.
Contents: Form, displays and any system response messages are displayed here.
News: here some information are displayed such as about system, about the school such as
mission, aims and backgrounds of school and images.
Footer: some notifications such as open windows, performance issues, right copy of the system.
LOGO
About
User Name
Contact
Password
User Type
Login Reset
Forget password
Footer
73
LOGO
Home Contents
Menus
Footer
Variables
Variable names should be descriptive and indicative of the variable’s use. For multiword
variables, the following notation will be used; the first letter of each word will be capitalized
if the variable contains multiple words except first word.
74
Examples:
integer stuId, age,phone;
Classes
All classes are named with singular nouns or noun phrases, and the first letter of each word
should be capitalized.
Methods
All methods are named with verb phrases, and the first letter of each word should becapitalized
except first word.
Example:CreateAcount(), Register()
Exception
When error occurs, the application will display an appropriate error message to the userand then
allow the user to terminate the application or close the error message andproceed with the
application.
Various Notes
Forms, textboxes, command buttons, labels and so forth that are used for the interface will be
assigned names according to standard and conventional Notation.
Database
Database fields are data base name, table name ant attributes that can be named using noun
phrases.
75
5.8.2. Class interfaces
The class interface describes the content of the class such as class name, methods, attributes,
parameters, data type, and visibility and so on. It can be described in the table 5.1 below.
Class Methods and Attributes
class SMSClassDiagram Attributes
+FirstName: public, string and it contains first name of the user
User +Mnane: public, string and it contains middle name of the user
+ FirstName: String +LastName: public, string and it contains last name of the user
+ LastName: String +Age: public, int and it contains age of the user
+ MName: String
+Gender: public, string and it contains gender type of the user
+ Age: int
+ Gender: String +phone: public, int and it contains phone number of the user
+ Phone: int +Address: public, string and it contains address of the user
+ Address: String -UId: private, int and it contains user id of the user
- UId: int -password: private, string and it contains password of user
+ UserName: String
- password: String
-username: public, string and contains username of users
Methods
+ Register(): Void
+ Login(): Void +Login(): void, public and enable user to login to system
Precondition: the user should enter valid user name and password.
Postcondition: system validates and user logged in
+Register(): public, void and enable user to register user information
Precondition: user should be eligible
Postcondition: system verifies and stores in to database user information
class SMSClassDiagram
Attributes
Admin
-field: private, string and it contains administrator department field
- AdminId: int -AdminId: private, int and it contains administrator id
- Field: S tring
+ CreateAccount(): void Methods
+ Manage(): void
+ ViewReport(): void +CreatAccount (): void, public and it enables admin to create account for
+ RecordDiscipline()
the user
Precondition: The users first should be registered
Post condition: The users get an account to login to system
+Manage (): public, void and enables Admin to manages user informations
Precondition: Admin should have user data in the system to manage
Post condition: data managed
class SMSClassDiagram Attributes
-GrId: private, int and it contains student grade report id
GradeReport -studId: private, int and it contains student id
-Grade: public, int and it contains student grade level
- Description: String
- GrId: int
-studentname: public, string and it contains student name
+ Grade: int -section: public, string and it contains student section or room
+ Mark: int -semester: public, string and it contains semester grade report
+ Section: String -year: public, int and it contains year of grade report
+ Semester: int
- StudId: int 76
+ StudentName: String
+ Subject: String
+ Clear(): void
+ Delete(): void
Methods
+Generate(): public, void and enables teacher to generate grade report
Precondition: teacher should collect mark via assignment, test, quiz and
exam then calculate it.
Post condition: student grade report generated.
+Clear (): public, void and enables teacher to clears form during filling
Precondition: if an error attributes may be happening when form filling
Post condition: teacher clicks clear button then existing form has been
cleared
+Update (): public, void and enables teacher to update student mark.
Precondition: teacher needs to upgrade previous mark then there should be
existing mark attributes
Post condition: student marks are updated
Attributes
-item: private, boolean and it contains item of the resource
-type: private, string and it contains types of the resource
+name: public, string and it contains name of the resource
+category: public, string and contains category of the resource
+date: public, int and contains the date of the resource
-status: private, string and it contains the status of the resource
-RcId: private, int and it contains id of the resource
Methods
+Record (): public, void and enables employee to record resource data
Precondition: employee collects and checks available resources then record
and save resources into database
Post condition: resource recorded in database
+Update (): public, void and enables user to update recorded resource
Precondition: the database must have recorded data to update
Postcondition: recorded resource updated with new record
+Delete (): public, void and enable user to delete recorded data from
database
Precondition: the database must have recorded data to delete
Postcondition: employee deleted recorded data
class SMSClassDiagram
Attributes
Teacher -TrId: private, int and it contains teacher id
-
-
Filed: String
Tr_ID: int -field: private, string and it contains department field of the teacher
+ ManageGradeReport(): void
+ RecordAttendance(): void
+ view(): boolean
Methods
+ManageGradeReport(): public, int and enable teacher to manage student
grade report.
Precondition: teacher should be collect all student marks and calculate it
Post condition: student grade report generated
77
+RecordAttendance(), public, void and enables teacher to record student
attendance
Per condition: teacher should checks the student attendance
Post condition: student attendance recorded
+view(): public, boolean and enables teacher to view notice, timetable
class SMSClassDiagram Attributes
+StudId: public, int and it contains student id
Student
-Grade: private, int and it contains student grade level
- BirthDay: int
- Grade: int
-Sction: private, string and it contains student section or room
- Section: String -Birthday: private, string and it contains student birthday
+ StudId: int
Methods
+ View(): boolean
+view(): public, boolean and enables students to view timetable, exam
schedule, grade report, notice and discipline
class SMSClassDiagram
Attributes
Parent
-Parent_ID: private, int and it contains parent id
- Parent_ID: int
-Jop: private, string and it stores parents job type
- Jop: S tring
+ View(): boolean
Methods
+ Comment(): void +view(): public, void and enables parent to view their student information
+comment(): public, void and enables parent to give comment on student
information
Precondition: parent should fill comment field
Post condition: comment is submitted on student
class SMSClassDiagram
Attributes
Employee
EmpId: private, int and it contains employee id
- EmpId: int Field: private, string and it contains employee’s department field
- Filed: String
+ ManageResource(): void
Methods
+ GenerateReport(): void +ManageResource(): public, void and enables employee to manage
resources
Per condition: employee should record all recorce information first
Post condition: resource managed
+generateReport(): public, void and enables employee to generate resource
reports.
per condition: resource should be managed first
Post condition: report is generated
Table 5.1: class interface
78
Appendix
Appendix 1.1 Student registration form
79
Appendix 1.2 Report form
80
Appendix 1.3: Attendance form
81
Appendix 1.4: Grade report
82
References
1. E. Burke and W. Erben. Practice and Theory of Automated Timetabling, Third International
Conference, Germany, Springer Private Limited, August 2000
2. J. G. Hedberg et. al. (1992). Educational information systems: Problems of the small
educational organisation. Australian Journal of Educational Technology, 8(2), 132-160.
3. Mr. Kean Tak, MSc, Lecturer and IT Project Management, School management system
4. Degif Teka, School of Graduate Studies of Addis Ababa University, Degree of Master of
Science in Computer Science, School management system, June 2008
83