College of Engineering, Technology and Computational Science

Department of Computer Science and MIS

Ethiopian Refugee Hosting Management System

Final project document

Submitted to the Department of Computer Science and MIS in partial

fulfilment of the requirements for the degree of Bachelor Science in
Computer Science.

By:

Amanuel Yemane (UU77223R)

Biniam W\michael (UU77357R)
Bereket Belete (UU77477R)
Hailemedhin Kassaye (UU77322R)
Nathnael Tadesse (UU77420R)

Advisor:
Ato Getahun Gezu

June, 2022
 Ethiopian Refugee Hosting Management System

Final project document

Submitted to the Department of Computer Science and MIS in partial

fulfillment of the requirements for the degree of Bachelor Science in
Computer Science

By:

Amanuel Yemane (UU77223R)

Biniam W\michael (UU77357R)

Bereket Belete (UU77477R)

Hailemedhin Kassaye (UU77322R)

Nathnael Tadesse (UU77420R)

Advisor: Ato Getahun Gezu

Examiners:
 Abstract
There are more refugees in the world right now in our modern world than has been ever in history.
Be it because of famine, war, or dissatisfaction, people could become refugees if circumstances
arise. Many countries are thus facing a refugee influx and having to try and solve that problem
could be a financial and resource strain on any nation. Current systems such as government refugee
programs, NGOs, and private voluntary organizations are trying to tackle these problems through
physical refugee sheltering. This endeavour proved to be very expensive, fatiguing, and, at times
impossible to follow. The system we will develop, The ERHMS, is going to approach these
problems differently. It works by providing a platform where refugees and volunteer hosts could
connect and arrange to meet. The platform will provide a means by which the refugees can be
accommodated by a voluntary host in accordance with the terms of agreement of both parties
involved. This way, refugees could find willing hosts in safer areas with absolute zero costs for
the government wing. Not only does our system eradicate the enormous amount of resources
required to maintain the growing number of refugees that are incoming, but also pave the way for
new systems to be developed that address the many obstacles that are present due to the usage of
out-dated institutions. The Development of the ERHMS is going to be user-oriented and focuses
on the user requirements that have been accumulated. It will utilize the various roles and
comprehension of programming and initiative abilities that our team members possess that will
lead to its realization.

i
 Acknowledgements
We would like to express our special thanks of gratitude to our advisor, Mr. Getahun, who gave
us quality guidance and an abundance of advice on how to go about doing this project. We would
also like to thank all the volunteers who agreed to participate in testing the project. Last but not
least, we would like to thank our families for their unending support and encouragement.

ii
 List of Abbreviations

ERHMS – Ethiopian Refugee Hosting Management System

NGO – Non-Governmental Organization
RAD – Rapid Application Development
IDE – Integrated Development Environment
PHP – Hypertext Preprocessor
HTML – Hypertext Markup Language
CSS – Cascading Style Sheets
XAMPP – cross-platform, Apache, MySQL, PHP, and Perl
WBS – Work Breakdown Structure
SRS – Software Requirement Specifications
Cat5 – Category 5
Cat6 – Category 6
ETB – Ethiopian Birr
RMMM – Risk Management Monitoring and Mitigation

iii
 List of Tables

Table 1: Schedule ............................................................................................................................ 5

Table 2: WBS .................................................................................................................................. 7
Table 3: Human Resource Plan..................................................................................................... 10
Table 4: Material Plan ................................................................................................................... 11
Table 5: Human Resource Financial Plan ..................................................................................... 12
Table 6: Material Financial Plan ................................................................................................... 12
Table 7: Project Budget ................................................................................................................ 12
Table 8: Team Organization ......................................................................................................... 13
Table 9: Risk Items ....................................................................................................................... 15
Table 10: RMMM Plan ................................................................................................................. 16
Table 11: chat class ....................................................................................................................... 57
Table 12: user class ....................................................................................................................... 58
Table 13: choose language class ................................................................................................... 59
Table 14: Admin class .................................................................................................................. 59
Table 15: contact class .................................................................................................................. 59
Table 16: Database Design ........................................................................................................... 61
Table 17: Normalized table ........................................................................................................... 62
Table 18: Name Table ................................................................................................................... 62
Table 19: Second normal form ..................................................................................................... 63
Table 20: normalized table for member id .................................................................................... 63
Table 21: normalized table for post id .......................................................................................... 64

iv
 List of Figures
Figure 1.1: Time Schedule Gantt chart ........................................................................................... 6
Figure 2.1: RAD............................................................................................................................ 14
Figure 3.1: Essential use case diagram ......................................................................................... 23
Figure 3.2: Admin broadcast page ................................................................................................ 29
Figure 3.3: User Profile................................................................................................................. 30
Figure 3.4: Login Page .................................................................................................................. 30
Figure 3.5: Essential UI prototype ................................................................................................ 31
Figure 3.6: User interface flow diagram ....................................................................................... 32
Figure 3.7: System Use Case Diagram ........................................................................................ 34
Figure 3.8: Create Account Sequence Diagram ............................................................................ 45
Figure 3.9: Login Sequence Diagram ........................................................................................... 46
Figure 3.10: Update Profile Sequence Diagram ........................................................................... 47
Figure 3.11: Logout Sequence Diagram ....................................................................................... 47
Figure 3.12: Delete Account Sequence Diagram .......................................................................... 48
Figure 3.13: Login Activity Diagram ........................................................................................... 49
Figure 3.14: Signup Activity Diagram.......................................................................................... 50
Figure 3.15: Update Profile Activity Diagram ............................................................................. 51
Figure 3.16: Logout Activity Diagram ......................................................................................... 52
Figure 3.17: Delete Account Activity Diagram ............................................................................ 53
Figure 4.1: Mapping class diagram to relation ............................................................................. 60
Figure 4.2: User login page ........................................................................................................... 65
Figure 4.3: User signup page ........................................................................................................ 66
Figure 4.4: Home Page ................................................................................................................. 66
Figure 4.5: Admin Page ................................................................................................................ 67
Figure 4.6: Deployment Diagram ................................................................................................. 68
Figure 4.7: Network Design .......................................................................................................... 69
Figure 5.1: Broadcasting/Sending message Sample code............................................................. 70
Figure 5.2: Sending message sample code ................................................................................... 71
Figure 5.3: Searching sample code ............................................................................................... 71
Figure 5.4: Login sample code...................................................................................................... 72

v
 Appendices
Ethiopian Refugee Hosting Management System (ERHMS) is an online platform that provides a
space for refugees from troubled areas to connect with willing potential hosts in safer areas. This
way, it will provide a means by which the general public can participate in accommodating
refugees from areas of turmoil. The main thing that makes the platform special is that it is based
solely on good will and volunteerism. It is free to use by anyone and that participation is not
mandatory makes the system special.

This is a near costless system that provides a platform to do a priceless service.

