You are on page 1of 108

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF INFORMATION SYSTEMS


PROJECT TITLE: - SCIENCE TECHNOLOGY ENGINEERING AND
MATHEMATICS (STEM) MANAGEMENT SYSTEM FOR
WOLKITE UNIVERSITY

STUDENTS NAME ID NUMBER

1. GIRUM NIGUSSE CIR/149/09

2. ALEHGN MELKIE CIR/030/09

3. ESUBALEWU ASCHALEW CIR/123/09

4. ABUBEKER ABDI CIR/018/09

ADVISOR: - MR. ISSAYAS W.

WOLKITE UNIVERSITY, WOLKITE, ETHIOPIA

JANUARY 4, 2021
WOLKITE UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF INFORMATION SYSTEMS

PROJECT TITLE: - SCIENCE, TECHNOLOGY, ENGINEERING


AND MATHEMATICS (STEM) MANAGEMENT SYSTEM FOR
WOLKITE UNIVERSITY

SUBMITED TO DEPARTMENT OF INFORMATION SYSTEMS IN PARTIAL


FULFILMENT OF THE REQUIREMENT FOR THE DEGREE OF BACHLER
OF SCIENCE IN INFORMATION SYSTEMS PREPARED BY:

STUDENTS NAME ID NUMBER

1. GIRUM NIGUSSE CIR/149/09

2. ALEHGN MELKIE CIR/030/09

3. ESUBALEWU ASCHALEW CIR/123/09

4. ABUBEKER ABDI CIR/018/09

ADVISOR: - ISSAYAS W.

WOLKITE UNIVERSITY, WOLKITE, ETHIOPIA

JANUARY 4, 2021
DECLARATION
This is to declare that this project work which is done under the supervision of Mr. ISSAYAS W.
and having the title SCIENCE, TECHNOLOGY, ENGINEERING AND MATHEMATICS
(STEM) MANAGEMENT SYSTEM is the sole contribution of: Girum Nigusse, Alehegn
Melkie, Esubalew Aschale and Abubeker Abdi. No part of the project work has been
reproduced illegally (copy and paste) which can be considered as Plagiarism. All referenced
parts have been used to argue the idea and have been cited properly. We will be responsible and
liable for any consequence if violation of this declaration is proven.

Date: _____________________

Group Members:

Full Name Signature

1. Girum Nigusse ____________________

2. Alehegn Melkie ____________________

3. Esubalew Aschale ____________________

4. Abubeker Abdi ____________________

i
APPROVAL FORM
This is to confirm that the project report entitled Science Technology Engineering and
Mathematics (STEM) MANAGEMENT SYSTEM submitted to Wolkite University, College of
Computing and Informatics Department of Information systems by: Girum Nigusse, Alehegn
Melkie, Esubalew Aschale and Abubeker Abdi are approved for submission.

Advisor Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Department Head Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Examiner 1 Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Examiner 2 Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Examiner 3 Name Signature Date

------------------------------------------------- ------------------------------ -------------------

ii
ACKNOWLEDGMENT
First of all, our gratitude thanks to God for help us in this project starting from the beginning up
to now. Secondly, we would like to express our deepest gratitude to our Adviser Mr. Issayas W.
for his advice and constrictive commit in our project and also, we would like to thanks our
College of Computing and Informatics college for giving as this chance to do this final project.
We would also like to thank to Wolkite University Community Service Director for his
willingness for any interview and give us different forms and documents that help us to the
achievement of the project. Finally, we would like to thanks our friends for their support and best
wish.

iii
TABLE OF CONTENTS

Table of Contents
DECLARATION..........................................................................................................................................i
APPROVAL FORM....................................................................................................................................ii
ACKNOWLEDGMENT............................................................................................................................iii
TABLE OF CONTENTS............................................................................................................................iv
LISTS OF FIGURES.................................................................................................................................vii
LISTS OF TABLES..................................................................................................................................viii
LIST OF ABBREVIATIONS.....................................................................................................................ix
ABSTRACT................................................................................................................................................x
CHAPTER ONE..........................................................................................................................................1
1. Introduction.........................................................................................................................................1
1.1 Background of the organization...................................................................................................1
1.2 Statement of the problem.............................................................................................................2
1.3 Objective of the project................................................................................................................3
1.3.1 General objective.................................................................................................................3
1.3.2 Specific objective.................................................................................................................3
1.4 Feasibility study...........................................................................................................................3
1.4.1 Technical feasibility.............................................................................................................3
1.4.2 Operational feasibility..........................................................................................................4
1.4.3 Economic feasibility............................................................................................................4
1.4.4 Schedule feasibility..............................................................................................................4
1.5 Scope and limitation of the project..............................................................................................5
1.5.1 Scope of the project.............................................................................................................5
1.5.2 Limitation of the project......................................................................................................5
1.6 Significance of the project...........................................................................................................5
1.7 Beneficiary of the project............................................................................................................6
1.8 Methodology of the project..........................................................................................................7
1.8.1 Data collection tools and techniques....................................................................................7
1.8.2 System analysis and design..................................................................................................7
1.8.3 System development model.................................................................................................8
1.8.4 Development tools and technologies....................................................................................8
1.9 Document organization................................................................................................................9

iv
CHAPTER TWO.......................................................................................................................................10
2. DESCRIPTION OF THE EXISTING SYSTEM...............................................................................10
2.1 Introduction of the existing system............................................................................................10
2.2 User of the existing system........................................................................................................10
2.3 Major function of the existing system........................................................................................11
2.4 Forms and Other Documents of the Existing Systems (if any)..................................................12
2.5 Drawback of the existing system...............................................................................................17
2.6 Business rule of the existing system..........................................................................................18
CHAPTER THREE...................................................................................................................................19
3. PROPOSED SYSTEM......................................................................................................................19
3.1 Functional Requirements...........................................................................................................19
3.2 Non-Functional Requirements...................................................................................................20
3.2.1 User Interface and Human Factors.....................................................................................20
3.2.2 Hardware Consideration....................................................................................................21
3.2.3 Security Issues...................................................................................................................21
3.2.4 Performance Consideration................................................................................................22
3.2.5 Error Handling and Validation...........................................................................................22
3.2.7 Physical Environment........................................................................................................23
3.2.8 Resource Issues..................................................................................................................23
3.2.9 Documentation...................................................................................................................23
CHAPTER FOUR.....................................................................................................................................24
4 SYSTEM ANALYSIS.......................................................................................................................24
4.2 System Model............................................................................................................................24
4.2.5 Use Case Model.................................................................................................................24
4.3 Object model.............................................................................................................................40
4.3.5 Class Diagram....................................................................................................................40
4.3.6 Data Dictionary..................................................................................................................42
4.4 Dynamic model..........................................................................................................................45
4.4.5 Sequence Diagram.............................................................................................................45
4.4.6 Activity Diagram...............................................................................................................55
4.4.7 State Chart Diagram...........................................................................................................62
CHAPTER – FIVE....................................................................................................................................67
5 SYSTEM DESIGN............................................................................................................................67

v
5.2 Design Goals.............................................................................................................................67
5.2.5 Performance.......................................................................................................................67
5.2.6 Dependability.....................................................................................................................67
5.2.7 Maintenance.......................................................................................................................67
5.2.8 End user.............................................................................................................................68
5.2.9 Security requirement..........................................................................................................68
5.3 Proposed System Architecture...................................................................................................68
5.3.5 Subsystem Decomposition and Description.......................................................................70
5.3.6 Hardware/Software Mapping.............................................................................................73
5.3.7 Detailed Class Diagram.....................................................................................................74
5.3.8 Persistence Data Management...........................................................................................75
5.3.9 Access Control and Security..............................................................................................76
5.4 Packages....................................................................................................................................77
5.5 Algorithm Design......................................................................................................................78
5.6 User Interface Design................................................................................................................79
CHAPTER - SIX.......................................................................................................................................81
6 IMPLEMENTATION AND TESTING.............................................................................................81
6.2 Implementation of the Database................................................................................................81
6.3 Implementation of Class Diagram.............................................................................................83
6.4 Configuration of Application Server..........................................................................................84
6.5 Configuration of Application Security.......................................................................................84
6.6 Implementation of User Interface..............................................................................................88
6.7 Testing.......................................................................................................................................89
6.7.5 Testing Tools and Environment.........................................................................................90
6.7.6 Unit Testing.......................................................................................................................90
6.7.7 Integration Testing.............................................................................................................91
CHAPTER – SEVEN................................................................................................................................92
7 CONCLUSION AND RECOMMENDATION.................................................................................92
7.2 Conclusion.................................................................................................................................92
7.3 Recommendation.......................................................................................................................92
Bibliography..............................................................................................................................................93

vi
LISTS OF FIGURES
FIGURE 2-1 INSTRUCTOR REQUEST TO THE COLLEGE COMMUNITY SERVICE DIRECTOR..............................13
FIGURE 2-2 RESPONSE LISTS OF INSTRUCTORS TO THE DIRECTOR...............................................................14
FIGURE 2-3 STUDENT SATISFACTION FORM.................................................................................................15
FIGURE 2-4 PREPARATION OF CLASS SCHEDULE..........................................................................................16
FIGURE 2-5 REPORT GENERATION FORM.....................................................................................................17
FIGURE 4-1 USE CASE DIAGRAM..................................................................................................................27
FIGURE 4-2 CONCEPTUAL CLASS DIAGRAM.................................................................................................41
FIGURE 4-3 SEQUENCE DIAGRAM FOR LOGIN..............................................................................................46
FIGURE 4-4 SEQUENCE DIAGRAM FOR ADD USER........................................................................................47
FIGURE 4-5 SEQUENCE DIAGRAM FOR UPDATE USER..................................................................................48
FIGURE 4-6 SEQUENCE DIAGRAM FOR DELETE USER...................................................................................49
FIGURE 4-7 SEQUENCE DIAGRAM FOR VIEW USER......................................................................................50
FIGURE 4-8 SEQUENCE DIAGRAM FOR UPLOAD MATERIAL.........................................................................51
FIGURE 4-9 SEQUENCE DIAGRAM FOR DOWNLOAD MATERIAL....................................................................52
FIGURE 4-10 SEQUENCE DIAGRAM FOR GENERATE CLASS SCHEDULE.......................................................53
FIGURE 4-11 SEQUENCE DIAGRAM FOR GENERATE DORM PLACEMENT.....................................................54
FIGURE 4-12 ACTIVITY DIAGRAM FOR LOGIN..............................................................................................55
FIGURE 4-13 ACTIVITY DIAGRAM FOR UPLOAD MATERIAL.........................................................................56
FIGURE 4-14 ACTIVITY DIAGRAM FOR DOWNLOAD MATERIAL...................................................................57
FIGURE 4-15 ACTIVITY DIAGRAM FOR MANAGE ACCOUNT.........................................................................58
FIGURE 4-16 ACTIVITY DIAGRAM FOR MANAGE USER................................................................................59
FIGURE 4-17 ACTIVITY DIAGRAM FOR GENERATE CLASS SCHEDULE..........................................................60
FIGURE 4-18 ACTIVITY DIAGRAM FOR GENERATE DORM PLACEMENT......................................................61
FIGURE 4-19 STATE CHART DIAGRAM FOR LOGIN......................................................................................62
FIGURE 4-20 STATE CHART DIAGRAM FOR UPLOAD MATERIAL.................................................................63
FIGURE 4-21 STATE CHART DIAGRAM FOR UPLOAD MATERIAL.................................................................64
FIGURE 4-22 STATE CHART DIAGRAM FOR MANAGE ACCOUNT.................................................................65
FIGURE 4-23 STATE CHART DIAGRAM FOR MANAGE USER........................................................................66
FIGURE 5-1 PROPOSED SYSTEM ARCHITECTURE..........................................................................................69
FIGURE 5-2 SUBSYSTEM DECOMPOSITION DIAGRAM...................................................................................72
FIGURE 5-3 DEPLOYMENT DIAGRAM...........................................................................................................73
FIGURE 5-4 DETAILED CLASS DIAGRAM.....................................................................................................74
FIGURE 5-5 PERSISTENCE DIAGRAM.............................................................................................................75
FIGURE 5-6 PACKAGE DIAGRAM..................................................................................................................77
FIGURE 5-7 USER INTERFACE FOR LOGIN.....................................................................................................79
FIGURE 5-8 USER INTERFACE FOR ADMINISTRATOR HOME PAGE................................................................80

LISTS OF TABLE
vii
TABLE 2-1 BUSINESS RULE OF THE EXISTING SYSTEM. 18
TABLE 4-1 USE CASE DESCRIPTION FOR LOGIN 27
TABLE 4-2 USE CASE DESCRIPTION FOR MANAGE ACCOUNT 29
TABLE 4-3 USE CASE DESCRIPTION FOR MANAGER USER 31
TABLE 4-4 USE CASE DESCRIPTION FOR SELECT INSTRUCTOR 32
TABLE 4-5 USE CASE DESCRIPTION FOR GENERATE CLASS SCHEDULE 33
TABLE 4-6 USE CASE DESCRIPTION FOR SEND REQUEST 34
TABLE 4-7 USE CASE DESCRIPTION FOR GENERATE DORM PLACEMENT 35
TABLE 4-8 USE CASE DESCRIPTION FOR UPLOAD MATERIAL 36
TABLE 4-9 USE CASE DESCRIPTION FOR DOWNLOAD MATERIAL 37
TABLE 4-10 USE CASE DESCRIPTION FOR SEND SMS MESSAGE 38
TABLE 4-11 DATA DICTIONARY FOR STUDENT TABLE 42
TABLE 4-12 DATA DICTIONARY FOR INSTRUCTOR TABLE 43
TABLE 4-13 DATA DICTIONARY FOR ACCOUNT TABLE 43
TABLE 4-14 DATA DICTIONARY FOR COURSE TABLE 44
TABLE 4-15 DATA DICTIONARY FOR ROOM TABLE 44
TABLE 4-16 DATA DICTIONARY FOR DEPARTMENT TABLE 44
TABLE 4-17 DATA DICTIONARY FOR BUILDING TABLE 45
TABLE 4-18 DATA DICTIONARY FOR COLLEGE TABLE 45

viii
LIST OF ABBREVIATIONS
ADMIN--------------------------------------Administrator
BR---------------------------------------------Business Rule
COLLEGE DIRECTOR----------------- College Community service Coordinator.
CSS--------------------------------------------Cascade style Sheet
DB----------------------------------------------Database
GUI--------------------------------------------Graphical User Interface
HTML-----------------------------------------Hyper Text Markup Language
HTTP------------------------------------------Hypertext Transfer Protocol
ID-----------------------------------------------Identification
MySQL----------------------------------------Relational database management
OOSAD----------------------------------------Object Oriented System Analysis Design
PC-----------------------------------------------Personal Computer (Client Computer)
PHP---------------------------------------------Hypertext Preprocessor
STEM-------------------------------------------Science, Technology, Engineering and Mathematics
UI------------------------------------------------User Interface
UNIVERSITY DIRECTOR----------------Community service director of university
UML---------------------------------------------Unified Modeling Language
WKU--------------------------------------------Wolkite University
XAMPP-----------------------------------------Platform apache MySQL Perl PHP

ABSTRACT

ix
Science, Technology, Engineering and Mathematics (STEM) is a curriculum offered for students
selected from different school of Gurage zone, Silte zone and Yem wereda and those students are
selected from grade 8th - 12th. and in the STEM, there are many problems like registering
students, preparation of dorm placement and preparation of class scheduling those problems lead
us to propose new system that solves the above problem. The main objective of the project is to
develop web-based STEM management system for wolkite university. The implementation will
be developed by using HTML, CSS, BOOTSTRAP, PHP, JAVASCRIPT, APACHE Server, and
MYSQL database and also, we use different data gathering techniques. The newly proposed
system provide for user is easy in registering students online, generating dorm placement and
generating class schedule.

CHAPTER ONE

1. Introduction
Science Technology Engineering and Mathematics (STEM) is a curriculum based on the idea
of educating students in four specific disciplines - science, technology, engineering and
mathematics in an interdisciplinary and applied approach. Rather than teach the four

x
disciplines as separate and discrete subjects, STEM integrates them into a cohesive learning
paradigm based on real-world applications [CITATION Ela14 \l 1033 ].
STEM start in Ethiopia with the moto of “Inside every child is a scientist.” And STEM is the
younger organization in Ethiopia that is proposed for the students who are talented and
skilled for science, technology, engineering and mathematics all around the country. It helps
us to lead in innovation and technology for the growth of our country. Nowadays, this center
is highly initiated by the government to upgrade our country to the next level. So students
within the country are getting training in STEM program to expand their knowledge and
solve the problems. Currently students who are in the range of grade 7-12 can participate in
the STEM program based on their result on their grades [ CITATION Hom18 \l 1033 ].
STEM is one of the services of wolkite university community service and this program helps
different students selected from different schools of Gurage zone, Silti zone and Yem special
woreda by teaching them about science, technology, engineering and mathematics the
university can helps them to gain knowledge about the current technology and makes them
creators, thinkers, problem solvers and innovators. This program helps the university
competitive to other universities and helps to fulfill the vision and mission of the university
[ CITATION Res18 \l 1033 ].

1.1 Background of the organization


Wolkite University (WKU) is one of the third-generation higher institutions that have been
founded in 2004 E.C. The University is located in the Southern Nation Nationalities Regional
State, in Gurage zone, 170 km southwest of the capital city, Addis Ababa, on the way to
Jimma. In November 2001 E.C the late Prime Minister, his Excellency Mr. Meles Zenawi,
laid the foundation stone of the University in a plain landscape which is quite ideal for
academic pursuit. It is situated at Gubre sub-city, 15 km away from Wolkite town, of the
Gubre-butajira road. Now a day the university has almost 7 colleges and 42 departments. And
as higher education institution besides of teaching learning participating on research, projects
and community services on the major identified prioritize problem areas are the concern of
universities [ CITATION Abo18 \l 1033 ].
After the foundation of the university in 2007 E.C (2015 G.C) STEM program is start given to
the students of Gurage zone, Silti zone and Yem special woreda. This program helps the

xi
community services of Wolkite University to achieve their mission and vision[ CITATION Res18
\l 1033 ].

1.2 Statement of the problem


In STEM there are many tasks done and this task include the community service of wolkite
university inform different directors of the schools of Gurage zone by sending letters and the
school directors resend the letter back to the university that contain the list of selected
students. The university wants this work done efficiently and quickly so this reduces human
power to perform the entire task done in the STEM.
However, the task is done in the STEM is manual based and, in this case, there are many
problems which are:
 Telling for all directors of the schools of Gurage zone to select and send their talented