vi
Table of Content
Abstract ............................................................................................................................................ i
Acknowledgements ......................................................................................................................... ii
List of Abbreviations ..................................................................................................................... iii
List of Tables ................................................................................................................................. iv
List of Figures ................................................................................................................................. v
Appendices ..................................................................................................................................... vi
Chapter One: Introduction .............................................................................................................. 1
1.1. Background Information .................................................................................................. 1
1.2. Statement of the Problem ................................................................................................. 2
1.3. Objectives ......................................................................................................................... 2
1.3.1. General Objective ..................................................................................................... 2
1.3.2. Specific Objectives ................................................................................................... 2
1.4. Scope ................................................................................................................................ 3
1.5. Tools and Methodology ................................................................................................... 3
1.5.1. Data Collection methodologies ................................................................................. 3
1.5.2. System Development methodologies ........................................................................ 3
1.5.3. Development tools .................................................................................................... 4
1.6. Beneficiaries ..................................................................................................................... 4
1.7. Schedule ........................................................................................................................... 5
Chapter Two: Project Management ................................................................................................ 7
2.1. Introduction ...................................................................................................................... 7
2.2. Work Breakdown Structure.............................................................................................. 7
2.3. Resource Plan ................................................................................................................... 9
2.3.1. Human Resource Plan ............................................................................................... 9
2.3.2. Material Plan ........................................................................................................... 11
2.4. Financial Plan ................................................................................................................. 11
2.4.1. Human Resource Financial Plan ............................................................................. 12
2.4.2. Material/Equipment Financial Plan ........................................................................ 12
2.4.3. Project Budget ......................................................................................................... 12
2.5. Team Organization ......................................................................................................... 13
2.6. Process Model ................................................................................................................ 14

vii
 2.7. Risk Management Mitigation and Monitoring (MMM) Plan ........................................ 14
2.7.1. Risk Items Table ..................................................................................................... 15
2.7.2. RMMM Plan ........................................................................................................... 16
Chapter Three: System Analysis ................................................................................................... 18
3.1. Introduction .................................................................................................................... 18
3.2. Current System Overview .............................................................................................. 18
3.3. Proposed System Overview ........................................................................................... 18
3.3.1. Functional Requirements ........................................................................................ 19
3.3.2. Non-functional Requirements ................................................................................. 22
3.4. System Models – Requirement Determination .............................................................. 22
3.4.1. Essential Use Case Modelling ................................................................................ 22
3.4.2. Essential UI Prototype ............................................................................................ 29
3.4.3. User Interface Flow Diagram.................................................................................. 32
3.4.4. Supplementary Specifications ................................................................................. 33
3.5. System Models – Analysis ............................................................................................. 34
3.5.1. System Use Case Modelling ................................................................................... 34
3.5.2. Sequence Diagram .................................................................................................. 45
3.5.3. Activity Diagram .................................................................................................... 49
Chapter Four: System Design ....................................................................................................... 54
4.1. Introduction ........................................................................................................................ 54
4.2. Design Goals ...................................................................................................................... 54
4.3 Design Trade-offs ................................................................................................................ 55
4.4 Subsystem Decomposition .................................................................................................. 56
4.5 Design Phase Models .......................................................................................................... 57
4.5.1 Class Modelling ............................................................................................................ 57
4.5.2 Persistent model ............................................................................................................ 60
4.5.3 User Interface Design ................................................................................................... 64
4.5.4 Deployment Diagram ................................................................................................... 67
4.5.5 Network Design ............................................................................................................ 69
Chapter 5: Implementation ........................................................................................................... 70
5.1 Introduction ......................................................................................................................... 70
5.2 sample code ......................................................................................................................... 70

viii
Chapter 6: Conclusion and Recommendation............................................................................... 73

ix
 Chapter One: Introduction

The Ethiopian Refugee Hosting Management System (ERHMS) is a website that provides a
means of coping with refugee crisis in our country through the involvement of the general public.
It works by providing a platform for refugees and volunteer hosts to communicate, thus, enabling
the public in safe areas to voluntarily host refugees from unstable places.

ERHMS involves creating separate types of accounts for refugees and volunteer hosts, providing
data – name and location – about both the host and refugee and also has a chat room where the
users can communicate. For the safety of both sides of the interaction the information that is
made public will only be their name and city of residence. Users can share more detailed
information through the chat room.

1.1. Background Information

Refugees At Home is a company located in London, England that provides a platform for willing
citizens to host refugees and asylum seekers from all over the world. It’s a non-profit company
that is mostly crowd-funded.

The company’s services are open for anyone to use as long as they fulfil certain criteria for both
refugees – called “guests" on the website – and for hosts.

Refugees At Home's system works as follows:

 Users – both guests and hosts – register on the website by filling a form.

 The system creates accounts for users who successfully registered.

 The system provides a means for the users to search for other uses to interact with.

 The system provides means of communication for the users.

1
 1.2. Statement of the Problem

In Ethiopia’s case a refugee hosting system that uses volunteers from the public as the host is
non-existent. This lays the burden of hosting refugees solely on the government – whom can only
do as much as the means of the country allows them will only result in slums for camps.
Therefore, creating overpopulated refugee camps that are a health hazard to the very people
taking refuge within them. The Currently existent camps don’t put in to account the fact that
refugees come from different cultural backgrounds is crucial to keep the hosting process trouble-
free. Consequently, internal disputes may arise in the settlements due to confusion and
dissatisfaction. Accommodations such as shelter, clothing, food and medicine are scarce due to
the hardships of maintaining funds required for sustaining the settlement programs. These funds
usually come from government aids, NGOs, and private organization donations, which are hard
to come by these days. Allocating land property for the settlement programs is an essential if not
an integral part of the whole hosting process. This undertaking is very challenging by reason of
land ownership expenses and policies related to it. Accordingly, it is near to impossible to not
only accommodate the already accepted refugees but also to accept the growing number of
displaced people.

1.3. Objectives

1.3.1. General Objective

Our general objective is to develop an online Ethiopian Refugee Hosting

Management System (ERHMS) that will alleviate the complications of refugee
acceptance and accommodation procedure.

1.3.2. Specific Objectives

✓ Analysing current systems in order to identify the system requirements.

✓ Gathering requirements for designing the system.
✓ Designing or modelling an online ERHMS.
✓ Testing, validation and implementation of the system.

2
 1.4. Scope

ERHMS will attempt to help solve refugee crisis specifically for Ethiopian internally displaced
peoples. In an effort to ease the strain of having too many refugees to deal with the ERHMS will
solve the hassle of overpopulated camps, accommodative scarcity and resource allocation
predicaments by creating a platform by which multitude of volunteers can reach the refugees and
offer housing, nourishment, treatment, therapy and several different aids. As a result, The
ERHMS will diminish the dilemma of refugee hosting services and restructuring it into an
advanced system of caregiving for the displaced community.

1.5. Tools and Methodology

1.5.1. Data Collection methodologies

To collect data, we used the following methods:

i. Interviews

We interviewed people who may be potential users of the system to analyse what assurances the
system needed to provide.

ii. Social media monitoring

We observed extensive social media content regarding the topic from users in our country, this
allowed us to further assess public openness to the project and to also check what concerns they
may have.

1.5.2. System Development methodologies

Since the project is going to be heavily user-oriented; it is required to be user-friendly and will
have to satisfy as many users defined features as possible. All this needs to happen while we stay
true to the relatively short time we have until the deadline is reached.

3
For these reasons we chose Rapid Application Development (RAD) as our system development
method. In order to facilitate user engagement and also be able to finish the project in a relatively
short time.

1.5.3. Development tools

To develop this project, we used the following tools:

I. Text editors

Every group member used various text editors on their machine to do their part of the project.
Like: Sublime, Atom and Visual Studio Code. The text editors were chosen based on each
member's personal preference.

II. Eclipse PHP IDE