and skilled students to the university.
 Registering students selected from different schools of Gurage zone.
 Assigning dorm for the selected students according to their genders.
 Preparing class schedule without clash of class is difficult.
 Select instructor from different departments.
 Generate report.

Those all problems make an inefficient use of the university’s time, resources and human
power. Using automated system community services office can eliminates the above-
mentioned problem and makes the university competitive with other university.

1.3 Objective of the project

1.3.1 General objective


The general objective of this project is to develop a web-based STEM student
management system for Wolkite University which solves the above-mentioned problem.

1.3.2 Specific objective


To accomplish the general objective, we could have the following specific objectives. Our
specific objectives are: -
 Identifying all problems of the existing system.

xii
 Collecting different information to identify all functionalities of the proposed
system.
 Analyzing the collected data through different techniques.
 Designing of the proposed system based on the development requirement of the
university infrastructure.
 Implementation of the proposed system based on the design.
 Testing of the developed system through different techniques before delivery.

1.4 Feasibility study

1.4.1 Technical feasibility


In technical feasibility study, one has to test whether the proposed system can be
developed using existing technology or not. It is planned to implement the proposed
system using Windows operating systems, web-based applications. It is evident that the
necessary hardware and software are available for the development and implementation of
the proposed system. So, the system will technically feasible. The assessment is based on
an outline design of system requirements, to determine whether the office has the technical
expertise to handle the new system. The Organization (Wolkite University) already
possesses Windows products Operating System. So, the solution is technically feasible.

1.4.2 Operational feasibility


Operational feasibility is a measure of how well a proposed system solves the problems,
and takes advantage of the opportunities identified during scope definitions. Our system
will provide a way of accepting different input from the users of the system, process the
given input and return appropriate output and make the satisfied so our system is
operationally feasible. The proposed system that we will develop provides accurate, active,
secure service and decreases labor of workers, Since the system is web-based application. It
is platform independent which indicates that the system will be operationally feasible.

1.4.3 Economic feasibility


Economic analysis is the most frequently used method for evaluating the effectiveness of a
new system. It is the first to be considered when we are going to develop the project. Since
the system will not need special requirements like standalone server, additional cost

xiii
incurred for tools and large cost for system development process the system will be
economically feasible. Generally, the system that we will develop has a number of tangible
and intangible benefits.
 Tangible benefits
▪ Cost reduction.
▪ Error reduction.
▪ Increase speed of activities and minimize workload.
 Intangible benefit
▪ Reduce resource consumptions
▪ Increase security
▪ Increase employee satisfaction.
▪ Increase management flexibility

1.4.4 Schedule feasibility


Schedule feasibility means that project can be implemented in an acceptable time frame or
the probability of a project will complete within its scheduled time limits, by a planned due
date. So, the project will accomplish and deliver within the given time. Since the project
contains the documentation parts (SRS, testing and maintenance). And also, the technology
we used to develop the system is known and there is a work division in our group. Due to
this reason the team will deliver based on the given time scope.

1.5 Scope and limitation of the project

1.5.1 Scope of the project


Our system concerned on Wolkite University STEM management system. The proposed
system will enhance the efficiency and effectiveness of the STEM program.
The scope of proposed system will focus on:
 Manage students (register, update, delete and view their information).
 Manage instructors (register, update, delete and view their information).
 Generate report about students and instructors.
 Manage accounts (create, update, delete and view).
 Generate class schedule.
 Assign dorm for the students according to their gender.
xiv
 Allow instructors, students and school directors to manage feedback (give and
read).
 Notify the students through Short Message Service (SMS) by using trial version of
API.

1.5.2 Limitation of the project


In our project there are some limitations.

 The interface which is the frontend it works only by English.

1.6 Significance of the project


The newly proposed system will have many advantages in terms of students, instructor, school
director and the university community service in the following ways:
 To enable the university to get acceptance in the outside community.
 Reduce wastage of time, cost of the user of the system.
 Reduce wastage of time and resource due to preparation of class scheduling.
 Reduce wastage of time and resource due to dorm placement.
 Increase user’s satisfaction in need to spend less amount of time on performing their
task.
 Improving availability and security of existing system.
 Helps students and instructors to access information online.
 Reduce the work load of the university by distributing to the school directors.
 Helps the students to read different materials online.

1.7 Beneficiary of the project


Student:
 Can register online.
 Know dorm (block and room).
 After they came to the university, they can see class schedule online.
 Can see and download uploaded materials (lab tutorial, books, handout and any other
material).
 Receive SMS message from their school director.
University director:
xv
 Registering students online.
 Store information of the student in database.
 Assign instructor for each subject efficiently.
 Placement of dorm for the students according to their gender.
 Make class schedule without clash of class.
 Generate report about the students.
College director:
 Select instructor from different department.
 Send selected instructor.
Instructor:
 Can see class schedule online.
 Can upload materials (lab tutorial, books, handout and any other material).
School director:
 Can be beneficiaries by giving the selected students information online.
 Can send SMS message for the students.

1.8 Methodology of the project

1.8.1 Data collection tools and techniques


Data collection is the most important part of the project to find the main requirement of
the system and to understand how the system works. We are going to use different
methods to collect data. Among the methods, we use the following:
 Interview – Interviewing the community services coordinator and the STEM program
coordinator by preparing the question, ask the question and get the answer for every
question.
 Questionnaires - this technique help us to know much about the program by preparing
and giving them question.
 Document analysis – this technique helps us to analysis the existing system problems
and enable us to know how they work and this give us everything about the program in
wolkite university.

xvi
1.8.2 System analysis and design
In our project we will use object-oriented software engineering methodology (approaches)
to develop the system. Because it is a popular technical approach for analyzing, designing
an application system, or business by applying the object-oriented paradigm and visual
modeling throughout the development life cycles. Object oriented system analysis and
design is selected since it has so many advantages and which can make the system more
effective.

The advantages of Object-Oriented system analysis and design:

 The ability to tackle more achieving problem domains.


 To simplify the design and implementation of complex program.
 We can inherit properties of the class that are defined in the super class.
 We can reuse methods for avoiding redundancy.
 Increased consistency among analysis, design and programming activities.
 The data and functions are encapsulated in the objects that help us for easily
debugging purpose.
 Explicit representation of commonality among system components.

1.8.3 System development model


Iterative software development model
The iterative model is a particular implementation of a software development life cycle
(SDLC) that focuses on an initial, simplified implementation, which then progressively
gains more complexity and a broader feature set until the final system is complete
[ CITATION SDL \l 1033 ].
This model has so many advantages some of them are:

 Results are obtained early and periodically.


 Parallel development can be planned.
 Progress can be measured.
 Testing and debugging during smaller iterations are easy[ CITATION SDL \l
1033 ].

xvii
1.8.4 Development tools and technologies
Modeling tools
 MS-Visio - enable us to draw (model) different diagram for our system.
 Edraw-Max - for designing different model of our system.
Programing language tools
 PHP– now a day this language is one of the best backend programming
and it help us to code.
 JavaScript – this is used to code client-side code.
 J-query - this is used for displaying some pages smarter.
 Bootstrap and CSS - for styling the user interface.
Database design tools
 MYSQL - is a relational database management system based on SQL
which used as storage.
 Xampp-Server which function as server in one computer.
Other editing software
 Adobe Photoshop CS6 - Adobe Photoshop used to edit images inserted in
the system and other editing and designing tools.

1.9 Document organization


This project consists of five chapters. Chapter one discusses about introduction, background of
the existing system. Statement of the problem, objective of the project (both general and
specific objective), significance of the project, scope of the project, limitation of the project,
methodology of the project, feasibility, Document Organization. Chapter two deals about
description of the current system, major function of the existing system, user of the existing
system, drawback of existing system, forms and other documents of the existing system and
business rule. Chapter three deals about overview of the proposed system, business rule,
functional requirement, process requirement, input requirement, output requirement, storage
requirement, and nonfunctional requirement. Determine security and safety procedures for our
project. Chapter four deals about we define system analysis and design for our projects include
scenarios, system model, user class and characteristics (actor specification), use case diagram
(system use case diagram and use case description), class diagram, dynamic model of our

xviii
system and this includes sequence diagram, activity diagram, ER Diagram, Data Dictionary or
Mapping, and Normalization. Chapter five covers System Overview, Design Considerations,
Design Goals, Design Trade-offs, Architecture of the proposed System, Sub-system
Decomposition, Hardware/Software mapping (Deployment design), Persistent data
management, Class interfaces, and User interface design.

CHAPTER TWO

2. DESCRIPTION OF THE EXISTING SYSTEM

2.1 Introduction of the existing system


In this chapter we will discuss about the existing system in order to have better understanding
of Science, technology, engineering and mathematics (STEM) program and a massive
knowledge about the program.

Currently Science, technology, engineering and mathematics (STEM) program perform all of
its task manually. The STEM program director informs the students by sending paper letter to
the school director and then the school director informs them the registration date. And after
they came to the university students see their dorm from the manual announce board and
before placing the students, the director must go to student dean and ask the specific block for
STEM program purpose, after that the director can done placement of all students. Not only
this they see their class schedule from the announce board and before preparing class schedule
the director must get instructors from the colleges and these instructors must selected by the

xix
criteria’s (if the instructors participate in other program like weekend, distance, night and
summer programs this program is give priority for other instructors not participated in the
program), after the director gets all required instructors, class room and laboratory room and
he can prepare schedule.