We used Eclipse as an IDE version 4.23 for the separate units of the program in order to test them
separately before assembling them into one.

III. MySQL server (community)

We used MySQL community server version 8.0 to separately design and test the needed database
without having to worry about the other web components before combining them all later on.

IV. XAMPP server

To test the final prototypes – after assembling the whole units – we used XAMPP server version
7.4.23, since it can service both the web application and the database parts at once.

1.6. Beneficiaries

The system will be beneficial in the following ways:

 Non-compulsory:

Only volunteers will be able to participate in the program, thus not straining the public with
unpopular demands.

 Nearly cost-less:

4
 The only type of funding the system needs to operate will be maintenance, which doesn’t
count as much of a cost considering the service it provides.

 Simplifies a rather burdensome task:

Because of the highly costly nature if the current way of dealing with refugees, the emergence
of this project will largely save on government costs.

As for whom benefits from the project, there are two broad beneficiaries – the government and
the general public.

1.7. Schedule

Table 1: Schedule

No. Task Name Start Date Finish Date Duration Preceding

Task

T1 Project Initiation April 7 April 18 11 days None

T2 Project Management April 19 May 3 14 days T1

T3 System Analysis May 4 May 26 22 days T2

T4 System Design May 27 June 16 20 days T3

T5 Implementation June 17 July 16 29 days T4

T6 Testing July 17 August 1 15 days T5

Since the schedule flows in a strictly linear fashion, the early start and early finish times of each
task are equal to the late start and late finish times which renders the slack time equal to zero.

5
Figure 1.1: Time Schedule Gantt chart

6
 Chapter Two: Project Management

2.1. Introduction

This chapter of the project document provides the systems project management. This chapter
contains and elaborates project planning (work breakdown structure), resource planning,
financial planning, team organization, process model and risk planning.

It is important to have knowledge about modern management on top of understanding the design
and deployment process. Web based Systems have particular objectives and constraints like a
required time frame for completion. And the development cost is significant. Web based systems
are usually prone to change. We can’t prevent change, but by applying effective project
management principles, engineers are able to increase the probability of success in the change
process. The three-primary target of the web-based system which are Cost, Time and
Performance are most likely to be prone to risk and uncertainty. So, the lack of effective project
management is a major contributor to the failure of a project.

2.2. Work Breakdown Structure

Our work breakdown structure is organised into four phases – Initiation, Planning, Execution and
control, closing – and is shown as follows:

Table 2: WBS

Task Task Name

Number

Phase 1:

1 Initiate Project

1.1 Develop Project Charter

1.1.1 Define Scope

7
1.1.2 Define Requirements

1.1.3 Identify Roles

1.1.4 Develop Budget

1.1.5 Identify Control Strategies

1.1.6 Finalise Charter and Gain Approvals

1.1.6.1 Revise Project Charter

1.1.6.2 Gain Approvals

Phase 2:

2 Plan Project

2.1 Develop Work Plan

2.1.1 Develop Work Breakdown Structure

2.1.2 Develop Project Staffing Plan

2.1.3 Develop Project Schedule

2.1.4 Develop Project Budget

2.2 Develop Project Control Plan

2.2.1 Develop Communication Plan

2.2.2 Develop Quality Management Plan

2.3 Finalise Project Plan and Gain Approvals

Phase 3:

3 Execute and Control Project

3.1 Design Framework

3.1.1 Define framework stages and activities

8
 3.1.2 Design framework content formats

3.2 Build the Framework

3.2.1 Write the framework content

3.2.2 Review framework content for quality

3.2.3 Build prototype

3.3 Test the Framework

3.3.1 Test usability of the prototype

3.3.2 Test usability of content

3.3.3 Adjust framework based on user feedback

3.4 Implement Framework

Phase 4:

4 Close the Project

4.1 Conduct the Project

4.2 End

2.3. Resource Plan

We are preparing a resource plan to generalize the resources needed to complete the project. A
well-documented resource plan is the exact number of human resources and materials needed to
complete our project.

2.3.1. Human Resource Plan

The human resource plan in our project consists of the type of the resource or the personnel, how

9
many people work on a specific task, their qualification and responsibilities according to the
project requirements specified.

Table 3: Human Resource Plan

Human Resource Number Qualification(s) Responsibilities

Type

(Role)

Project Manager 1 Decent skills on Provide leadership,

team building,
Overseeing the entire project,
management and
organisation. Managing the budget,

Adept at planning Develop project plan,

work. Estimate costs

Requirement 2 Good analysis Formulate research questions,

Analyst skills,
Provide suggestions and feedback
Good knowledge on the methodology,
on web
Gathering requirements,
development.
Structuring requirements,

Prepare the Software Requirement

Specifications (SRS),

Interact with/guide the

programmers.

Programmer 2 Knowledge of the Study project deliverables,

software tools
Develop prototypes,
needed to build the

10
 project (PHP, Test the prototypes,
MySQL, HTML
Study user feedback,
and CSS).
Improve the prototypes,

Develop the final program

2.3.2. Material Plan

Table 4: Material Plan

Items Quantity Details Description

Laptops 2 Core i7 & Core i5

Will be used to write and test the code for
processors, 8GB
the system and to prepare all the
RAM and 1 TB
documentations of the system.
storage

Cables 2 Cat5 and Cat6 Used to connect the computers to wall

sockets to access some packages from the
internet

Software 4 XAMPP, Used to write program code, test/run

written programs, design graphical
Microsoft Office,
components, write reports on progress.
Adobe Photoshop,

Various text editors.

2.4. Financial Plan

A financial plan is prepared to identify the amount of money required. A financial plan entails
the total cost of labor and the hardware needed for the project.
11
 2.4.1. Human Resource Financial Plan

Table 5: Human Resource Financial Plan

Human Resource Financial Costs

Role Number Salary per project contract

Project Manager 1 10,000 ETB

Requirement Analysts 2 16,000 ETB (combined)

Programmers 2 12,000 ETB (combined)

2.4.2. Material/Equipment Financial Plan

Table 6: Material Financial Plan

Item Quantity Unit Price Total Price

Laptops 2 40,000 ETB 80,000 ETB

Cables 2 400 ETB 800 ETB

Software 4 0 ETB 0 ETB

Internet Service 4,000 ETB 4,000 ETB

Total 44,400 ETB 84,800 ETB

2.4.3. Project Budget

Table 7: Project Budget

Cost Type Estimated Cost Actual Cost

Human Resource Costs 35,000 38,000

Material Costs 90,000 84,800

Total 125,000 122,800

12
Summing it up, when estimating the costs for human resources we had allocated 35,000 ETB the
actual cost was 38,000, which left us with a deficit of 3,000 ETB. When estimating the costs for
materials/equipment we had a cost estimate of 90,000 ETB the actual cost ended up being 84,800
ETB, which left us with a surplus of 5,200 ETB.

Overall, we had a budget of 125,000 ETB for the project and ended up having to spend 122,800
ETB, this in turn meant that we have a surplus of 2,200 ETB.

2.5. Team Organization

The team organization selected for our project is a specifically designed type that utilizes both
voting and hierarchy.
The team consists of members with roles that have a hierarchical value. There are 3 roles: a single
Project Manager and 4 personnel working as both Analysts and Programmers. The group system
works as follows:
At the bottom are the Analysts and Programmers each of them having a single vote on matters
equalling a total of 4 votes, and at the top of the hierarchy is the project manager with the right
to make the ultimate decision in case of disagreements within the group. This absolute power
however, can only be exercised as long as there is a disagreement within the other 4 group
members. Any unanimous agreement between all four members should be exercised regardless
of the Project Manager’s opinion.