2.2 User of the existing system


Players 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: -

 University director
A person who manage the whole activity in STEM program and perform task in
the existing system like Informing the school director, Dorm placement,
Registration of students, Class room placement, Class schedule, Report generation
these all task done by the university director.
 College director
A person who is responsible for selecting the instructors from different
departments and selecting different class and laboratory room then report to the
university director.
 Instructor
A person who is responsible for teaching the students and help them to gain more
knowledge about the current technology and science by uploading different
materials like lab tutorials, books, handouts and any other materials that is useful
for them.
 Student
A person who is responsible for taking the STEM program and can view different
information about dorm placement, class room placement, class schedule and
other different materials uploaded by the instructors.
 School director
A person who is responsible for informing by using SMS message and send the
lists of those students that include name, wereda, grade and point they score.

xx
2.3 Major function of the existing system
In the existing system major functions are done in manually way the major functions in the
existing system are as the following: -

 Informing the school director: - the community service director of the university
informs for different school directors to send their skilled and talented student selected
from the school by their grade and the community service director inform by using
letters or by sending person.
 Registration of students: - the community service director of the university registers
talented and skilled students selected from different school from grade (8-12) and if
the director wants to update the student’s information they search and update
manually.
 Dorm placement: - first there is pre-assigned dorm for both male and female students
and then the community service director of the university arrange the students in
alphabetic order and give them dorm maximum of six and minimum of four students
in each dorm form both genders.
 Selecting instructors: - the community service of the college select instructor from
different department and report to the director of the university and the director receive
the instructors and assign for different courses
 Class room placement: first there is pre-assigned class room and laboratory room for
the purpose of STEM program and assign class room maximum of 40 students in the
class and also in the laboratory.
 Class schedule: - first there is pre-assigned teachers for different courses according to
the one-to-one relation 1 instructor assigned for 1 class room or laboratory room at a
time by using this the director prepare class schedule.
 Report preparation: - the community service of the university prepare report about
how many students the school directors reports to the university and how many of
them take the STEM program, and how many instructors selected from the
departments and give service to the students.

xxi
2.4 Forms and Other Documents of the Existing Systems (if any)
When we interview the university community service director, he told us about the whole work
done in the STEM program and how they work, and he let us to analysis the document and we
capture the following forms and letters.

There are a lot of forms and letters which are:

 Instructor request to the college community service director.


 Response lists of instructors to the university community service director.
 Preparation of class schedule.
 Student satisfaction form.
 Report Generation form.

xxii
Figure 2-1 Instructor request to the college community service director

xxiii
Figure 2-2 Response lists of instructors to the director

xxiv
Figure 2-3 Student satisfaction form.

xxv
Figure 2-4 Preparation of class schedule.

xxvi
Figure 2-5 Report Generation form.

2.5 Drawback of the existing system


 Consume a lot of resources and working times to register students.
 Since it is a manual system that means it can only perform limited number of tasks at a
time.
 In the manual system there are many student’s information stored, it is difficult to get
the information when required.
 Preparing and organizing reports are Difficult and time-consuming work.
 Require a lot of human power and resources to prepare class schedule.
 Require a lot of human power and resources to prepare dorm placement.
 The prepared class schedule may not stay longer in the announce board.
 Since it is manual the information of students may lose or damage.
 Preparing class schedule is difficult.
 Assigning instructors for different sections is difficult.
 Giving the material for the student is too tedious.

xxvii
2.6 Business rule of the existing system
BUSINES BUSINESS RULE NAME BUSINESS RULE DESCRIPTION
S RULE
ID
BR 1 Students are must be between grade 8-12. Only students selected from 8th, 10th, and
12th grade below 8th and above 12th grade
is not allowed to take this program.
BR 2 Only two students are allowed to take the The maximum number selected from each
program from each grade. grade is 2 students.
BR 3 Students should not change their dorm Student only live in there given dorm not
without the permission of the proctor and allowed to change their dorm.
sufficient reason.
BR 4 Students are allocated in which male Dorm placement must be done in a way in
students are not allocated together with which based on their gender.
female students.
BR 5 The selected instructors must not teach This program benefit instructor and this
before in any program like weekend, chance is given priority for instructor not
summer and extension. benefited before.
BR 6 Selecting 2 instructors and 2 lab technicians Maximum of 4 teachers are selected from
from one department. each department to give the program
BR 7 One instructor must not assign for different Clash of class is not allowed.
rooms at the same time.
BR 8 The time bound for teaching is from Teaching and learning process in delivered
2:30am to 6:30 for morning and 7:30pm to in the given time.
11:30pm for afternoon session.

Table 2-1 Business rule of the existing system.

xxviii
CHAPTER THREE

3. PROPOSED SYSTEM
The proposed system will solve the existing system problem that has been faced currently. This
system is design and developed in such a way that it will solve all the pre-describe problems in
the existing system that have been practice in STEM program. The proposed system will be more
flexible and user friendly for user to access information without wasting their time. Proposed
system is a system that is developed to give solution to the existing system.

The proposed system that is going to be developed by our team will automate the operations of
the current STEM program. It will be used to manage and process data recording based on the
rule and regulations of the current system. The new system provides capability of organizing all
information in a single client-server system, easy way of recording and accessing information by
its well-organized user-friendly interface.

3.1 Functional Requirements


Functional requirements are the functions of the proposed system and its components. It
describes the interactions between the system and its environment independent of its
implementation and specific functionality that define what the system is supposed to accomplish [
CITATION top16 \l 1033 ].

The major functionalities of the system are the following:

The system shall allow the Administrator to

 Login to the system.


 Manage users account (create, view, delete and update).
 Logout from the system.
The system shall allow University Director to: -
 Manage users account (create, view, delete and update).
 Request instructors to director of community service of college.
 Assign courses to instructors.
 Request students to the school directors.

xxix
 Request available laboratory rooms and class rooms.
 Generate class schedule.
 Generate dorm placement.
 Give feedback.
The system shall allow College Director: -
 Select instructors according to some criteria.
 Send selected instructors to the director.
 Send available laboratory room and class room.
 Give feedback.
The system shall allow instructors/Teachers to: -
 View class schedule.
 Upload different materials (lab tutorial, books, handout, course outline and any
other material).
The system shall allow students to: -
 View dorm placement
 Register.
 Download course materials (lab tutorial, books, handout, course outline and any
other materials).
 Receive SMS message from the school director.
 Give feedback.
The system shall allow School directors to: -
 Send SMS message to the students.
 View uploaded course materials.

3.2 Non-Functional Requirements

3.2.1 User Interface and Human Factors


The user interface of the proposed system will be simple to understand, easy to use and
user-friendly and users of the system can easily use and perform their task, and this
interface provide visibility to the functioning system. To design better user interface we
design beautiful buttons, check boxes, menus and others by using bootstrap framework
and this framework enable us to easily create responsive user interface. The developed

xxx
system provides web application user interfaces and it will be responsive user interface in
all devices.

The system we will develop require no expert level anyone who has basic computer skill
and who know how browser works can easily access our system.

3.2.2 Hardware Consideration


The Software product to be developed should run on existing system standard server and
accessible by any computers. The system will be portable that can accessible by any type
of computers, it supports any type of browsers like Internet Explorer, Mozilla Firefox,
Google Chrome, etc. and run in any operating systems like WINDOWS, UNIX, LINUX
and etc.

3.2.3 Security Issues


The proposed system is protected from internal and external intrusions or unauthorized
user by the following methods: -

User authentication

 The system provides username and password for each user based on their
privilege
 When users try to access the system should authenticate by asking user name
and password.
 The system allows only valid user to login to the system.
 The system will only be accessed by registered users and administrative.
 System data modification shall only be done by Privileged users.

Encryption mechanism

 To create strong password the allow making the password the system allow
password length minimum of 8 character and combination of characters that
include numbers, special characters, and upper letters and lower-case letters.
 To prevent credential data like password not easily view by anyone so, the
system will encrypt those data or information using Message-Digest algorithm
(MD5) hashing algorithm.

xxxi
3.2.4 Performance Consideration
Since the system is going to be accessed by different users with different needs, it should
be capable of handling concurrent tasks and processing their tasks as quickly as possible.
Generally, the system should be able to handle many users at the same time and it will be
responsive for all user at the same time. To increase the system performance, we
implement the best searching, inserting, and retrieving algorithm and also properly
normalize our database. The system should be responsibly fast in order to access the
required information easily.

 The login information shall be verified within a few seconds.


 The users get the expected result within a few seconds.

3.2.5 Error Handling and Validation


Since the system is going to be accessed by different users with different needs, it should
capable of handling different exceptions like: -

 The system handles many exceptions like inserting empty string to the database
and inserting a duplicated students id, inserting incorrect students name and
display an appropriate message for each error. The system should have error
handling mechanisms that is, as errors occur it should not stop functioning rather
provide error manages and should guide the user through what to do next.
 The system shall handle an attempt to login with incorrect username and password
and display error message.
3.2.5 Quality Issues

Reliability: The proposed system will minimize crash during its runtime, since more than
one user could use the system simultaneously.

 Good validations for user inputs will be done.


 Avoid incorrect storage of records.

Availability: There is no delay in the availability of any information, whatever needed,


can be captured very quickly and easily by using more than one server. The server should
be always on to be availability. The system should have to be functional at any given time.

xxxii
Usability

 User operability: -The system will offer simple navigation function so, can be
operated by any user with basic computer knowledge.
 Language support: - The proposed system supports English language.
3.2.6 Backup and Recovery

Storing data in another place for backup purpose, if the system is destroyed, then it is easy
to get the lost data. This can be done by placing the data in another place. If the data is
failed or lost, then the lost data can be easily recovered the database.

3.2.7 Physical Environment


The system is deployed or installed on the server computer, but for more feature we
recommend that the system to deploy on the cloud that is free from any disaster.

3.2.8 Resource Issues


The system consumes resources that required high processor speed and memory for both
server and client.

3.2.9 Documentation
The system will provide two types of system documentation. These are internal and
external documentation. System documentation addresses programmers, system
developers, owners, and users. Programmers include those who are currently working on
the project as well as those who give support and maintain the system including the
system administrator.

xxxiii
CHAPTER FOUR

4 SYSTEM ANALYSIS
This chapter describes what the proposed system does and how it carries out its activities. These
include use case diagrams, use case description, analysis level class diagram (conceptual
modeling), sequence diagram, activity diagram and state chart diagram.

4.2 System Model


This section consists of the modeling of the proposed system using object-oriented
methodologies such as unified modeling language (UML). Here represents the proposed system
by using different system models such as use case models, object models, dynamic models, that
describe the problem to be solved and as the system models represented by graphically, they are
more understandable than more detailed natural language description of the system requirement.

4.2.5 Use Case Model


Use case model is composed of a use case diagram and the accompanying documentation
describing the use cases, actors, and associations, and representation of the system
intended functions and its environment[ CITATION wik194 \l 1033 ].

Use case diagram is created to visualize interactions between systems with the external
environment[ CITATION wik194 \l 1033 ].

Use case: It’s the identification and representation of a sequence of actions that the user
(Actors) takes for a system to get particular target. It can be identified and represented by
ellipses with a respective descriptive name.

Actor is a person, system, or real object that plays a role in one or more interactions with
the system. Relationship between actors and classes are indicated within use case
diagrams.

There are 6 major actors in the proposed system are: -

 Administrator (Admin)
 Community service director of university (University director).

xxxiv
 Community service director of college (College Director).
 Instructor
 Student
 School director.

Lists of use case

 Login
 Create account
 Update account
 Delete account
 Add user
 Update user
 Delete user
 View user
 Manage notification
 Manage profile
 Send Request
 Select Instructor
 Generate Dorm placement
 View Dorm placement
 Generate Class schedule
 View Class schedule
 Upload materials
 Download Material
 Give Feedback
 Send SMS message
 View SMS message
 Generate Reports
 Logout

xxxv

STEM management system

<<Include>>

Login Upload materials

Select Instructor <<Include>>

<<Include>> <<Include>> View Class schedule


Send classroom and
laboratory room

Extend
<<Include>>
View SMS message Instructor
Send selected
<<Include>>
instructor
<<Include>>
College Director Logout
Send Request Fill agreement form
<<Include>>
<<Include>>
Generate Class
schedule <<Include>> View Dorm
<<Include>> placement

Update Class
schedule Student
<<Include>> Download Material
<<Include>>
Generate Dorm
Administrator placement
<<Include>> Give feedback

Generate Reports

Send SMS message


Add user
Manage user

Extend

View user Send selected


University Director Manage account
students School Director
Extend
Extend
Extend Extend
Update user
Extend
Update user
Extend account

Delete user
account Delete user

Create user account

xxxvi
UseUse
Figure 4-6 case
caseDescription
diagram

Use case name Login

Use case identifier UCID - 01


Actor(s) Administrator, University Director, College Director,
Instructor, School director and Student.
Description Allows user to access the system and interact with the
system.
Precondition The users must have valid username and password.

Basic Course of Action Actor actions System Responses


Step1: user initiates the Step2: The system shows the
UCID - 01

system on home page. login interface for the user.

Step3: user enter username Step4: The system validates


and password. user name and password.
[A.1]

Step5: The system display


user home page.

Step6: The Use case end.


Alternative Course of Action A.1 If the input information invalid or empty.
Step4.1: The system display error message.

Step4.2: The system returns to step2.


Post condition The user accesses the system.
Table 4-2 Use case description for Login

Use case name Manage account

Use case identifier UCID – 02

xxxvii
UCID - 02
Actor(s) Administrator.
Description Allows Administrator to create account for valid users to access the
system, update and delete accounts of the users.
Precondition The Administrator must login to the system.

Basic Course of Action Actor actions System Responses


Step1: Administrator enter Step2: The system validates
username and password. user name and password. [A.1]

Step4: Administrator select Step3: The system display


manage account: admin page.

1. Create account Step5: The system displays


2. Update account Create account page.
3. Delete account
Step7: The System checks
4. View account
added user information. [A.2]
Step4.1: If the Administrator
Step8: The System add user
selects Create account go to
account information to the
Step5.
database and go to Step4.
Step6: Administrator enter user
Step9: The system displays
account information.
Update account page.
Step4.2: If the Administrator
Step11: The System checks
selects Update account then go to
updated account information.
Step9.
[A.2]
Step10: Administrator enter user
Step12: The system displays
account information to be
Delete account page.
updated.
Step14: The System checks
Step4.3: If the Administrator
deleted account information
selects Delete account go to

xxxviii
Step12. and go to Step4. [A.2]

Step13: Administrator enter user Step15: Display user accounts


account information to be information.
Deleted.
Step16: The Use case end.
Step4.4: If the Administrator
selects View account go to
Step15.
Alternative Course of A.1: If the user name and password is incorrect.
Action
Step2.1: The system displays error message and Go to
Step1.

A.2: If the input is incorrect or empty, then go to step4 select one of


the following operations and fill the required information correctly.
Post condition The admin successfully creates, update and delete user account.
Table 4-3 Use case description for Manage account
UCID - 03

Use case name Manage User

Use case identifier UCID – 03


Actor(s) University Director.
Description Allows University Director to add, view, update and delete user to and
from the system.
Precondition The users must have valid username and password.

Basic Course of Actor actions System Responses


Action Step1: University Director enter Step2: The system validates
username and password. user name and password. [A.1]

Step4: University Director select Step3: The system display


manage user: admin page.

1. Add User Step5: The system displays

xxxix
2. Update User add user page.
3. Delete User
Step7: The System checks
4. View User
added user information. [A.2]
Step4.1: If the university director
Step8: The System add user
selects Add user
information to the database and
Step6: University Director enter user go to Step4.
information.
Step9: The system displays
Step4.2: If the University Director Update user page.
selects Update user information then
Step11: The System checks
go to Step9.
updated user information and
Step10: University Director enter go to Step4. [A.2]
user information to be updated.
Step12: The system displays
Step4.3: If the University Director Delete user page.
selects Delete user go to Step12.
Step14: The System checks
Step13: University Director enter deleted user information and
user information to be Deleted. go to Step4. [A.2]

Step4.4: If the University Director Step15: Display User


selects View user go to Step15. information.

Step16: The Use case end.


Alternative Course of A.1: If the user name and password is incorrect.
Action
Step2.1: The system display error message and Go to Step1.

A.2: If the input is incorrect or empty then Go to step4 select one of


the following operations and fill the required information correctly.
Post condition The University Director successfully creates, update and delete user
account.
Table 4-4 Use case description for Manager user

xl
Use case name Select Instructor

Use case identifier UCID - 04


Actor(s) College Director
Description Allows College Director to select instructors to teach the
selected students.
Precondition The College Director must have valid username and
password.

Basic Course of Action Actor actions System Responses


Step1: College Director Step2: The system validates
enter user name and user name and password. [A.1]
password.
UCID - 04

Step4: The system displays


Step3: College Director select Instructor page.
choose Select Instructor.
Step7: The system displays
Step5: College Director selected instructors.
prepare questions for
Step8: The Use case end.
instructors.

Step6: College Director


select instructor based on
their score.
Alternative Course of Action A.1: If the user name and password is incorrect.

Step2.1: The system display error message and Go to


Step1.
Post condition The College Director must successfully select instructors.
Table 4-5 Use case description for Select instructor

xli
Use case name Generate Class schedule

Use case identifier UCID - 05


Actor(s) University Director
Description Allows University Director to Generate class schedule for
each grade (8th, 10th,12th).
Precondition The University Director must have valid username and
password.

Basic Course of Action Actor actions System Responses


Step1: University Director Step2: The system validates
enter user name and user name and password.
password. [A.1]

Step3: University Director Step4: The system display


UCID - 05

select Class schedule.


Class schedule page.
Step5: University Director
Step7: The system displays
Select Instructor, time, date,
generated class schedule.
classroom and course.
[A.2]
Step6: University Director
Step8: The Use case end.
click on Generate Class
Schedule button.
Alternative Course of Action A.1: If the user name and password is incorrect.

Step2.1: The system displays error message and Go


to Step1.

A.2: If the system fails to Generate Class Schedule Go to


Step5.
Post condition The University Director successfully generate class
schedule.
Table 4-6 Use case description for Generate Class Schedule

xlii
Use case name Send Request

Use case identifier UCID - 06


Actor(s) University Director, School Director
Description Allows Admin and College Director to Send different
request.
Precondition The User must have valid username and password, and must
login to the system.

Basic Course of Action Actor actions System Responses


Step1: User enter username Step2: The system validates
and password. username and password.
UCID - 06