Table 8: Team Organization

Team Members Position Address

Biniam W/Michael Project Manager Email: binijoe4@gmail.com
Phone: +251 92 728 7309
Amanuel Yemane Analyst and Programmer Email: aleisteryemane@gmail.com
Phone: +251993946846
Hailemedhin Kassaye Analyst and Programmer Email: hailemedn@gmail.com
Phone: +251 95 498 8027
Bereket Belete Analyst and Programmer Email: Bereketasress@gmail.com
Phone: +251 96 719 9719

13
 Nathnael Tadesse Analyst and Programmer Email: nati1stonegaudi@gmail.com
Phone: +251 93 167 8242

2.6. Process Model

Due to the nature of our group’s members and the relatively short time constraints that has been
laid upon us, we chose Rapid Application Development (RAD) as our process model.

RAD Model is a software development process based on prototyping without any specific
planning. In RAD model, there is less attention paid to the planning and more priority is given
to the development tasks. It targets at developing software in a short span of time.

Figure 2.1: RAD

2.7. Risk Management Mitigation and Monitoring (MMM) Plan

Risk analysis and management are a series of steps that helps a software team to understand and
manage uncertainty (Hoofer, Jeffrey A; Joey F George and Joseph S.Valacich 2000). A risk is a
potential problem; it might or might not occur. It is a good approach to identify risk, asses its
probability of occurrence, estimate its impact, and establish a contingency plan should the
problem actually occur.

14
 2.7.1. Risk Items Table

Table 9: Risk Items

Risk Description Impact

Time Shortage Lack of enough time to finish the Critical

project

Budget Shortage Lack of enough monetary resources Fatal

for the project

Lack of community acceptance Users not being interested in using the Critical
system

Lack of software development Our team not being able to implement Critical
skills the project

End user illiteracy Users not knowing how to use the Critical
system

Server and connection failure A server or connection failure either as Critical

a result of human or design errors

Infrastructure cost overrun Cost of hosting the project getting out Critical
of hand

Critical risks are risks that could harm the project but isn’t a threat to its existence altogether,
while fatal risks are the ones that could totally collapse the project should they occur.

15
 2.7.2. RMMM Plan

Table 10: RMMM Plan

Risk Name: Time Shortage Probability: Likely

Description: Lack of enough time to finish the project
Risk Mitigation: Risk Monitoring: Risk Management:
Set realistic timeline for tasks Check if project progress is Do some elements of the
and maintain team morale going in sync with planned project that are not co-
schedule dependent in a parallel
timeline
Responsibility of: Biniam W/Michael
Risk Name: Budget Shortage Probability: Mildly Likely
Description: Lack of enough monetary resources for the project
Risk Mitigation: Risk Monitoring: Risk Management:
Set a realistic budget with Check remaining budget Make purchase adjustments
careful consideration for the whenever a purchase has to not overspend on a single
prices of items or services been made asset or tool
needed
Responsibility of: Bereket Belete
Risk Name: Lack of community acceptance Probability: Mildly Likely
Description: Users not being interested in using the system
Risk Mitigation: Risk Monitoring: Risk Management:
Check community openness Keep monitoring social Adjust project marketing to
before starting the project trends to see community appeal to community interests
interests
Responsibility of: Hailemedhin Kassaye
Risk Name: Lack of software development Probability: Unlikely
skills
Description: Our team not being able to implement the project
Risk Mitigation: Risk Monitoring: Risk Management:

16
Check our knowledge of and Check how often bugs are Keep learning from online
skills on the programming found in a single unit in the forums as we develop the
languages, frameworks and project project
tools
Responsibility of: Amanuel Yemane
Risk Name: End user illiteracy Probability: Very Likely
Description: Users not knowing how to use the system
Risk Mitigation: Risk Monitoring: Risk Management:
Learn users’ UI preferences Observe new users’ ability to RM1. Provide tutorials for
before implementing the learn the UI new users
project
RM2. Adjust the UI to be
more user friendly
Responsibility of: Nathnael Tadesse
Risk Name: Server and connection failure Probability: Mildly Likely
Description: A server or connection failure either as a result of human or design errors
Risk Mitigation: Risk Monitoring: Risk Management:
Purchase or develop a fault Monitor how often Quickly identify the cause
tolerant system or component disturbances in the and repair or replace it
connection occur
Responsibility of: Amanuel Yemane & Biniam W/Michael
Risk Name: Infrastructure cost overrun Probability: Likely
Description: Cost of hosting the project getting out of hand
Risk Mitigation: Risk Monitoring: Risk Management:
Choose cost friendly Monitor monthly costs Downgrade to less costly
infrastructure equipment without
compromising functionality
Responsibility of: Bereket Belete & Hailemedhin Kassaye

17
 Chapter Three: System Analysis

3.1. Introduction

This chapter of the project documents the system analysis of the project. It contains the current
and proposed system overviews, functional and non-functional requirements of the proposed
system, system models – requirement determination and analysis.

3.2. Current System Overview

Be it on the federal or regional level, there currently exists no system in place that involves the
voluntary accommodation of refugees by the use of the general publics’ participation as the main
resource. So far anything related to refugee accommodation has been – and is still being done – by
government internal ministries and a collection of NGOs, both of which use the traditional way of
dealing with a refugee influx, by building refugee camps in relatively safe areas.

So far there has yet to be a system like ours to be implemented in Ethiopia.

3.3. Proposed System Overview

There are more refugees in the world right now in our modern world than has been ever in history.
Be it because of famine, war or plain dissatisfaction people could become refugees if
circumstances arise. Many countries are thus facing a refugee influx and having to try and solve
that problem could be a financial and resource strain on any nation. When faced with such crises
most countries tend to use the traditional way of mitigating the problem, by building refugee
camps. This, we found, can be problematic cause of the overcrowded nature of said camps, which
could easily become a hotspot for disease.

Instead of using the traditional way of stuffing refugees in refugee camps that could easily get
overcrowded and underfunded, we propose to mitigate the refugee problem through the
involvement of the general public. Our system, ERHMS, works by providing a platform where
refugees and volunteer hosts could connect and could arrange to meet. This way, refugees could
find willing hosts in safer areas with absolute zero costs for the government wing.

18
 3.3.1. Functional Requirements

A functional requirement defines a function of a system or its component.

 Login

Description: If a user has an account they can login provided that they enter the right username
and password.

Input: Username (email) and password.

Processing: Retrieves the provided information and checks if it is valid.

Output: Displays user homepage.

 Logout

Description: If a user is logged into their account they can logout whenever they want.

Input: None needed, just a click on the logout button.

Processing: Logs out of the account.

Output: Displays homepage.

 Create account:

Description: If a user doesn’t have an account and wishes to create one.

Input: Request for first name, middle name, last name, phone number, email, physical address and
password.

Processing: Retrieves the provided information and makes a new account for user.

Output: Displays created account.

 Searching for hosts:

Description: Users search for other users (hosts) to connect with.

Input: Input name and click on search.

Processing: Retrieves the provided information and searches for matching hosts.

19
Output: Displays a list of matching hosts.

 Searching for refugees:

Description: Users search for matching users (refugees) to connect with.

Input: Input name and click on search.

Processing: Retrieves the provided information and searches for matching refugees.

Output: Displays a list of matching refugees.

 Making connections:

Description: Users send a connect request to users of the opposite category they want to
communicate with.

Input: Click on “connect”.

Processing: System registers users as “friends”.

Output: Communication is enabled between the users.

 Breaking connections:

Description: Users tap/click on either “Accept” or “Delete”.

Input: Users tap/click on “Accept”.

Processing: When user taps/clicks on “Accept”, users can communicate through a chat room.

Output: Request sent.

 Uploading a profile photo:

Description: Users can have profile photos.

Input: Users tap/click on “Photo”, select a photo to upload, tap/click “Done”.

Processing: When a user taps/clicks on “Done”, the selected photo gets uploaded to the user’s
profile.

Output: Photo uploaded successfully.

20
  Sending a message:

Description: Users can message each other once they have been connected.

Input: Message is typed and recipient is chosen.

Processing: Message sent to target user.

Output: Display a message delivery report.

 Update profile:

Description: Users can update their profile details.

Input: Asks for profile photo, first name, middle name, last name, phone number, email and
physical address.

Processing: Check the information and process the request.

Output: Profile updated.

 Delete Account:

Description: Users can delete their account when they wish.

Input: Asks for reason and password.

Processing: Remove account from database.

Output: Account deleted.

21
 3.3.2. Non-functional Requirements

 Maintainable: in case of a crash the time required for the system or its component to be
fixed, or adapted to a changing environment should be minimal.
 Reliable: the system should run without a failure for a minimum of 6 months with minimal
supervision.

 Easy to Learn: the website should be easy to learn by new users.

 Secure: assurance that all data inside the system or its part will be protected against
malware attacks or unauthorized access.

 Efficient: The system shouldn’t be overly consuming in time and hardware capacity. It
should work without lags on minimal server capacity.

 User friendly: should have a pleasant frontend design. However this should be as long as
it doesn’t substantially affect efficiency.

3.4. System Models – Requirement Determination

3.4.1. Essential Use Case Modelling

In this section we try to present a complete, meaningful, and well designed from the point-of-
view of users in some roles in relation to a system and that embodies the purpose underlying the
interaction.

22
 3.4.1.1. Essential Use Case Diagram

Figure 3.1: Essential use case diagram

3.4.1.2. Use Case Documentation

 UC01:

Use case: Login

Actor: Admin, Host, Refugee

Description: In this case a user or an admin logs into their account. The user does that by inserting
the details necessary for the attributes of the account.

23
Preconditions: User has an account and is on the Login window.

Post conditions: The user or admin logs into their account.

 UC02:

Use case: Create an account

Actor: Host, Refugee

Description: In this case a user creates an account. The user does that by inserting the details
necessary for the attributes of the account.

Preconditions: User is on the Sign Up window and has an email.

Post conditions: User creates either an account.

 UC03:

Use case: Logout

Actor: Admin, Host, Refugee

Description: In this case users have the ability to logout of their account if they wish.

Preconditions: User is logged in to their account.

Post conditions: User logs out of their account.

 UC04:

Use case: Update Profile

Actor: Host, Refugee

Description: In this case a user updates the details of their account. The user does that by inserting
the details necessary for the attributes for the updates.

24
Preconditions: User is logged in to their account.

Post conditions: User updates their profile details.

 UC05:

Use case: Connect

Actor: Host, Refugee

Description: In this case a user sends a request to another user, after choosing a recipient.

Preconditions: User is logged in to their account.

Post conditions: User gets permission to communicate with another user.

 UC06:

Use case: Disconnect

Actor: Host, Refugee

Description: In this case a user breaks a connection to a selected user.

Preconditions: User is logged in to their account and is connected to another user.

Post conditions: User can no longer communicate with the selected user.

 UC07:

Use case: Send Message

Actor: Host, Refugee

Description: In this case users send a message towards another user with whom they have
established a connection.

25
Preconditions: User is logged in to their account and must have permission to communicate with
the target user.

Post conditions: User sends a message to another user.

 UC08:

Use case: Delete Account

Actor: Host, Refugee, Admin

Description: In this case users have the ability to delete their account if they wish. This is done
after they pass a user verification protocol. Admins also have the option to delete a user.

Preconditions: User or admin is logged in to their account.

Post conditions: User deletes their account or admin deletes an account.

 UC09:

Use case: Post Story

Actor: Host, Refugee

Description: Users have the ability to post a story about anything they wish.

Preconditions: User is logged in to their account.

Post conditions: User posts a story.

 UC10:

Use case: Upload Photos

Actor: Host, Refugee

Description: Users have the ability to post photos which will be visible on their profile.

26
Preconditions: User is logged in to their account.

Post conditions: User posts photos.

 UC11:

Use case: Delete Posts

Actor: Host, Refugee, Admin

Description: Users have the ability to delete their own posts. Admin can delete any post by any
user.

Preconditions: User or admin is logged in to their account.

Post conditions: User or admin deletes a post.

 UC12:

Use case: Report Posts

Actor: Host, Refugee

Description: Users have the ability to report offensive or harmful posts. Admin can view them and
take corrective measures.

Preconditions: User is logged in to their account.

Post conditions: User reports a post.

 UC13:

Use case: View Users’ Profiles

Actor: Host, Refugee

Description: In this case users have the ability to view another user’s profile.

27
Preconditions: User is logged in to their account.

Post conditions: User views the profile of another user.

 UC14:

Use case: Search Users

Actor: Host, Refugee

Description: In this case users have the ability to search for another user using their name.

Preconditions: User is logged in to their account.

Post conditions: User gets a list of other accounts matching their filters.

 UC15:

Use case: Broadcast Message

Actor: Admin

Description: In this case the system administrator sends a message to every single user in the
system.

Preconditions: Admin is logged in to their account.

Post conditions: Admin broadcasts a message.

28
 3.4.2. Essential UI Prototype
In this section we will attempt to represent the general ideas behind the UI for our website. We
will model user interface requirements, requirements that are evolved through analysis and design
to result in the final user interface for your system.

Admin broadcast page

Figure 3.2: Admin broadcast page

29
User Profile

Figure 3.3: User Profile

Login Page

Figure 3.4: Login Page

30
Signup Page

Figure 3.5: Essential UI prototype

31
3.4.3. User Interface Flow Diagram

Figure 3.6: User interface flow diagram

32
 3.4.4. Supplementary Specifications
3.4.4.1. Business Rules
 Valid username and password. If there are login failures, the system should send a
warning email to the user’s email address.
 Loading pictures is a must.
 Public information should be vague about physical addresses – only provide city.

3.4.4.2. Constraints
 The main constraint that affects the project is funding. Since the project is intended to be
a non-profit, it will have to be maintained through donations once deployed. This
jeopardises the project’s survival cause of a reliance on such a fragile source of revenue.
 The main physical constraint of the project is the fact that internet access is a prerequisite
for use. This makes it harder for refugees in less than ideal places.

3.4.4.3. Change Case

 A change case is used to define new requirements or modify the existing requirements to
suite the change that occurs. They are modeled in a simple manner where the potential
change is described, specify the likeliness of the change that occurs, and specify the
potential impacts of the change. Here we have specified some changes that might occur.