[A.1]
Step3: User select Request.
Step4: The system display
Step5: User select the form
and write the request. Request page.

Step6: The user clicks send Step7: The system displays


request button. Successful message. [A.2]

Step8: The Use case end.


Alternative Course of Action A.1: If the user name and password is incorrect.

Step2.1: The system display error message and Go to


Step1.

A.2: If the system fails to send request Go to Step5.


Post condition The user successfully send request.
Table 4-7 Use case description for Send request

xliii
Use case name Generate Dorm Placement

Use case identifier UCID - 07


Actor(s) University Director
Description Allows University Director to give dorm for all students.
Precondition The University Director must have valid username and
password, and must login to the system.

Basic Course of Action Actor actions System Responses


Step1: University Director Step2: The system validates
enter username and username and password.
password. [A.1]

Step3: User select Dorm Step4: The system display


Placement.
UCID - 07

Dorm Placement page.


Step5: University Director
Step7: The system displays
Select Student, Block and
Generated Dorm placement.
Dorm.
[A.2]
Step6: University Director
Step8: The Use case end.
click on Generate Dorm
Placement button.
Alternative Course of Action A.1: If the user name and password is incorrect.

Step2.1: The system display error message and Go to


Step1.

A.2: If the system fails to Generate Dorm Placement Go to


Step5.
Post condition The University Director Must Successfully Generate dorm
placement.
Table 4-8 Use case description for Generate dorm placement

xliv
Use case name Upload material

Use case identifier UCID - 08


Actor(s) Instructor
Description Allows Instructor to upload different materials for their
students.
Precondition The Admin must have valid username and password, and
must login to the system.

Basic Course of Action Actor actions System Responses


Step1: Instructor enter Step2: The system validates
username and password. username and password.
[A.1]
UCID - 08

Step3: Instructor select


Upload material link. Step4: The system display

Step5: Instructor select the Upload material page.


materials to be uploaded.
Step7: The system displays
Step6: Instructor click on the uploaded materials. [A.2]
Upload material button.
Step8: The Use case end.
Alternative Course of Action A.1: If the user name and password is incorrect.

Step2.1: The system display error message and Go to


Step1.

A.2: If the system fails to display the uploaded materials Go


to Step5.
Post condition The Instructor successfully Upload the materials.
Table 4-9 Use case description for Upload material

Use case name Download material

Use case identifier UCID - 09

xlv
UCID - 09
Actor(s) Student
Description Allows Student to download the uploaded materials.
Precondition The Students must have valid username and password, and
must login to the system.

Basic Course of Action Actor actions System Responses


Step1: Student enter Step2: The system validates
username and password. username and password.
[A.1]
Step4: Student click
Download material link. Step3: The system display

Step6: Student view the Students home page.


downloaded materials.
Step5: The system downloads
the materials successfully.
[A.2]

Step7: The Use case end.


Alternative Course of Action A.1: If the user name and password is incorrect.

Step2.1: The system display error message and Go to


Step1.

A.2: If the system fails to download the uploaded materials


Go to Step4.
Post condition The Student successfully download the materials.
Table 4-10 Use case description for Download material
UCID - 010

Use case name Send SMS message

Use case identifier UCID - 010


Actor(s) School Director
Description Allows School Director to inform the students by using SMS

xlvi
message.
Precondition The School Director must have valid username and
password, and must login to the system.

Basic Course of Action Actor actions System Responses


Step1: School Director Step2: The system validates
enter username and username and password.
password. [A.1]

Step4: School Director Step3: The system display


select SMS message link.
School Director home page.
Step6: School Director
Step5: The system display
writes students phone
SMS message form. [A.2]
number and the message.
Step8: The Use case end.
Step7: School Director
click send SMS message
button.
Alternative Course of Action A.1: If the user name and password is incorrect.

Step2.1: The system display error message and Go to


Step1.

A.2: If the system fails to send the SMS message Go to


Step6.
Post condition The School Director successfully the message to students.
Table 4-11 Use case description for Send SMS message
Use case Scenario

A usage scenario, or scenario for short, describes a real-world example of how one or more
people or organizations interact with a system. They describe the steps, events, and/or actions
which occur during the interaction[ CITATION art19 \l 1033 ].

1. Scenario name: Login. Mr. X wants to login into the system

xlvii
I. The Mr. X must enter username and password and
II. Then Mr. X click the login button,
III. If Mr. X has valid account the system display user page else display error
message.

2. Scenario name: Upload material. Mr. X wants to upload material into the system

I. First Mr. X must login into the system and


II. Then Mr. X has valid account system displays instructor page else display error
message.
III. Then Mr. X select upload menu and the system display browse from the storage
device.
IV. Mr. X select the material to be uploaded.
V. Then Mr. X click upload button, then the system display course material is
uploaded.

3. Scenario name: Download material. Mr. X wants to upload material into the system

I. First the Mr. X must login into the system and the system displays student pages
II. Then Mr. X click download course button and the system display course materials
are downloaded successfully.

4. Scenario name: Generate Class Schedule. Mr. X wants to generate class schedule.

I. First Mr. X must login into the system and the system displays University director
page
II. Then Mr. X selects generate class schedule menu
III. The system display course, section, instructor information.
IV. Mr. X selects appropriate information and click Generate button.
V. The system displays generate successfully message.

5. Scenario name: Generate Dorm Placement. Mr. X wants to generate class schedule.

I. First Mr. X must login into the system and the system displays University director
page

xlviii
II. Then Mr. X selects generate dorm placement menu
III. The system displays students, block and dorm information
IV. Mr. X selects appropriate information and click Generate button.
V. The system displays generate successfully message.

6. Scenario name: Manage account.

I. First Mr. X must login into the system and the system display admin page
II. Then the Mr. X selects one of the listed sub-menus
III. If Mr. X wants to create a new account, click to create account link and
IV. The System displays create account form Then Mr. X fill needed information
correctly.
V. The system displays account successfully created message.

4.3 Object model


In this section, discussed an overview of object model such us class diagram, Data dictionary.

4.3.5 Class Diagram


Class diagram in the Unified Modelling Language (UML) is a type of static structure
diagram that describes a conceptual relationship among objects/classes [ CITATION wik195 \l
1033 ].

xlix
Figure 4-7 Conceptual class diagram

l
4.3.6 Data Dictionary
In this section mention attributes, data type, data size, key constraints and constraints on
the identified entities or classes by using tabular form.

Table: - Student table


Primary key: - StudentID
Description: - this table shows students' information
Key Constraints Field Name Caption Data type Field Size
Primary Key StudentID ID Varchar 30
Not Null firstName First Name Varchar 30
Not Null lastName Last Name Varchar 30
Not Null Age Age Number 2
Not Null Gender Gender Varchar 10
Null phoneNumber Phone Number Varchar 20

Table 4-12 Data Dictionary for Student table


Table: - Instructor table
Primary key: - InstructorID
Description: - this table shows Instructor information
Key Constraints Field Name Caption Data type Field Size
Primary Key InstructorID ID Varchar 30
Not Null firstName First Name Varchar 30
Not Null lastName Last Name Varchar 30
Not Null Age Age Number 2
Not Null Gender Gender Varchar 10
Not Null phoneNumber Phone Number Varchar 20
Not Null Email Email Varchar 50

li
Table 4-13 Data Dictionary for Instructor table

Table: - Account table


Primary key: - accountID
Description: - this table shows Account information
Key Constraints Field Name Caption Data type Field Size
Primary Key accountID ID Varchar 30
Not Null userName User Name Varchar 30
Not Null password Password Varchar 30
Not Null userRole Role Varchar 30

Table 4-14 Data Dictionary for Account table


Table: - Course table
Primary key: - courseCode
Description: - this table shows Course information
Key Constraints Field Name Caption Data type Field Size
Primary Key courseCode Course Code Varchar 30
Not Null courseName Course Name Varchar 30

Table 4-15 Data Dictionary for Course table


Table: - Room table
Primary key: - roomNumber
Description: - this table shows Room information
Key Constraints Field Name Caption Data type Field Size
Primary Key roomNumber Room Number Varchar 30
Not Null roomLocation Room Location Varchar 30
Table 4-16 Data Dictionary for Room table

lii
Table: - Department table
Primary key: - departmentID
Description: - this table shows Department information
Key Constraints Field Name Caption Data type Field Size
Primary Key departmentID ID Varchar 30
Not Null departmentName DepartmentNam Varchar 30
e
Table 4-17 Data Dictionary for Department table

Table: - Building table


Primary key: - buildingName
Description: - this table shows building information

Key Constraints Field Name Caption Data type Field Size


Primary Key dormNumber Dorm Number Varchar 30
Not Null buildingName Building Name Varchar 30
Table 4-18 Data Dictionary for Building table

Table: - College table


Primary key: - collegeNumber
Description: - this table shows college information
Key Constraints Field Name Caption Data type Field Size
Primary Key collegeNumber ID Varchar 30
Not Null collegeName College Name Varchar 30

liii
Table 4-19 Data Dictionary for College table

4.4 Dynamic model

4.4.5 Sequence Diagram


Sequence diagrams show the interaction between participating objects in a given use case.
They are helpful to identify the missing objects that are not identified in the analysis
object model[ CITATION wik196 \l 1033 ].

liv
Figure 4-8 Sequence diagram for Login

lv
Figure 4-9 Sequence diagram for Add user

lvi
Figure 4-10 Sequence diagram for Update user

lvii
Figure 4-11 Sequence diagram for Delete user

lviii
Figure 4-12 Sequence diagram for View user

lix
Figure 4-13 Sequence diagram for Upload material

lx
Figure 4-14 Sequence diagram for Download material

lxi
Figure 4-15 Sequence diagram for Generate Class Schedule

lxii
Figure 4-16 Sequence diagram for Generate Dorm Placement

lxiii
4.4.6 Activity Diagram
Activity diagram used to emphasize the flow of control from activity to activity or to
model the flow of an object as it moves from the state at different points in the flow of
control[ CITATION uni19 \l 1033 ].

Figure 4-17 Activity diagram for Login

lxiv
Figure 4-18 Activity diagram for Upload material

lxv
Figure 4-19 Activity diagram for Download material

lxvi
Figure 4-20 Activity diagram for Manage account

lxvii
Figure 4-21 Activity diagram for Manage user

lxviii
lxix
Figure 4-22 Activity diagram for Generate class schedule

lxx
Figure 4-23 Activity Diagram for Generate Dorm Placement

lxxi
4.4.7 State Chart Diagram
State chart diagram is used to describe the states of different objects in its life cycle. So,
the emphasis is given on the state changes upon some internal or external events. These
states of objects are important to analyze and implement them accurately[ CITATION
uml19 \l 1033 ].

Figure 4-24 State chart Diagram for Login

lxxii
Figure 4-25 State Chart Diagram for Upload material

lxxiii
Figure 4-26 State Chart Diagram for Upload material

lxxiv
Figure 4-27 State Chart Diagram for Manage account

lxxv
Figure 4-28 State Chart Diagram for Manage user

lxxvi
CHAPTER – FIVE

5 SYSTEM DESIGN
This chapter focuses on transforming the analysis model into the design model that takes into
account the nonfunctional requirements and constraints described in the problem statement and
requirement analysis sections discussed earlier. In addition to this, we describe a brief overview
of the design goals, proposed software architecture, Hardware/software mapping, Persistent data
management, Access control and security.

5.2 Design Goals


The objectives of the design are to model the system with high quality. The design goals
are derived from non-functional requirements that means non-functional requirement is
the description of the feature characteristics and attribute of the system as well as any
constraints that may limit the boundary of the proposed solution. The design Goals
specify the qualities of the system that should be achieved and addressed during the
design of the system like:

5.2.5 Performance
The proposed system performs its operations within a minimum amount of time and the
user gets the expected result within a few seconds and the system is effective. To make
our system has a high performance we will properly normalize our database, design based
on three-tier architecture, implement multiple database.

5.2.6 Dependability
The user’s needs the system to be highly dependable. The system should be robust
(forceful) i.e. It should be able to carry on invalid user inputs, fault tolerant, reliable and
available. The system shouldn’t allow non-authorized users to access students’ personal
data or modify.

5.2.7 Maintenance
The system should be easily extensible to add new functionalities at a later stage. It
should also be easily modified to make changes to the features and functionalities.

lxxvii
5.2.8 End user
The system has simple and understandable graphical user Interface such as forms and
buttons, which have descriptive names.

5.2.9 Security requirement


Since the system hold important information (data), the system requires strong security
features to protect that valuable information i.e. not allow other users or unauthorized
users to access data that has no right to access it. To prevent brute force, attack the
system control a maximum of 5 login attempts. To prevent credential data like password
not easily view by anyone so, the system will encrypt those data or information using
Enhanced message digest (MD) 5 hashing algorithm.

5.3 Proposed System Architecture


The proposed system has three layers of architecture. The layers are the following:

 Presentation layer
 Logic layer/Application layer
 Database layer

Presentation layer: Layer which provides graphical user interface and application-specific
entry forms to the user of the system. Application layer interacts with the logical layer
through HTTP/ HTTPs protocol and sends content to browsers in the form of HTML/JS/CSS.

Logic layer/Application layer: Layer that used to implement business rules and data rules,
which keep the data structure consistent.

Database layer: This actual DBMS layer which store and retrieve data from database, it
provides data persistence mechanism to access the database without installing database
dependent drivers and libraries on the client device.

lxxviii
Figure 5-29 Proposed system architecture

lxxix
5.3.5 Subsystem Decomposition and Description
Any system can be decomposed into different subsystem based on the functional
services. A subsystem is characterized by the services it provides to another subsystem.
The proposed system has been divided into eight subsystems.

Database connection subsystem: This subsystem allows us to create database


connection.

 Database connection.

Account management subsystem: This subsystem allows for managing user account
information and performs the following operation.

 Create user account


 Upload user account
 Delete user account
 View user account

User management subsystem: This subsystem managing of information user and


perform the following operations.

 Add user.
 Upload user
 Delete user.
 View user.

Class schedule subsystem: This subsystem allows us to manage class scheduling and
performs the following operation.

 Generate class scheduling


 View class scheduling
 Update class scheduling

Dorm placement subsystem: This subsystem allows us to manage Dorm placement and
performs the following operation.

lxxx
 Generate dorm placement
 View dorm placement
 Update dorm placement

Report management subsystem: This subsystem allows us to manage reports and


performs the following operation.

 Generate reports
 View reports

Request management subsystem: This subsystem allows us to manage requests and


performs the following operation.

 Send requests
 View requests
 Receive requests

Assign instructor and material subsystem: This subsystem allows us to manage


requests and performs the following operation.

 Assign instructor
 Add materials
 Upload materials
 Delete materials
 View materials

lxxxi
Figure 5-30 Subsystem Decomposition diagram

lxxxii
5.3.6 Hardware/Software Mapping
UML deployment diagram used to illustrate subsystem decomposition, taking software
into the real world by showing how software gets assigned to hardware and how
communicates. The deployment diagram shows how the software components, processes,
and objects are deployed into the physical architecture of the system.

Figure 5-31 Deployment Diagram

lxxxiii
5.3.7 Detailed Class Diagram
Class diagrams in the Unified Modelling Language (UML) is a type of static structure
diagram that describes the structure of a system by showing the system's classes, their
attributes, operations (or methods), and the relationships among the classes.

Figure 5-32 Detailed Class Diagram

lxxxiv
5.3.8 Persistence Data Management
Persistence models are used to communicate the design of database usually a relational
database to both users and developers. This is basically the entity-relationship model in a
database application.

Figure 5-33 Persistence diagram

5.3.9 Access Control and Security


List of use case Admin University College School Instructor Student
Director Director Director
Login      
Receive message 

Send message 

Manage user 

Manage account 

Select Students 

Send Request 

Select Instructors 

Upload materials 

Download materials 

Generate Dorm 
placement

View dorm placement  

Generate class schedule 

View class schedule   

Generate Report 

Logout      

lxxxv
5.4 Packages
In this section we have to organize and decomposes functionally related subsystem into packages
and specifying the dependency between packages.

lxxxvi
Figure 5-34 Package diagram

5.5 Algorithm Design


Algorithm Design for Create user account

Click on create account link

lxxxvii
Form is displayed

Fill information for the user

Click on create button

IF (valid) Display successful message.

EISE Display invalid input message

END IF

Algorithm Design for Update user account

Click on update account link

Form is displayed

Insert user id in the form

Click button search

If (exist)display user information

Fill information to be updated of the user

Click on update button

IF (valid) Display successful message.

EISE Display invalid input message

END IF

lxxxviii
5.6 User Interface Design

Figure 5-35 User interface for login

lxxxix
Figure 5-36 User interface for administrator home page

xc
CHAPTER - SIX

6 IMPLEMENTATION AND TESTING


The implementation phase in the software life-cycle is where the actual software is
implemented. The result of this phase consists of source code, together with documentation
to make the code more readable. This is what we call software implementation. The purpose
of these activities is to convert the final physical system specification into working model
with reliable software and hardware, document the work that has been done and provide help
for current and future users and take care of the system.
Implementation concerned with the type of material (Hardware and Software required),
objective of implementation, code samples of the system. The following section describes
some of the tool that is often used in STEM management system implementation.

6.2 Implementation of the Database