Change case 01
Name: users not using the system

Probability: certain, improving the system in time will increase the usability
Impact: High might require to redesign some aspects of the system
Change case 02
Name: Updates and improvements in the system
Probability: certain, improving the system’s usability through time while maintaining normal
activity of the system
Impact: High might require the system to be down for some time
Change case 03
Name: increasing number of users

33
 Probability: certain, long term plan for the system
Impact: medium, requires additional hardware to expand the system

3.5. System Models – Analysis

3.5.1. System Use Case Modelling

In this section we will attempt to represents a discrete unit of interaction between a user (human
or machine) and the system.

3.5.1.1. System Use Case Diagram

Figure 3.7: System Use Case Diagram

34
 3.5.1.2. System Use Case Documentation

 SUC01:

Use case: Create an account

Actor: Host, Refugee

Description: In this case a user creates an account. The user does that by inserting the details
necessary for the attributes of the account.

Preconditions: User is on the Sign Up window and has an email.

Post conditions: User creates either a Host or Refugee account.

Basic course of action:

Basic1: User clicks on “signup”.

Basic2: System displays a form.

Basic3: User fills the form and submits.

Basic4: System verifies if form has been adequately filled.

Basic5: System saves information and logs in on the new account.

Basic6: Use case ends when system displays the home page of a new account.

Alternative course of action:

A.4 System determines that the form hasn’t been properly filled.

A.5 System shows error message and goes back to Basic2.

 SUC02:

Use case: Login

Actor: Admin, Host, Refugee

35
Description: In this case a user logs into their account. The user does that by inserting the details
necessary for the attributes of the account.

Preconditions: User has an account and is on the Login window.

Post conditions: User or admin logs into their account.

Basic course of action:

Basic1: User picks one of two account categories (Host or Refugee).

Basic2: System displays a login screen.

Basic3: User enters their username and password.

Basic4: System validates the information passed.

Basic5: Use case ends when system displays the home page of the user’s account.

Alternative course of action:

A.4 System determines the passed information is invalid.

A.5 System shows error message and goes back to Basic2.

 SUC03:

Use case: Update Profile

Actor: Host, Refugee

Description: In this case a user updates the details of their account. The user does that by inserting
the details necessary for the attributes for the updates.

Preconditions: User is logged in to their account.

Post conditions: User updates their profile details.

Basic course of action:

Basic1: System displays an update profile screen.

Basic2: User updates their details.

36
Basic3: System validates then saves the information passed.

Basic4: Use case ends when system goes back to the user’s home screen.

Alternative course of action:

A.3 System determines the information passed isn’t valid.

A.4 System shows an error screen.

A.5 System goes back to Basic1.

 SUC04:

Use case: Search Users

Actor: Host, Refugee

Description: In this case users have the ability to search for other users narrowed down further by
details provided by the first user’s search options and by the second user’s public information.

Preconditions: User is logged in to their account.

Post conditions: User gets a list of other accounts matching their filters.

Basic course of action:

Basic1: System displays an account search screen.

Basic2: User enters their desired city and number of people.

Basic3: System searches database for matching accounts.

Basic4: Use case ends when system displays accounts matching the details.

Alternative course of action:

A.3 System determines there aren’t matching accounts.

A.4 System shows “no matches” error message and goes back to Basic2.

37
  SUC05:

Use case: Connect

Actor: Host, Refugee

Description: In this case a user connects to another user, after choosing a recipient.

Preconditions: User is logged in to their account.

Post conditions: User gets permission to communicate with another user.

Basic course of action:

Basic1: User chooses a recipient out of the search results from SUC04.

Basic2: User chooses a recipient.

Basic3: User connects to the recipient.

Basic4: Use case ends when system connects the two users.

 SUC06:

Use case: Disconnect

Actor: Host, Refugee

Description: In this case a user disconnects from another user and can no longer communicate with
them.

Preconditions: User is logged in to their account and is connected to another user.

Post conditions: User ceases communications with the other user.

Basic course of action:

Basic1: User selects a connected account they want to disconnect from.

Basic2: User disconnects from the account.

Basic3: Use case ends when system disconnects the accounts.

38
  SUC07:

Use case: Send Message

Actor: Host, Refugee

Description: In this case users send a message towards another user with whom they have
established a connection through the request process.

Preconditions: User is logged in to their account and must have permission to communicate with
the target user.

Post conditions: User sends a message to another user.

Basic course of action:

Basic1: User chooses a recipient.

Basic2: System checks if user has the privileges to communicate with their target.

Basic3: User enters their desired message and sends.

Basic4: Use case ends when system sends message to recipient’s inbox.

Alternative course of action:

A.2 System determines user doesn’t have the privileges to communicate with their target.

A.3 System shows error message and goes back to Basic1.

 SUC08:

Use case: Delete Account

Actor: Host, Refugee, Admin

Description: In this case users have the ability to delete their account if they wish. This is done
after they pass a user verification protocol. Also, admin could delete any user account.

Preconditions: User or admin are logged in to their account.

Post conditions: User deletes their account or admin deletes an account.

39
Basic course of action:

 For User:

UserBasic1: System displays an account deletion screen.

UserBasic2: User enters their reason and password.

UserBasic3: System validates the information passed.

UserBasic5: System removes the account from the database.

UserBasic4: Use case ends when system goes to the index page.

 For Admin:

AdminBasic1: System displays an accounts list.

AdminBasic2: Admin selects to delete an account.

AdminBasic3: System removes the account from the database.

AdminBasic4: Use case ends.

Alternative course of action:

UserA.3 System determines the passed password is invalid.

UserA.4 System shows error message and goes back to Basic2.

 SUC09:

Use case: Logout

Actor: Admin, Host, Refugee

Description: In this case users have the ability to logout of their account if they wish.

Preconditions: User is logged in to their account.

Post conditions: User logs out of their account.

40
Basic course of action:

Basic1: User clicks on the “Logout” button.

Basic2: System shows an “are you sure?” dialog box

Basic3: User clicks on “Yes”.

Basic4: Use case ends when system logs out of the account.

Alternative course of action:

A.3 User clicks on “No”.

A.4 System goes back to the user’s home screen.

 SUC10:

Use case: Broadcast Message

Actor: Admin

Description: In this case the system administrator broadcasts a message to every single user in the
system.

Preconditions: Admin is logged in to their account.

Post conditions: Admin broadcasts a message.

Basic course of action:

Basic1: Admin writes message and clicks “Broadcast”.

Basic2: System sends the message to all user accounts.

Basic3: Use case ends when system shows a “sent” dialogue box.

Alternative course of action:

A.3 Admin doesn’t write anything before they click “Broadcast”.

A.4 System shows an error message and the use case restarts.

41
  SUC11:

Use case: View Users’ Profiles

Actor: Host, Refugee

Description: In this case users have the ability to view another user’s profile.

Preconditions: User is logged in to their account.

Post conditions: User views the profile of another user.

Basic course of action:

Basic1: System shows a list of users.

Basic2: User clicks on the profile photo of an account.

Basic3: System displays the selected account’s profile.

Basic4: Use case ends.

 SUC12:

Use case: Report Posts

Actor: Host, Refugee

Description: Users have the ability to report offensive or harmful posts. Admin can view them and
take corrective measures.

Preconditions: User is logged in to their account.

Post conditions: User reports a post.

Basic course of action:

Basic1: System shows a list of public posts.