Sample code
Database: `STEM`
---------------------------------------------------------
-- Table structure for table `account`
CREATE TABLE `account` (
`User_Name` varchar(50) NOT NULL,
`Password` varchar(50) NOT NULL,
`Role` varchar(50) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

-- Table structure for table `building`


CREATE TABLE `building` (
`Block_Number` int(10) NOT NULL,
`Dorm_Number` int(10) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

-- Table structure for table `class_room`


CREATE TABLE `class_room` (
`Room_Number` varchar(50) NOT NULL,
`Room_Location` varchar(50) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

-- Table structure for table `course`

xci
CREATE TABLE `course` (
`Course_Name` varchar(50) NOT NULL,
`Course_Code` varchar(50) NOT NULL,
`Course_Description` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

-- Table structure for table `instructor`


CREATE TABLE `instructor` (
`ID` varchar(50) NOT NULL,
`First_Name` varchar(50) NOT NULL,
`Middle_Name` varchar(50) NOT NULL,
`Last_Name` varchar(50) NOT NULL,
`Gender` varchar(10) NOT NULL,
`Age` int(10) UNSIGNED NOT NULL,
`Email` varchar(255) NOT NULL,
`College` varchar(50) NOT NULL,
`Department` varchar(50) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

-- Table structure for table `student`


CREATE TABLE `student` (
`ID` varchar(20) NOT NULL,
`First_Name` varchar(50) NOT NULL,
`Middle_Name` varchar(50) NOT NULL,
`Last_Name` varchar(50) NOT NULL,
`Gender` varchar(10) NOT NULL,
`Age` int(10) UNSIGNED NOT NULL,
`Grade` varchar(20) NOT NULL,
`Phone_Number` varchar(50) NOT NULL,
`Wereda` varchar(50) NOT NULL,
`Kebele` varchar(50) NOT NULL,
`School` varchar(50) NOT NULL,
`Block_Number` int(10) NOT NULL,
`Dorm_Number` int(10) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
-- Table structure for table `upload_file`
CREATE TABLE `upload_file` (
`ID` int(11) NOT NULL,
`file_name` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

xcii
6.3 Implementation of Class Diagram

Identifier Type STEM management system


Methods +CreateAccount();
#UpdateAccount();
#DeleteAccount();
+ViewAccount();
+ManageStudent();
+ManageInstructor();
+UploadMaterials();
+ DownloadMaterials();
+ManageClassRoom();
+ManageDormPlacement();
+ManageClassScheduling();
+ManageBuilding();
+ManageCourse();
Variables +Int ID
+VarChar First_Name
+VarChar Middle_Name
+VarChar Lase_Name
+VarChar Email
+VarChar Gender
+Int Age
+VarChar Grade
+VarChar Phone_Number
+VarChar Wereda
+VarChar Kebele
+VarChar School
+VarChar College
+VarChar Department

xciii
6.4 Configuration of Application Server
We use XAMPP application server because XAMPP is simple and lightweight. Apache
distribution is extremely easy to create a local web server for testing and deployment
purposes. Everything you needed is to set up a web server-server application (Apache),

xciv
database (MYSQL) and scripting language (PHP). XAMPP works on different operating
systems.

6.5 Configuration of Application Security


We validate our inputs by using client and server sides. Validate of the inputs sides allow
the user to fill correct information in our system we validate all the input to enter the
correct format. Example the name must be in the form of string not include other like
spatial character number our system refuse this inputs. In addition, age must be in the
form of number.

Sample code for input validation in Student Registration Form

xcv
<script type='text/javascript'>

function formValidator() {
var id = document.getElementById('id');
var first_name = document.getElementById('first_name');
var middle_name = document.getElementById('middle_name');
var last_name = document.getElementById('last_name');
var age = document.getElementById('age');
var phone = document.getElementById('phone');
var wereda = document.getElementById('wereda');
var kebele = document.getElementById('kebele');
var school = document.getElementById('school');
if (iswordNumeric(id, "Please Insert Student ID!")) {
if (isAlphabet(first_name, "Please Enter Only Letters For First Name!")){
if (isAlphabet(middle_name, "Please Enter Only Letters For Middle Name!")){
if (isAlphabet(last_name, "Please Enter Only Letters For Last Name!")){
if (phoneValidator(phone, "Please Enter Valid Phone Number!")) {
if (lengthRestriction(wereda, 4, 30)) {
if (lengthRestrictionforpassword(kebele, 4, 15)) {
if (isNumeric(age, "Please Enter Only Number for Age!")){
return true;
}}}}}}}}
return false;
}
function notEmpty(elem, helperMsg) {
if (elem.value.length == 0) {
alert(helperMsg);
elem.focus(); // set the focus to this input
return false;
}
return true;
}

xcvi
function iswordNumeric(elem, helperMsg) {
var wordnumericExpression = /^[\Wa-zA-Z0-9]+$/;
if (elem.value.match(wordnumericExpression)) {
return true;
}
else {
alert(helperMsg);
elem.focus();
return false;
}}
function isAlphabet(elem, helperMsg)
{ var alphaExp = /^[a-zA-Z]+$/;
if (elem.value.match(alphaExp)){
return true;
} else {
alert(helperMsg);
elem.focus();
return false;
}}
function phoneValidator(elem, helperMsg) {
var emailExp = /^[\w\-\.\+]+\@[a-zA-Z0-9\.\-]+\.[a-zA-z0-9]{2,4}$/;
if (elem.value.match(emailExp)) { return true;
}
else {
alert(helperMsg);
elem.focus(); return false;
}}
function lengthRestriction(elem, min, max){
var uInput = elem.value;
if (uInput.length >= min && uInput.length <= max) {
return true;

xcvii
}
else {
alert("Please Enter Between " + min + " upto " + max + " Characters for Username!");
elem.focus(); return false;
}}
function lengthRestrictionforpassword(elem, min, max){
var uInput = elem.value;
if (uInput.length >= min && uInput.length <= max) {
return true;
}
else {
alert("Please Enter Between " + min + " upto " + max + " Characters for Strong
password!");
elem.focus(); return false;
}}
function isNumeric(elem, helperMsg) {
var numericExpression = /^[0-9]+$/;
if (elem.value.match(numericExpression)) {
return true;
}
else {
alert(helperMsg);
elem.focus();
return false;
}}
</script>

6.6 Implementation of User Interface


Our system is built with a user interface they should match and satisfy the skills and
expectations of its users. There are many human factors we have considered before
designing an effective interface. It is natural that users make mistakes when they use new

xcviii
interface and things like alarms or messages might panic the user and will become the
reason for more mistakes. The system has consistent user interface when navigating
through the pages.

xcix
1. Login page

c
2. Admin Home page

6.7 Testing
Developing software is a complex process. No matter how hard we try to eliminate all
faults simply by going through the phases of requirements, design and implementation,
however through good practice we can make sure that most series fault does not occur in
the first place. In addition, we need a separate testing phase with the goal of elimination
all remaining faults before release.

ci
6.7.5 Testing Tools and Environment
Testing tools are important for the success of testing phase and naturally the
success of product. In our unit testing phase Sublime Text3, Google Chrome and
XAMPP are used.
Sublime text3:- is used to edit PHP, HTML, JavaScript and CSS code.
XAMPP: - is an open source tool used to handle the administration of MYSQL
database. It allows user to view, modify, add and delete tables and their records in
database. This tool will be used in order to check the correctness of the database
and database related part of the project.

6.7.6 Unit Testing


It is done at the source or code level for language-specific programming errors
such as bad syntax, logic errors or to test particular functions or code modules.
The unit test cases shall be designed to test the validity of the program’s
correctness. It is a way of testing each of the system functionality independently.
Accordingly the team has tested each one of the systems activities and the rest
accompanying activities independently using different user input, different login
mechanisms and any technique of fault finding so that an incorrect functioning of
the activities was corrected at the right time.

cii
6.7.7 Integration Testing
We have the specific permissions related to each user type (authorization) and
authentication mechanism. Our integration testing procedure is given below.
 Firstly, we will create users who have role types namely student or
instructor or admin.
 Then we will login with the user name and password of each user. This
tests whether the authentication mechanism works correctly.
 Then we will also try some wrong user name and/or wrong password. We
expect an error message by trying this case.

ciii
CHAPTER – SEVEN

7 CONCLUSION AND RECOMMENDATION


7.2 Conclusion
Our general objective is to develop Web-based STEM management system for Wolkite
University. In order to solve different problems of the existing system we tried to develop
this system. We believe that different tools and techniques have helped us a lot in
capturing real user requirements and model the right system for the users to perform their
activities. This project is developed for Wolkite University in order to give efficient,
reliable, timely, available, secured and easily accessed.

7.3 Recommendation
According to the scope of our project the team develops web-based application. Due to
time limitation we can’t do all the tasks that are needed in the system so to enhance the
performance and functionality of the system our team believes that this system should be
fully operationally by adding some functionality that are not included in the proposed
system. We recommended also the next developer can include the following tasks:-
 Developing online exam (Evaluation Questions) Modules.
 Developing Generate Exam scheduling modules.
 Satisfaction form for the students.
 Develop Agreement Form.

civ
Bibliography

[1] E. J.Hom, "Home," 11 February 2014. [Online]. Available: www.livescience.com.


[Accessed 2019].

[2] "Home," 2018. [Online]. Available: www.STEMpower.org. [Accessed 2019].

[3] "Research," 5 May 2018. [Online]. Available: www.Wolkite University.com. [Accessed 10


November 2019].

[4] "About Us," 22 April 2018. [Online]. Available: www.Wolkite University.com. [Accessed
November 2019].

[5] "SDLC Tutorial," [Online]. Available: www.tutorialspoint.com.

[6] "topics/engineering/functional-requirement," 12 February 2016. [Online]. Available:


https://www.sciencedirect.com/. [Accessed 21 December 2019].

[7] "wiki/Use_case," 18 December 2019. [Online]. Available: https://en.wikipedia.org/.


[Accessed 29 December 2019].

[8] "artifacts/usageScenario," 27 February 2019. [Online]. Available:


http://agilemodeling.com/. [Accessed 02 January 2020].

[9] "wiki/Class_diagram," 5 December 2019. [Online]. Available: https://en.wikipedia.org/.


[Accessed 30 December 2019].

[10] "wiki/Sequence_diagram," 12 December 2019. [Online]. Available:


https://en.wikipedia.org/. [Accessed 02 January 2020].

[11] "unified-modeling-language-uml-activity-diagrams/," 14 July 2019. [Online]. Available:


https://www.geeksforgeeks.org/. [Accessed 03 January 2020].

[12] "uml/uml_statechart_diagram.htm," 12 March 2019. [Online]. Available:


https://www.tutorialspoint.com/. [Accessed 05 January 2020].

cv

You might also like