Basic2: User clicks on “report” in a particular post.

Basic3: System increments reports count for that post.

Basic4: Use case ends.

42
  SUC13:

Use case: Post Story

Actor: Host, Refugee

Description: Users have the ability to post a story about anything they wish.

Preconditions: User is logged in to their account.

Post conditions: User posts a story.

Basic course of action:

Basic1: System shows a text area for writing story.

Basic2: User writes their story and click on “share”.

Basic3: System forwards that post to every account’s feed.

Basic4: Use case ends.

Alternative course of action:

A.2 User doesn’t write anything before they click “Share”.

A.3 System shows an error message and the use case restarts.

 SUC14:

Use case: Upload Photos

Actor: Host, Refugee

Description: Users have the ability to post photos which will be visible on their profile.

Preconditions: User is logged in to their account.

Post conditions: User posts photos.

Basic course of action:

Basic1: User goes to “photos” page.

43
Basic2: User chooses a photo and submits.

Basic3: System saves that photo to the user’s photos section.

Basic4: Use case ends.

Alternative course of action:

A.2 User doesn’t select anything before they submit.

A.3 System shows an error message and the use case restarts.

 SUC15:

Use case: Delete Posts

Actor: Host, Refugee, Admin

Description: Users have the ability to delete their own posts. Admin can delete any post by any
user.

Preconditions: User or admin is logged in to their account.

Post conditions: User or admin deletes a post.

Basic course of action:

Basic1: User views his own post.

Basic2: User clicks on “delete”.

Basic3: System removes that post from the database.

Basic4: Use case ends.

44
3.5.2. Sequence Diagram

Figure 3.8: Create Account Sequence Diagram

45
Figure 3.9: Login Sequence Diagram

46
Figure 3.10: Update Profile Sequence Diagram

Figure 3.11: Logout Sequence Diagram

47
Figure 3.12: Delete Account Sequence Diagram

48
3.5.3. Activity Diagram

Figure 3.13: Login Activity Diagram

49
Figure 3.14: Signup Activity Diagram

50
Figure 3.15: Update Profile Activity Diagram

51
Figure 3.16: Logout Activity Diagram

52
Figure 3.17: Delete Account Activity Diagram

53
 Chapter Four: System Design

4.1. Introduction
In this chapter we will discuss the system design of our project. System design is the stage where
we define the entire data, interfaces, modules, components and architecture for our system. It is
meant to satisfy the specific needs and requirements of our project.

This chapter will go through the system design process of ERHMS in the following sequence:

• Design goals: are statements on what targets we have set for our system to achieve.
• Design trade-offs: are statements on what compromises we had to make in terms of giving
priority to particular features or components whose quality may bear upon other
features/components.
• Subsystem decomposition: is the part where We break up the system into smaller, easier
to implement subsystems in order to avoid the complexities of dealing with the whole
project all at once. The subsystems are then further decomposed into components, and the
components into smaller well-defined sub-components.
• Class modelling: describes the various domains in the system and the Classes and
instances within them.
• Persistent model
• User interface design
• Deployment diagram: shows what hardware components exist, what software
components run on each node, and how the different pieces are connected.
• Network design

4.2. Design Goals

When designing ERHMS our design goals were:

• Security

Since the system will deal with people who are strangers to each other, it may be open to misuse
by users with malicious intentions. This then requires that the five pillars of security namely:

54
confidentiality, integrity, availability, authenticity and non-repudiation to be of the utmost priority
in our design goals.

• Fault tolerance

The fact that the system will be dealing with situations that require it to be available for use at all
times it shouldn’t be of the kind that could completely go offline cause of minor errors. This
necessitates that the system be fault tolerant, so as to continue working even if small errors occur.

• Performance

The system should be able to run smoothly on relatively minimal hardware. This means the system
should be able to run with smaller processing power compared to other websites of the same scale.

• Maintainability

Whenever there occurs an error which is too serious to be solved by the fault tolerance mechanism,
the design of the system should be in such a way that the error should be identifiable quickly. The
system shouldn’t have redundant codes or modules that could hinder it’s maintainability.

• Open source

Since the project is aimed at helping people in need and not making a profit. The system should
be open source, and thus available for anyone interested to experiment and expand on it.

• Usability

The system should have an interface designed in a way that the user can achieve their objective
efficiently.

• Learnability

The interface of the system should be user friendly and easy to learn. This would avoid
discouraging interested people from using the system cause of a poor interface.

4.3 Design Trade-offs

During the design of ERHMS we had to make the following compromises:

• Performance vs. Aesthetics

55
The better the interface is for a user the more processing power it requires to run. A compromise
is necessary to not make the system so efficient that it has an unpleasant interface but also so user
friendly that the processing power required for the interface ends up making the whole system
slow.

Decision: focusing on performance while not completely neglecting the interface’s user
friendliness.

• Usability vs. Aesthetics

Although the user friendliness of the interface should be maintained. Too much emphasis placed
on aesthetics however, could lead to neglecting the usability of the interface.

Decision: making the interface usable before making it beautiful.

• Security vs. Usability

A user wanting to get a task done will want to have less steps into achieving that task, so having
some security policies on the system will sometimes hinder the usability of it.

Decision: focus on security while finding harmless shortcuts whenever possible.

• Open source vs. Security

Open source projects have their source code available for the public. This could lead to
vulnerabilities being discovered by individuals with malicious intentions, thus putting the whole
project at risk.

Decision: we chose to let the project be open source, reasoning that the chances of a person fixing
vulnerabilities are substantially higher than them exploiting it to cause harm.

4.4 Subsystem Decomposition

Our system, ERHMS, has the following subsystems:

• A search engine: used when a user is searching for a match of the opposing category. This
works by including multiple filters for narrowing down the options.

56
 • Account control: this is used to create an account as well as edit it’s information.
• Connection handler: used when connections are being made and broken.
• Messaging service: used to send private messages between accounts of opposite
categories.
• Session controller: monitors login sessions.
• Application integration: responsible for the connection between all subsystems.
• Universal database: responsible for storing all the data on the system.

4.5 Design Phase Models

4.5.1 Class Modelling
Class Modelling focuses on static system structure in terms of classes (Class, Data Type, Interface
and Signal items), Associations and on characteristics of Classes (Operations and Attributes).

Class diagrams are used to visualize, specify, and document structural features in your models.
Class diagrams are used to perform the following functions:

. Represent and define the structure of classes and other classifiers

. Define relationships between classes and classifiers

. Illustrate the structure of a model by using attributes, operations, and signals.

Table 11: chat class

Chat class

Chat id
Chat receiver
Chat Sender

-view inbox()
-send message()

57
 Table 12: user class

User class

User id
User first name
User last name
User user name
User phone number
User date of birth
User password
Current city
User type

-register()
-login()
-add profile picture()
-update profile()
-post story()
-upload photos()
-logout()
-search for users()
-make connection ()
-break connection()

58
 Table 13: choose language class

Choose language class

Language id
Language name

-pick language()
-change language()

Table 14: Admin class

Admin class

Admin id

-delete user()
-delete post()
-broadcast message()

Table 15: contact class

Contact class

Contact id

-communicate with other users()

59
4.5.2 Persistent model
Persistent objects are stored in a persistence mechanism. Unless your system takes a “pure”
approach and uses an object base, you will need to model your persistent schema. Data models are
traditionally used to model relational database schemas. Most software requires persistent objects.
There is a wide selection of persistence mechanisms like, Flat files, Relational databases, Object-
relational databases, Object bases, first you model something, then you build it. A lot of object
developers need to build relational databases to support their software yet the UML has little to
offer on this issue.

4.5.2.1 Mapping Class Diagram to Relation

The mapping of a UML class to the relational model is straight-forward as long as the UML class
has a complete set of attributes that are well defined. A UML class is mapped to a relation scheme
in the relational model. There are of course several other issues that the mapping needs to address,
such as the mapping of multi-valued attributes, attributes with an enumerated domain, and the
specification of candidate keys and the primary key.

Figure 4.1: Mapping class diagram to relation

60
4.5.2.2 Normalization Database
normalization is a series of steps followed to obtain a database design that allows for consistent
storage and efficient access of data in a relational database. These steps reduce data redundancy
and the risk of data becoming inconsistent. Reason for normalization: to prevent possible
corruption of DB stemming from update anomalies (insertion, deletion, modification).

First normal form (1NF)

A relation in which the intersection of each row and column contains one and only one value is
said to be in First normal form. It requires that all column values in a table are atomic

Table 16: Database Design

Field type

Member id Int (11)

First Name Varchar(30)

Last Name Varchar(30)

Username Varchar(30)

Phone number Varchar(30)

Date of Birth datetime

Password Varchar(30)

Current city Varchar(30)

Status Varchar(30)

To normalize user table, we need to decompose the fields and place other multivalued attributes
into another table. The normalized table becomes:

61
 Table 17: Normalized table

Field type

member id Int (11)

Name Varchar(30)

Username Varchar(30)

Phone number Varchar(30)

Date of Birth datetime

Password Varchar(30)

Current city Varchar(30)

status Varchar(30)

Name Table

Table 18: Name Table

Field Type

Name Varchar(30)

First Name Varchar(30)

Last Name Varchar(30)

Second Normal form (2NF)

Second normal form (2NF) A relation that is in 1NF and every non-primary key attribute is fully
functionally dependent on the primary key. The essence of functional dependence is that if the
existence of something, call it A, implies that B must exist and have a certain value, then we say
that "B is functionally dependent on A." We also often express this idea by saying that "A

62
determines B". Second normal form applies to relations with composite keys (primary key
composed of two or more attributes). A relation with a single attribute primary key is in at least
2NF.

Table 19: Second normal form

username User id post

Composite Keys

member 1 1 Post 1

member 2 2 Post 2

member 3 3 Post 3

member 4 4 post 4

The normalized table becomes:

Table 20: normalized table for member id

User Name User id

Composite keys

member 1 1

member 2 2

member 3 3

member 4 4

63
 Table 21: normalized table for post id

User id Post id

Composite keys

member 1 Post 1

member 2 Post 2

member 3 Post 3

member 4 Post 4

Third normal form (3NF)

A relation that is in 1NF and 2NF, and in which no non-primary key attribute is transitively
dependent on the primary key. A transitive relationship is a relationship of the following form: "If
A implies B, and if also B implies C, then A implies C." Since our tables are in first and second
normal form and there are no transitive dependencies, all our tables are in third normal form.

4.5.3 User Interface Design

Using the acquired knowledge from the background research and the survey it is possible to specify
the features of the ERHMS’s User interface. When designing the user interface some aspects
should be addressed. These are usability and functionality requirements.

4.5.3.1 Usability

System Usability could be described in terms of effectiveness, efficiency and satisfaction.

Effectiveness could be described as the system’s ability to accomplish the tasks that it is meant to
perform. Efficiency means that the system should accomplish the tasks with as little spent time
and effort as possible. Satisfaction is more difficult to measure, but it implies that the users should
be positive about using the system. Learnability refers to how easy it is for the user to learn how
to perform different tasks using the system. Attitude is almost similar to satisfaction, but implies
that the users should enjoy using the system rather than just finding it satisfying. Finally, Flexibility
indicates that the system should be able to adjust to the different user environments that exist.

64
These are aspects that have been considered during the user interface design. After the future
implementation of the project, this design needs to be tested and evaluated to confirm that the
usability requirements are met. An aim has been to reduce the time and the number of clicks that
the user needs to make in order to perform a task in the web portal. Another aim has been to
distinguish as clearly as possible between the different areas of the portal and to make it intuitive
how to navigate in order to achieve the desired goals. The usability aspects also need to be
considered in future stages when the user interface and the technical structure of the system are
developed to make it even more satisfactory and flexible. After the future implementation of the
project portal, the design needs to be tested and evaluated to confirm that the usability requirements
are met.

Figure 4.2: User login page

65
Figure 4.3: User signup page

Figure 4.4: Home Page

66
 Figure 4.5: Admin Page

4.5.4 Deployment Diagram

Deployment Diagram visualizes the topological view of an entire system. It represents the
deployment of the system. A deployment diagram consists of nodes which describe the physical
devices used inside the system. On these nodes, artefacts are deployed. Node and artefacts of a
system participate in the final execution of a system. The deployment diagram maps the software
architecture created in design to the physical system architecture that executes it. The software
systems are manifested using various artefacts, and then they are mapped to the execution
environment that is going to execute the software such as nodes. Many nodes are involved in the
deployment diagram; hence, the relation between them is represented using communication paths.

67
Figure 4.6: Deployment Diagram

68
4.5.5 Network Design

In this section we will show the network design we have chosen for our project. We have chosen
a hybrid design that could easily be scalable and is sustainable for the long term.

Figure 4.7: Network Design

69
 Chapter 5: Implementation

5.1 Introduction
Software implementation is the process of adopting and integrating a software application into
your systems and workflows. It can apply to software as simple as project management. In this
section we see some of the code that construct the whole project. These are not the source code for
the whole project but little snippets of what are included in it.

5.2 sample code

In this section sample code from all over the project included so that anyone who is viewing this
document can see them with ease

1. broadcasting/sending message

The code below shows the code for sending/broadcasting a message to all users from the admin
panel

Figure 5.1: Broadcasting/Sending message Sample code

70
2. Sending message from user to uses

This is another code that enables users to send message to other users

Figure 5.2: Sending message sample code

3. Searching

And this code below implements search functionality to users

Figure 5.3: Searching sample code

71
4. Login code

This code shows the back-end code for the login functionality.

Figure 5.4: Login sample code

72
 Chapter 6: Conclusion and Recommendation
From our time working on this project we found out that that there are a lot of refugees in camps
that are not able to have a decent time during their stay at a country as a refugee in Ethiopia. Using
our website helps many refugees because it gives them to a temporary sense of being or living in
a stable home. people don’t have to be afraid to imagine a stable home to live in, by using our
website they can easily communicate, share information etc. Ethiopian refugee management
system is a great way to create memories, create families, have an everlasting enjoyment with chat
many other features our website brings. We recommend our website for anybody who wants to
access the website and anybody who wants to create memories and have the ability to say I changed
someone’s pain or reduced the suffering they faced, share their information, have a healthy
relationship with others and be the best version of them selves. We recommend and invite others
to study, improve and meet the objectives that we couldn’t meet because so much limiting factors
including but not limited to shortage of time, inexperience and others. some of our ideas are very
basic and easy to understand for this project. So, we advise other developers to check out our
system and improve it because it’s all for the greater good.

73