Haramaya City Civil and Vital Registration System: Chapter One

Haramaya City Civil And Vital Registration System 2014/1
CHAPTER ONE
INTRODUCTION
Civil and vital registration is the continuous, permanent, compulsory, and universal recording
of the occurrence and characteristics of vital events (live births, deaths, marriages, and
divorces) and other civil status events pertaining to the population as provided by decree, law
or regulation, in accordance with the legal requirements in each country. Also, civil and vital
registration is the system by which a government records the vital events of its citizens and
residents. The resulting repository or database is called civil register or registry, or population
registry. The primary purpose of civil registration is to secure individuals with recognition of
their legal identity and protect the civil rights of individuals. A secondary purpose is to create a
data source for the compilation of vital statistics. In most countries, there is a legal requirement
to notify the relevant authority of any life event which affects the registry. The first nation to
establish a nationwide register over its population was Sweden in 1631. This register was
organized by the church of Sweden but on the demand of the crown.
Haramaya city civil and vital registration system will be a web based system which improves
the issuance of copies of government certificates and legal documents of Haramaya city. It also
helps to the residents of Haramaya city to apply for their birth, marriage, divorce and death
certificates. The main purpose of this project is to develop a system that automates the civil and
vital registration of Haramaya city and to avoid unwanted rushes for searching manual
documents whenever it is needed by different bodies. Additionally, it also creates smooth
working schedule at different kebele along with the city office.
At the end, the computerized civil registry database could be the final outcome of the project.
1.1. Background
Alemaya (also transliterated Alem Maya; Oromo: Haramya is a city in east-central Ethiopia
Located in the Misraq Hararghe Zone of the Oromia Region. Haramaya is bordered on the
south by Kurfa Chele, on the west by Kersa, on the north by Dire Dawa, on the east by
Kombolcha, and on the southeast by the Harari Region. Haramaya is home to Haramaya
1
5
University (formerly Alemaya University). Haramaya city municipal was originally established
in 1962 E.C. Due to the Ethiopian city reformation, in 1997 Haramaya city become one of the
level B cities of the country. Based on recent figures from the Central Statistical Agency,
Haramaya has an estimated total population of 15,317 of whom 7,796 are men and 7,521 are
women. It is the largest of three towns in Haro Maya woreda. Formerly, the city had five
kebeles. But currently, the city has three kebeles (kebele 01, kebele 02 and kebele 03-Bate).
The city has different sectors in each kebele that works diligently to make sure that the policies
and strategies of the country as well as serving the community through sustained good
governance. The city shall also have target to make continual record on civil and vital
registration for its citizens.
1.2. Review of Related Work (Literature Review)

Lots of related works have been done in the area of civil and vital registration across different
country. In the mean time, in our country we couldn’t find complete work on this area because
most of the works are ongoing in different cities across the country. Different countries have
different ways of registering their citizens’ vital events. Among them we take Sweden as it was
the first country that started registering its citizens.
In Sweden, the civil registry is maintained by the Swedish Tax Agency; up into the 1990s the
Church of Sweden was responsible. The administration of the population registry was
transferred from the church to the tax agency on July 1, 1991, due to the upcoming separation
of church and state. Recording of births and deaths was stipulated in the early 17th century,
formal national censuses have been made since the mid-18th century, and Sweden has one of
the longest and most comprehensive suites of civil records of any country. As Finland was part
of the Swedish kingdom from the high middle Ages to 1809, and its laws and administration
were recognized by the Tsar after the country had been ceded to Russia, the country shared the
Swedish system of civil records and these have developed on lines broadly similar to Sweden
into the present age.
Population registration in Sweden is the civil registration of vital events (e.g. births, deaths,
and marriages) of the inhabitants of Sweden. The data is kept in the population registry and is
administered by the Swedish Tax Agency. The registry spans back several centuries and is thus
often used by genealogists. One can order a registry extract about oneself, and one is entitled to
obtain all records of oneself in the registry according to different rules. The information is
publicly available, except for people needing secrecy, such as people threatened with violence.
The address shall be where the person usually sleeps. For a person having two such places, the
one where the family lives should be selected. People who have a temporary residence for less
than six months do not need to register a movement to that address. All residence longer than
2
5
that, including education and temporary work assignment, shall be registered as address (unless
living regularly with the family).
Generally Sweden has been benefited because of having comprehensive suites of civil records.
Source Information: GenWeekly, New Providence, NJ, USA: Genealogy Today LLC, 2006
1.3. Statement of the problem

Haramaya city municipal is doing a great job on registering civil and vital registration for its
citizens. Even though they are doing great, it is necessary to fill out some spots that happen
because of the current system. At this time, they exercise labor-intensive based system to
register, search, distribute and report on vital status for their citizens. In the main, they don’t
have automated civil registry database. These problems are going to lead Haramaya city
municipal to give unsatisfactory service to the community. That is why we need a system that
finds a way to automate the system using most recent civil registry technique that is proficient
in the developed world. This makes the services civil and vital registration of Haramaya city
more efficient and scientific.
1.4. Objectives
1.4.1. General Objective
General objective of the proposed system that we are going to develop is to automate the
current manual based system and to put web based civil and vital registration for Haramaya
city into service so that the civil recognition is insured.
1.4.2. Specific Objective

Our project has the following specific objectives.
 To study the current working structure of municipal of Haramaya city.

 To develop automated civil registry database for Haramaya city.
 To grant accounts for authorized personnel’s of Haramaya city municipal and kebele
administrators.
 To automate registration of citizens of Haramaya city.
 To give brief and genuine reports of population distribution of Haramaya city.
 To develop registration of events- focusing on the registering of live births, marriages,
divorces and deaths.
 To develop certification of events- issuing original live births, marriages, divorces and
deaths, and providing copies to individuals when needed.
 To create a user friendly interfaces for Haramaya city employers and residents.
 To reduce the work load of employers of Haramaya city municipal.
3
5
1.5. Methodology
1.5.1. Data Collection Methodology
We used interview, observation and previous documents to collect data that are necessary to
develop our proposed system.
Interview
We had a continuous contact with the chief of the Haramaya city municipal and other staff
members under him in order to make interview with them. Accordingly, our questions were
appropriately answered.
Observation
We observed the current working system of Haramaya city municipal and we mark the
drawbacks that our system is going to solve.
Previous documents
We were continuously glancing, understanding and reviewing the previous documents of the
Haramaya city municipal to identify the problems that our project is going to solve.
1.5.2. System Development Methodology
We are going to use waterfall system development methodology to develop our new system.
While we are developing the system, we found that our project is suitable to follow a strict path
through the development process not moving on to the next phase until the previous stage has
been completed. This is the reason why we choose waterfall system development
methodology.
1.5.3. System Development Tool
1.5.3.1. Web Development Tool
PHP5 with CAKEPHP framework
Hypertext Pre-processor (PHP) is an open source Scripting language. PHP5 is considered for
the project due to some previous knowledge of the scripting language as well as wish for
expanding and improving knowledge and understanding of developing different webs using
this scripting language.
CakePHP is the most popular mature frameworks for PHP. The framework is based on an
MVC-like architecture that is both powerful and easy to grasp: controllers, models and views
4
5
guarantee a strict but natural separation of business logic from data and presentation layers
This architecture can greatly improve the maintainability of the proposed system.
JQuery magistrate witiness
There are a lots of other JavaScript frameworks out there, but jQuery seems to be the most
popular, and also the most extendable.
JQuery takes a lot of common tasks that requires many lines of JavaScript code to accomplish,
and wraps it into methods that you can call with a single line of code.JQuery also simplifies a
lot of the complicated things from JavaScript, like AJAX calls and DOM manipulation.
Java Script
JavaScript is used to add functionality, validate forms, communicate with the server, and much
more in the proposed system.
CSS
CSS (Cascading Style Sheet) is used for describing the presentation of semantics (the look and
formatting) of a document written in a markup language. It’s most common application is to
style web pages written in HTML and XHTML. This is used to prepare the layout of the GUI
(Graphical User Interface).
1.5.2.2 Database Development Tool
MySQL version 5.0.51b

Since MySQL is a popular choice of database for use in web applications, we choose to use
MySQL server as our database server. It is open source relational database management system
(RDBMS) having the following features:
 Because of its unique storage engine architecture, MySQL’s performance is very

high.
 Allows transactions to be rolled back, commit and crash recovery.
 It is secure means MySQL includes solid data security layers that protect sensitive
data from intruders.
 Use of Triggers, Stored procedures and views which allows the developer to give a
higher productivity.
 It's inexpensive: MySQL is included for free with NetWare® 6.5 and available by
free download from MySQL Web site.
5
5
1.5.2.3 System development Environment
Wamp server version 4.0
Wamp installs Apache, PHP, MySQL database and phpMyAdmin on your computer
automatically. This development environment is used to develop web application. It is simple
but powerful web development compared with other. The other factor is it is free and open
source.
Sublime text editor
Sublime text editor makes writing codes fast and easier because of its coloring and automatic
completion plus it is free.
1.5.2.4. Hardware description

Computer with 4 GB (gigabyte) RAM, 300 GB Hard Disk Drive, and CORE I3 processor are
the minimum requirement.
1.6. Scope and Limitation

1.6.1. Scope
Civil and vital registration for Haramaya city is a system which is designed to automate the
current system of the organization and to make computerized civil recognition only for the
Haramya city. The system works on registering legal residents of the city and creates a
computerized record of vital events like birth, marriage, divorce and death. It also supports
requesting and issuing of certificates of birth, marriage, divorce and death.
1.6.2. Limitation
The proposed system has limitations which are not able to solve by this project. Our system
doesn’t support searching for legal citizens using finger prints and face recognitions. It is also
not available outside Haramaya city.
1.7. Significance of the project

The significance of this project is invaluable not only for Haramaya city municipal but also for
the community as well. It is obvious that Ethiopia as a developing country will be benefited
from this kind of project a lot. Because as the living standard and technology boosted;
advanced civil and vital registration system is crucial for a city or a country as a whole. This
project will help to overcome problems that are happening now and that might happen in the
future. In the main, our new project is capable of registering and updating information on a
daily bases (instead of weekly or monthly or yearly) and make daily retrievals and from the
system, such that the freshness of the data and thus the quality of retrievals and enquiries has
6
5
improved markedly which is not achievable using the current system. Since civil registry
databases will be used by government and nongovernmental organization for different
purposes, this project develops a system which is secured, fault tolerant and capable of
retrieving information about every city citizen using personal identification number as well as
name. In citizen’s perspective, the major benefit to the residents of Haramaya city is to get
efficient civil and vital events related services like online request for birth certificates, marriage
certificates, divorce certificates, and death certificates compared to the old system. The project
is also significant over the current one in terms of time and energy consumption of employers
and residents of Haramaya city municipal.
1.8. Work breakdown

The following table shows the breakdown of the documentation of Haramaya city civil and vital
registration system.
7
5
Months
Until Nov Nov Dec Dec Jan Jan Jan Jan
Nov 21- 28- 9-20 26- 8-10 11 10-12 13-14
20 25 Dec 6 Jan 6
Chapters Activity
Data Collection
from Haramaya
City Municipal
Chapter Introduction
One
Submit Draft
document
Chapter System
Two Requirement
And
Specification
Submit Draft
document
Chapter System
Three Modeling And
Data Description
Submit Draft
document
Chapter System Design
Four
Submit Draft
document
Finalizing Final Document
Review With
Our Advisor
Final Document
8
5
Submission to
The Department
Preparing Slide
For Presentation
Presentation
Table 1: work break down
CHAPTER TWO
SYSTEM REQUIREMENT AND SPECIFICATION

In this chapter, we are going to overview the existing and proposed system of Haramaya city
civil and vital registration system with its practicability.
2.1. Existing System

The existing system of Haramaya city civil and vital registration system is entirely manual. In
the mean time the city municipal is giving two main services namely registering and issuing
birth, death, marriage and divorce certificate for the residences, but all information are
recorded on paper. As a result, the current system becomes poor in providing services to the
community. This leads citizens of Haramaya city to wait several days as the likelihood of
finding the required information.
2.2. Proposed System

2.2.1. Overview
The proposed system is to design and implement automated Civil and vital registration for the
city. The proposed system will be distributed web based application in which the civil registry
is stored in the central database in city municipal then all kebeles of the city will have access to
this central database to record, update, and retrieve required data and information. English
language is going to be used to make the Graphical user interface in order to accesses the
system easily and user friendly. As a result, the proposed system will become well-built in
providing services to the community. This makes modern and genuine civil recognition for the
Haramaya city residents.
2.2.2. Functional Requirement

Registration
9
5
 The system must able to register information of the residents of Haramaya city.
 The system must able to register and update vital events (typically includes live births,
marriages, divorces and deaths) of residents of Haramaya city.
Account management
 City administrator must be able to add/create kebele administrators.
 City administrator must be able to remove kebele administrators.
 The system provides environment for creating and modifying user accounts.
Searching
 The system must be able to search using personal identification number as well as name.
Requesting vital certificate
 Allowed users are capable of requesting birth, marriage, divorce, and death certificates.
Reporting vital concerns
 The system must be able to report birth, marriage, divorce, and death certificates.
 The system reports population distribution of Haramaya city.
2.2.3. Non functional requirement

Backup: Haramaya city civil and vital registration system will have scheduled backup plan
from the central civil registry database so as to curtail the possibility of losing the city’s civil
information.
Security: Haramaya city civil and vital registration system will have sufficient secrecy for the
citizen’s vital information that stored in the central civil registry database from illegal accesses.
Maintainability: Haramaya city civil and vital registration system will be extensible in order
to add new functionalities by incorporating new advanced technologies whenever it is
necessary and it will be easily modifiable for future enhancements and workflow changes. It
also satisfies the traceability criteria; the code what we are going to implement will match to
the functional requirements of the system. Because of this, Haramaya city civil and vital
registration system is readable to assure its maintainability.
Performance: Haramaya university civil and vital registration system is going to handle
multiple user requests and process them efficiently as much as possible. This helps the system
to be accessed from different locations.
10
5
Dependability: Haramaya city civil and vital registration system will robust enough to manage
any valid input from the users and performs any civil registry database operations with no
errors.
End user criteria: In order to access the system suitably, Haramaya city civil and vital
registration system will have simple, understandable and user friendly fashion graphical user
interface which have appropriate and descriptive names.
2.3. Feasibility Study

In feasibility study, it is crucial to make decision on how beneficial or practical the developing
system is. Before we are going to develop our system, first we should have to clearly notify the
feasibility of the system that we are going to implement.
Economical feasibility
In economic feasibility, we should notify that Haramaya city municipal will be profitable by
the proposed system. Small amount of budget is going to be used to build the proposed system.
Economically, the system will profit the organization by providing a better means of recording
and managing civil and vital events of Haramaya city. So, Haramaya city municipal as an
organization gives better service to the public and country by using the proposed system.
Technical feasibility
When we evaluate the hardware’s and software’s requirement and how they meet the need of
the proposed system, our projected system is technically feasible because we are using
currently available and affordable technologies to develop the proposed system.
Operational feasibility
The proposed system is going to solve the problems, take advantage of the opportunities
identified during scope definition and to satisfy the requirements specified in the requirement
specification. So, the proposed system is operationally feasible.
11
5
CHAPTER THREE
SYSTEM MODEL AND DATA DESCRIPTION
Haramaya city civil and vital registration system brings into play an Object Oriented System
Analysis and Design (OOSAD) to model the system and describe the data. The reason why we
chose an object oriented approach is because of the analysis is made on the classes and
interaction among them in order to meet the functional requirements.
3.1. Use Case Model Modeling

In the main, our use case modeling describes the proposed functionality of Haramaya city civil
and vital registration system. It also represents a discrete unit of interaction between the user
and the system, capturing requirements of the proposed system and presenting the behavior of
the system from an external point of view.
Actors of the system

We have three actors that interact with Haramaya city civil and vital registration system. The
following table shows us actor the proposed system with their description.
NO Actor name Description

1 Resident Is legal Haramaya city dweller
2 Kebele Is employee’s of one of the kebele’s of Haramaya city
administrator municipal and responsible for activities of that specific
kebele.
3 City administrator Is one of the employee’s of Haramaya city municipal
responsible for controlling the system.
Table 2: actor description
12
5
Essential use case (task case model or abstract use case)
Haramaya city civil and vital registration system consists of eight essential use cases. These
are:
1. Login
2. Register resident
3. Search resident
4. View population distribution
5. Update resident vital information
6. Manage user accounts
7. Request vital certificate
8. Report vital certificate
The following diagram shows us the essential use case of Haramaya city civil and vital
Login
Request
vital certificate
View population
distribution
Resident
City
Administrator
Search resident
Manage user
Register resident accounts
Kebele Report
Administrator Update resident
vital certificate
vital information
Figure 1: essential use case diagram
13
5
System use case (concrete use case or detailed use case)
We design the following system use case diagram in order to make clear about what Haramaya
city civil and vital registration system will do.
Request Request
birth certificate marriage certificate
Request
divorce certificate Manage user accounts
<<include>> <<include>>
<<include>>
Request Request
<<include>> death certificate <<include>>
vital certificate <<include>>
<<include>>
Resident Remove account

Modify account
Create account
City
Administrator
Login
Search <<include>> Search resident

resident in kebele
Kebele
Administrator
View population
distribution in kebele
<<include>>
View population
Register resident distribution Report
vital certificate
<<include>>
<<extend>> Report
birth certificate
<<include>>
<<include>>
<<include>>
Register marriage
Report
Report marriage certificate
death certificate
Report
Update resident divorce certificate
vital information
Figure 2: system use case diagram
14
5
Use case Description

Before we are going to describe the system use case, let’s give identifiers to the use cases. The
following table shows us use cases with their identifiers.
Use case Identifier

login CVRUC01
Register Resident CVRUC02
Update Resident Vital Information CVRUC03
Search Resident CVRUC04
Search Resident in kebele CVRUC05
View population distribution CVRUC06
View population distribution in kebele CVRUC07
Request vital certificate CVRUC08
Request birth certificate CVRUC09
Request marriage certificate CVRUC10
Request divorce certificate CVRUC11
Request death certificate CVRUC12
Manage user accounts CVRUC13
Create account CVRUC14
Remove account CVRUC15
Report vital certificate CVRUC16
Report birth certificate CVRUC17
Report marriage certificate CVRUC18
Report divorce certificate CVRUC19
Report death certificate CVRUC20
Modify account CVRUC21
Register marriage CVRUC22
Table 3: system use case with their identifiers
Below the description of use cases of Haramaya city civil and vital registration system is
presented.
Login use case description
Use case name Login

Use case identifier CVRUC01
Actor(s) City administrator, kebele administrator, resident
15
5
Description Authorized users will access the system
Pre-condition The user not already logged in to the system.
Post-condition The user will access the system.
Basic course of action
1. The user sends the request to the server using web browser.
2. The System displays the login page.
3. The user enters username and password and press submit button.
4. The system validates the account.
5. The system displays the appropriate home page.
6. The user access the system.
7. Use case end.

Alternative course of action
Alternative course of action A: if the user enters inappropriate user name and password
A.4. The system determines that the entered user name and password is invalid.
A.5. The system displays “try again” message.
A.6. Use case ends.
Table 4: login use case description
Register Resident use case description
Use case name Register Resident

Actor(s) Kebele Administrator
Description Register citizens who are eligible residents of
Haramaya city
Pre-condition The residents should bring all necessary
information from Shengo of the Kebele
Post-condition The residents will be registered.
1. The use case begins when child is born and resident comes to the city.
2. The resident must bring all required information to kebele administrator.
3. The kebele administrator inputs the resident’s information into the system.
4. The system validates the entered data by the Kebele administrator.
16
5
5. The system generates user name and password for the residents.
6. The system displays user name and password.
7. The system registers the resident.
8. The use case ends.
Alternative Course of action A: If the resident doesn’t bring all the necessary
information.
A.3. Kebele administrator proves the resident doesn’t submit the necessary
information.
A.4. The resident will be asked to bring the necessary information.
A.5. The use case ends.
Alternative course of action B: If the kebele administrator enters invalid information.
B.4. The system determines the entered information is invalid.
B.5. The system displays “Invalid information”.
B.6. use case ends.
Table 5: register resident use case description
Update Resident vital information use case description
Use case name Update resident vital information.

Actor(s) kebele administrator
Description Update vital information for appropriate citizens.
Pre-condition the citizen is registered in the kebele
Post-condition The citizen vital information will be updated if he
or she is fitting.
1. Kebele administrator wants to update citizen’s vital information.

2. Kebele administrator obtains all necessary information’s from the shengo of the
kebele.
3. Kebele administrator enters required vital information.
4. Kebele administrator submits the required vital information.
5. The system validates the submitted information.
6. After validation, the system stores the updated information.
7. Use case end.
17
5
Alternative course of action A: if the Kebele administrator doesn’t obtain all

necessary information
A.2. use case ends.
Alternative course of action B: If the Kebele administrator enters invalid information
B.5. the system determines that the entered information is invalid.
B.6. the system displays “invalid information”.
B.7. Use case ends.

Table 6: update resident vital information use case description
Search Resident use case description
Use case name Search resident

Actor(s) city administrator
Description searching for registered citizens
Pre-condition The citizen is registered in one of the kebele of
the city.
Post-condition The system will generate search results.
1. City administrator wants to search for citizens of the city.

2. City administrator enters personal identification number as well as name on the
search box.
3. After entering search key, the city administrator submits it using the search
button.
4. The system validates the entered search key.
5. The system generates search results.
6. Use case ends.
Alternative course of action A: if the city administrator enters invalid personal

identification number as well as name
A.4. the system determines that the entered personal identification number as well as
18
5
name is invalid.
A.5. use case ends.

Table 7: search resident use case description
Search resident in kebele use case description
Use case name Search resident in kebele.

Actor(s) kebele administrator
Description Searching for registered citizens in kebele.
Pre-condition The citizen is registered in one of the kebele of the
city.
Post-condition The citizen is registered in one of the kebele of the
city.
1. kebele administrator wants to search for citizens of the city.

2. kebele administrator enters personal identification number as well as name on the
search box.
3. After entering search key, the kebele administrator submits it using the search
button.
4. The system validates the entered search key.
5. The systems generate report for search results.
6. Use case ends.
Alternative course of action A: if the kebele administrator enters invalid personal

identification number as well as name
A.4. the system determines that the entered personal identification number as well as
name is invalid.
A.5. use case ends.

Table 8: search resident in kebele use case description
View population Distribution use case description
19
5
Use case name View population Distribution
Actor(s) City Administrator
Description view the required population distribution
information of the city
Pre-condition There must be Civil registry database which is
accessible only by authorized users.
Post-condition The required population distribution information
will be displayed.
1. City administrator wants to view population distribution in city.

2. City administrator clicks a button which is related to the required population
distribution.
3. The system displays the required population distribution.
4. Use case ends.
Alternative course of action A: if city administrator clicks unrelated button to the

required population distribution.
A.3. The system displays population distribution which is not required.
A.4. Use case ends.
Table 9: view population distribution use case description
View population Distribution in kebele use case description
Use case name View population Distribution in kebele

Actor(s) kebele administrator.
Description View the required population distribution with in
kebele.
Pre-condition There must be Civil registry database for the
kebele which is accessible only by authorized
user
Post-condition The required population distribution information
displayed
1. Kebele administrator wants to view population distribution with in kebele.
20
5
2. Kebele administrator clicks a button which is related to the required population
distribution.
3. The system displays the required population distribution.
4. Use case ends.
Alternative course of action A: if kebele administrator clicks unrelated button to the

required population distribution.
A.3. the system displays population distribution which is not required.
A.4. Use case ends.
Table 10: view population distribution in kebele use case description
Manage user accounts use case description
Use case name Manage user accounts

Description City administrator can add or remove kebele
administrator’s account
Pre-condition City administrator has privileges to manage
kebele administrator’s accounts.
Post-condition The city administrator will manage kebele
administrator’s accounts.
1. City administrator wants to manage accounts.

2. The city administrator chooses manage account link
3. The system display manage account page
4. The city administrator clicks “Create account” or “Remove account” button.
5. The system display Create account or Remove account page.
6. City administrator enters required information via create or Remove page.
7. The system cheeks that all the entered information are valid.
8. System display different message accordingly.
9. Use case ends.
Alternative course of action A: If the city administrator enters incorrect

information
21
5
A.8. The system determines the entered information is invalid.
A.9. The system displays message “the entered information is invalid”
A.10. Use case ends.

Table 11: manage user accounts use case description
Request birth certificate use case description
Use case name Request birth certificate.

Actor(s) Resident
Description dealing out birth certificate requests for
appropriate citizens
Pre-condition The citizen is registered in the city.
Post-condition Citizen’s request for birth certificate will be
processed by the system.
1. The resident wants a birth certificate
2. The resident sends birth certificate request to the system
3. The system processes the request for birth certificate
4. The system validates the request for birth certificate
5. The system displays “request successfully send” message
6. Use case ends

Alternative course of action A: if resident is not appropriate for requesting birth
certificate
A.4. the system determines that the resident is not fitting for birth certificate request.
A.5. The system displays “request not successfully send” message
A.6. use case ends.
Table 12: request birth certificate use case description
Report Birth Certificate use case description
Use case name Report Birth Certificate
22
5
Description City administrator issues birth certificate for registered
residents
Pre-condition Resident is valid for birth certificate
Post-condition The resident will get birth certificate.
1. The system determines that the resident is legal for birth certificate
2. The city administrator goes to report birth certificate page
3. The city administrator fills the birth certificate form and presses the report button
4. The system prints the birth certificate.
5. City administrator finalizes the birth certificate and gives for the resident in person.
6. Use case ends.
Alternative course of action A: If resident is not legal for birth certificate
A.1. the system determines that the resident is not legal for birth certificate.
A.2. The system displays “not legal for birth certificate” message.
A.3. Use case ends.

Table 13: report birth certificate use case description
Request marriage certificate use case description
Use case name Request marriage certificate

Actor(s) Residents
Description Dealing out marriage certificate requests for
appropriate citizens.
Pre-condition The residents are married, kebele shengo does this.
Post-condition Citizen’s request for marriage certificate will be
1.The resident wants a marriage certificate
23
5
2. The resident sends marriage certificate request to the system
3. The system processes the request for marriage certificate
4. The system validates the request for marriage certificate
6. Use case ends

Alternative course of action A: if resident is not appropriate for requesting marriage
certificate
A.4. the system determines that the resident is not fitting for marriage certificate request.
A.6. use case ends.
Table 14: request marriage certificate use case description
Report Marriage Certificate use case description
Use case name Report Marriage Certificate

Description City administrator issues Marriage certificate for
registered residents.
Pre-condition The resident is valid for marriage certificate
Post-condition The resident will get Marriage certificate.
1. The system determines that the resident is legal for marriage certificate
2. The city administrator goes to report marriage certificate page
3. The city administrator fills the marriage certificate form and presses the report button
4. The system prints the marriage certificate.
5. City administrator finalizes the marriage certificate and gives for the resident in person.
6. Use case ends.
Alternative course of action A: If residents is not legal for marriage certificate
A.1. the system determines that the resident is not legal for marriage certificate.
24
5
A.2. The system displays “not legal for marriage certificate” message.
A.3. Use case ends.

Table 15: report marriage certificate use case description
Request divorce certificate use case description
Use case name Request divorce certificate

Actor(s) Residents
Description dealing out divorce certificate requests for
appropriate citizens
Pre-condition The residents are divorced, kebele shengo does this.
Post-condition Citizen’s request for divorce certificate will be
1. The resident wants a divorce certificate
2. The resident sends divorce certificate request to the system
3. The system processes the request for divorce certificate
4. The system validates the request for divorce certificate
6. Use case ends

Alternative course of action A: if resident is not appropriate for requesting divorce
certificate
A.4. the system determines that the resident is not fitting for divorce certificate request.
A.6. use case ends.
Table 16: request divorce certificate use case description
Report Divorce Certificate use case description
Use case name Report Divorce Certificate
25
5
Description City administrator issues Divorce certificate for
registered residents.
Pre-condition The resident is valid for divorce certificate
Post-condition The residents will get Divorce certificate.
1. The system determines that the resident is legal for divorce certificate
2. The city administrator goes to report divorce certificate page
3. The city administrator fills the divorce certificate form and presses the report button
4. The system prints the divorce certificate.
5. City administrator finalizes the divorce certificate and gives for the resident in person.
6. Use case ends.
Alternative course of action A: If residents is not legal for divorce certificate
A.1. the system determines that the resident is not legal for divorce certificate.
A.2. The system displays “not legal for divorce certificate” message.
A.3. Use case ends.

Table 17: report divorce certificate use case description
Request death certificate use case description
Use case name Request death certificate

Actor(s) Residents
Description Dealing out death certificate requests for appropriate
citizens.
Pre-condition The resident is died, kebele shengo does this.
Post-condition Citizen’s request for death certificate will be processed
by the system
1. The resident wants a death certificate
26
5
2. The resident sends death certificate request to the system
3. The system processes the request for death certificate
4. The system validates the request for death certificate
6. Use case ends

Alternative course of action A: if resident is not appropriate for requesting death
certificate
A.4. the system determines that the resident is not fitting for death certificate request.
A.6. use case ends.
Table 18: request death certificate use case description
Report Death Certificate use case description
Use case name Report Death Certificate

Description City administrator issues Death certificate for
registered residents
Pre-condition The resident is valid for death certificate
Post-condition The residents will get death certificate.
1. The system determines that the resident is legal for death certificate
2. The city administrator goes to report death certificate page
3. The city administrator fills the death certificate form and presses the report button
4. The system prints the death certificate.
5. City administrator finalizes the death certificate and gives for the resident in person.
6. Use case ends.
Alternative course of action A: If residents is not legal for death certificate
A.1. the system determines that the resident is not legal for death certificate.
27
5
A.2. The system displays “not legal for death certificate” message.
A.3. Use case ends.

Table 19: report death certificate use case description
Modify account use case description
Use case name Modify account

Actor(s) City Administrator, kebele administrator, resident
Description Allows all users of the system to modify their own
account information
Pre-condition all users must have an account
Post-condition the users account information will be modified
1. The user requests to his/her profile
2. The system displays the profile of the user
3. The user selects the setting account to be modified
4. User enters his/her current password and presses continue
5. User modifies his/her account information and presses modify
6. The use case ends
Alternative course of action A: if the user enters wrong password
A.5. the system displays “the password you entered is incorrect. Please try again” message
A.6. Use case ends
Table 20: modify account use case description
Register marriage use case description
Use case name Register marriage

Actor(s) Kebele Administrator
Description Performing marriage registrations of Haramaya city
residents who are eligible
Pre-condition The married residents should bring all necessary
information from Shengo of the Kebele
28
5
Post-condition The married residents will be registered for marriage
registration.
1. The use case begins when residents are get married

2. The married residents must bring all required information to kebele administrator.
3. The kebele administrator inputs the married resident’s information into the system.
4. The system validates the entered data by the Kebele administrator.
5. The system makes marriage registration for the married residents.
6. The use case ends.
Alternative Course of action A: If the married residents don’t bring all the necessary
information.
A.3. Kebele administrator proves the married resident doesn’t submit the necessary
information.
A.4. The married resident will be asked to bring the necessary information.
A.5. The use case ends.
Alternative course of action B: If the kebele administrator enters invalid information.
B.4. The system determines the entered information is invalid.
B.5. The system displays “Invalid information”.
B.6. use case ends.
Table 21: register marriage use case description
3.2. Class Diagram

Class diagram of Haramaya city civil and vital registration system illustrates the object
oriented analysis and design in brief. It shows us the classes of the system, their
interrelationships like inheritance to introduce reuse between classes, aggregation in order to
show composition, association to describe a connection among the classes. It also gives you an
idea about operations, attributes, and multiplicity and role names of the classes.
Haramaya city civil and vital registration system class diagram is presented below.
29
5
Person Login
+full_name:string 1 Be able to 1 +username:string

+username:string +password:string
+password:string +login()
+login() +logout()
1 modifies
+logout()
+modify_account()
Resident Kebele_Adminstrator City_Adminstrator Account
-kebele_number:String -kebele_number:String -priviledge:string +username:string

1 Manages *
-resident_id:string -kebele_admin_id:string -city_admin_id:string +passowrd:string
+request_certificate() +search_resident() +user_type:string
+view_population() 1
+take_certificate() +view_population() +search_resident() +create_account()
+register_marriage() +report_certificate() +remove_account()
1..* +modify_account()
1
1..* +register_resident() +manage_account()

+update_resident_info() 1
searches 1 1 1 1
Act upon
searches
sends
1..*
Haramaya City
Request Vital certificate
Civil And Vital Registration System
+Request_Id:String
+Sender_Id:String 1..*
Views
+Request_type:String
Report vital
Performs
+Send_request()
certificate
+request_status()
Views
-Request_Id:String
-Report_type:String
-Report_Id:string
+requester_info()
+generate_report()
Resident Regestration
-full_name:string
-mother_name:string
-resident_id:string
-kebele_number:string 1..* GUI
-age:integer
-form_type:string
-resident_picture:BLOB
-interface type:string
-sex:string
-house_number:string +inputData()
+dislplayStatusMessage()
+register_resident() 1..* +showresults()
+register_marriage()
+generatePDFFormatReport()
+update_resident_vital_info() Population Distribution
-population_distrubution_ID:string
-population_distrubution_type:string 1..*
+view_population_distribution()
30
5
Figure 3: class diagram
3.3. Dynamic Model

Haramaya city civil and vital registration system uses sequence, activity and state chart
diagrams of dynamic models in order to show its internal behavior.
3.3.1. Sequence Diagram
The following sequence diagrams gives illaboration for the different system use cases of
Haramaya city civil and vital registration system.
Login sequence diagram
Login Page Login

:User :Home page :DB
:GUI :Controller
Enter username and password
and press login button
ValidateInput()
Submit()
Check()
alt Response()
[Found] Display()
Display()
[Not Found]
Response()
DisplayErrorMessage()
Figure 4: login sequence diagram
31
5
Register residents sequence diagram
Kebele Registeration Register

Result:Page :DB
Admin:User Page:GUI :Controller
Click register button
RegistrationForm()
Fill the form and
press submit
ValidateInput()
Transferregistrationrequest()
Check()
Result()
alt
Store()
[Resident not exist in DB]
Response()
DisplayConfirmation()
Successful registration
[Resident already exist]

DispalyError()
Unsuccessful registration
Figure 5: register resident sequence diagram
Update resident’s vital information sequence diagram
32
5
Admin Resident UpdateRecord

Update:GUI :DB
:User Record:Page :Controller
Press the fitting update

button
Update_form()
Enter the information
ValidateInput()
InitiateUpdate()
AccessRecord()
ReadRecord()
DisplayRecord()
Show record for change
Update resident information and

press submit button
Replace()
Update()
Updated()
DisplayChange()
Resident information successfully updated
Figure 6: update residents vital information sequence diagram
Search residents sequence diagram
33
5
Search Search Search

Admin:User :DB
page:GUI result:Page :Controller
Fill the search criteria
and press search button
CheckInputCriteria()
ActivateController()
Search()
SearchResult()
alt Display()
[Found]
DisplaySearchResult
[Not Found]
DisplayError()
Display unsuccessful
search
Figure 7: search resident sequence diagram
Create account sequence diagram
34
5
City_Admin CreateAccount CreateAcount CreateAccount

:DB
:User :GUI :Page :Controller
Click create
account button
accountForm()
Fill the form and
press submit button
Validate_Input()
InitiateAccountController()
CheckAccount()
Result()
alt Store()
[Username not exist] DisplayConfirmation() Response()
Display confirmation
Set privilege
SetPrivilege()
Store()
Response()
Creating account Display()
successful
[Username exist]
DisplayError()
Creating account not
successful
Figure 8: create account sequence diagram
View population distribution sequence diagram
35
5
Admin
ViewPage:GUI ViewResult:Page View:Controller :DB
:User
Click appropriate view

button
ActivateController()
View()
ViewResult()
Display()
Successful view
Figure 9: view population distribution sequence diagram
Request vital certificate sequence diagram
36
5
Request Result Page Request :DB

:Resident
Resident Result page
Page: GUI :Page :Controller
Click appropriate request

button
Requestform()
Fill the form and press

submit button ValidateInput()
InitiateRequest()
Check()
Response()
alt
Displayconfirmation()
[Found] Request successfully send
[Not found]
Request not successfully send
Figure 10: sequence diagram for requesting vital certificate
Remove account sequence diagram
37
5
City_Admin RemoveAccount RemoveAcount RemoveAccount

:DB
:User :GUI :Page :Controller
Click remove
account button
accountForm()
Fill the form and
press submit button formValidation()
InitiateAccountController()
CheckAccount()
Result()
alt Remove()
[Username exist]
Response()
Display confirmation
[Username not exist]
DisplayError()
Unsuccessful removing
account
Figure 11: sequence diagram for removing account
Report vital certificate sequence diagram
38
5
CityAdmin Report Result Page Report

Resident Result page :DB
:user Page: GUI :Page :Controller
Click appropriate report

button
Reportform()
Fill the form and press

submit button
ValidateInput()
InitiateReport()
Check()
Response()
Display Successful report
Figure 12: sequence diagram for reporting vital certificate
3.3.2. Activity Diagram
The following activity diagrams show the detailed and stepwise work flows of Haramaya city
civil and vital registration system.
39
5
Login activity diagram
User enters login name and

password
Correct login and [No]

Invalid login/password
password?
[yes]
User has successfully logged in
User's setting are displayed
Figure 13: activity diagram for login
40
5
Register resident activity diagram
41
5
Click on register button
Registration form is displayed
Fill the form and press submit button
[Invalid] Check
Display error message
Input data
[Valid]
Successful Registration
Display success message
42
5
Figure 14: activity diagram for registering resident
Update resident’s vital information activity diagram
43
5
select appropriate update button
Display update form
Enter information related to the

registry to be updated
and press update
[Invalid] Check
input
[Valid]
Information updated
Figure 15: update residents vital information activity diagram
44
5
Search resident activity diagram
Click on search
button
Search type
search by
Identification no. Search by Name
Search resident
Check [Not found]

input criteria
[Found]
Show result
Figure 16: activity diagram for searching a resident
45
5
Create account activity diagram
46
5
Select manage account
Select create new account
Enter user information and

press create
Check [Invalid]
information
[Valid]
System creates user account
47
5
Figure 17: create account activity diagram
View population distribution activity diagram
Click view button
Select the required view button
Display the required Population

Distribution
Figure 18: view population distribution
Request vital certificate activity diagram
48
5
Click on request vital certificate

button
Choose the request type
Enter the required information

and press send
Enter again
[Invalid]
Check request
[Valid]
Display successful request
49
5
Figure 19: activity diagram for requesting vital certificate
Remove account activity diagram
50
5
Select manage account
Select remove account
Enter user information

and
press remove
Check [Invalid]
information
[Valid]
System removes user account
Displaay success message
Figure 20: remove account activity diagram
51
5
Report vital certificate activity diagram
Click on report vital certificate
Choose the report type
Enter the necessary

information and press submit
Re-enter the required

information
[Invalid]
Check input
[Valid]
Print the certificate
Finalize the certificate
requester gets
the certificate
Figure 21: report vital certificate activity diagram
52
5
3.3.3. State Chart Diagram

Haramaya city civil and vital registration system has the following different state chart
diagrams to show the state of a particular object through its life time in response to different
events of the system.
Login state chart diagram
Login Page
Enter username
and password
Re-Enter login name

Reading Login name
and password
and password
Correct username
and password
Home Page
completed
Logout
Figure 22: login state chart diagram
53
5
Register resident state chart diagram
Home Page
Chosen page
Logout Pressed
Regestration page
Information Entered
Reading Regestration Logout Pressed

[Invalid Information] Information
Re-enter information
Registered
Logout Pressed
successful registration
Accomplished
Logout
Figure 23: register resident state chart diagram
Update resident’s vital information state chart diagram
54
5
Home page
Chosen page
Logout pressed
Update page
Information
entered
Reading update Logout pressed

[Invalid information] information
Re-enter update
information Updated
Display information Logout pressed

is updated
accomplished
Logout
Figure 24: state chart diagram for updating resident’s vital information
Search resident state chart diagram
55
5
Home page
Chosen page
Logout pressed
Search page
Search key entered
Logout pressed
Resident search
[Invalid search criteria] Successfully searched

Re-enter search
information
Display detailed Logout pressed
information
completed
Logout
Figure 25: search resident state chart diagram
Create account state chart diagram
56
5
Home page
Chosen page
Logout pressed
Manage account page
Chosen page
Logout pressed
Create account page
selected
Logout pressed
Entering user information
[Invalid information]
Re-enter user information
Information entered
Logout pressed
System create user account
Account successfully created
Logout
Figure 26: create account state chart diagram
View population distribution state chart diagram
57
5
Home page
Chosen page
Logout pressed
View page
selected
Required view Logout pressed

selection
Successfully viewed
Display view
Logout pressed
poplation
distribution
completed
Logout
Figure 27: view population distribution state chart diagram
Request vital certificate state chart diagram
58
5
Home page
Choose a page
Logout pressed
Request page
Request type selected
Logout pressed
Resident request
Certificate requested
Dispatch request Logout pressed

[Invalid] message
Try again
Complete request
Logout
Figure 28: request vital certificate state chart diagram
59
5
Remove account state chart diagram
60
5
Home page
Chosen page
Manage account Logout pressed

page
Chosen page
Remove account Logout pressed

page
Selected
Entering user Logout pressed

[Invalid information] information
Re-enter user
information Information entered
System Removes Logout pressed

user account
Account successfully
removed
Logout
61
5
Figure 29: remove account state chart diagram
Report vital certificate state chart diagram
Home page
Chosen page
Logout pressed
Report page
Report type selected

[Invalid]
Logout pressed Re-enter require
Entering required information
information
Certificate reported
Logout pressed
Successful report
report completed
Logout
Figure 30: report vital certificate state chart diagram
62
5
3.4. User Interface
The following navigational paths and screen mockups enables you to gain a high-level
overview of the web site of Haramaya city civil and vital registration system.
Login Page
Resident Home Kebele Administrator City Administrator

Page Home Page Home Page
Request Vital Certificate Update Resident Vital info Register Resident View Population Search Resident Manage Account
Page Page Page Distribution Page Page Page
Birth Registration Marriage Registration Birth Registration Report Vital Information

Page Page Page Page
Divorce registration Death registration

Page Page
Figure 31: site map of Haramaya city civil and vital registration system
63
5
CHAPTER FOUR
SYSTEM DESIGN
4.1. Introduction
System design is the abstraction or invention of a solution; it is the general description of the
solution to a problem. System designing shows the direction how the system is built with clear
and enough patterns needed to drive the actual implementation and high quality of the system.
It also considers the following points:
 Working out how to solve the problem of the current system.

 Making decisions about what software we will write and how we deploy it.
 Breaking the system down in to different operations.
 What must be done to the selected services to support the interactions?
 The way the service will be used to provide the repository of data.
 How programs will be developed to give users access the data.
 The interface that is needed to support interactions in the system, how services will be
integrated.
Haramaya city civil and vital registration system design is the process of defining the
architecture, components, modules, interfaces, and data for the system to satisfy specified the
requirements. This systems design could be seen as the application of systems theory to
product development. This helps us to facilitate registration and provide efficient vital
information of the residents of the city.
4.1.1. Overview of System Design

System design is a phase which provides a blueprint for implementation, testing and
maintenance phases of the system. As we have stated in the requirements analysis and system
modeling and data description phases, the proposed system is aimed and going to be designed
to attain computerized civil registry database system. So, these requirements and data
descriptions should be solved for the sake of implementation of the system. This helps us to
find an easy way to register residents, search residents, and update residents’ vital information.
This also helps us to give functionalities like modernized reporting vital certificates and
viewing population distributions.
64
5
4.1.2. Design Goal
These design goals of this system represents the desired qualities or good-qualities of
Haramaya city civil and vital registration System and providing a consistent set of criteria that
must be considered when making design decisions. Based on the non-functional requirements
that we have stated before, the following design goals will have to achieve in order to make the
system successful.
1. Dependability criteria
Robustness: Haramaya city civil and vital registration system is tough or robust enough to
manage any valid inputs from the users.
Reliability: Haramaya city civil and vital registration system is going to perform different
civil registry database operations in a predictable manner and with no errors in order to make
genuine civil recognition of Haramaya city.
Security: since our system is dealing about the recognition of Haramaya city which is the big
deal of the city, the civil registry database should be extremely secured so that information
about residents kept safe and sound.
Performance: Haramaya university civil and vital registration system is going to handle
multiple user requests and process them efficiently as much as possible. This helps the system
to be accessed from different settings.
Backup: Haramaya city civil and vital registration system will have scheduled backup plan
from the central civil registry database so as to curtail the possibility of losing the city’s civil
information.
2. Maintainability criteria
Haramaya city civil and vital registration system is capable of adding new functionality and is
modifiable for future enhancements and work flow changes, in which the system’s internal
structure and data flow are minimally or not affected.
Generally, Lots of developers are familiar with php/mysql so it is relatively easy to find
developers to maintain the system.
3. End User Criteria

Haramaya city civil and vital registration system will have simple, understandable and user
friendly fashion graphical user interface such as forms and buttons which have descriptive
names. This specifically supports the residents and employers of Haramaya city municipal in
65
5
order to access the system suitably. It also gives trustworthy response for each user request at
least before the session expires.
4.2. System Decomposition with Services

System decomposition is breaking down a system in to its component subsystems, analyzing
each separately, and aggregating them back in to the complete system.
During system decomposition of Haramaya city civil and vital registration system, we break
down the system into different subsystems or modules. The subsystems are with strong
coherence in order to perform specific task and loosely coupled in order to solve and modify
the modules separately. Our system decomposition shows the existence of the following
subsystems.
User management subsystem

This subsystem is responsible for managing different users of Haramaya city civil and vital
registration in the way how they are logging in and logging out. This subsystem also advocates
that only one username and password is required to access all applications that are available to
the user.
This subsystem contains the following operations:
 create _login()
 update _login()
 login()
 logout()
Account management subsystem

This subsystem responsible for managing user accounts. It provides function for creating an
account, updating an account and removing an account. Administrator is the only actor who
communicates with this subsystem. This subsystem uses login services of the user management
subsystem for authenticating the administrator and also uses the storage subsystem for storing
account’s information.
The operations provided by this subsystem are:
 create_account()
 remove_account()
 modify_account()
66
5
Registration management subsystem
This subsystem is responsible for managing different resident registrations of Haramaya city
civil and vital registration system. This subsystem uses login services of the user management
subsystem in order to access the system and also uses the storage subsystem for storing variety
of resident registrations.
 register_resident ()
 register_marriage()
 search_resident()
 update_residents_vital_info()
 view_poppulation_distribution()
Report management subsystem

This subsystem is responsible for handling different vital certificate requests and providing
appropriate reports for them. It uses login services of the user management subsystem in order
to access the system and also uses the storage subsystem for storing variety of requests and
reports.
 send_request()
 generate_report()
Storage subsystem
This subsystem will encapsulate the database providing a common interface to other three high
level subsystems. It is responsible for getting system-related data from different subsystems
and issuing database management system-specific calls for information storage and retrieval.
Database subsystem
The database subsystem will be implemented by relational database management system which
is used to store the persistent data.
GUI subsystem
67
5
This subsystem is responsible for the interaction between user and the system. It provides
simple way of interaction of the user to the system as much as possible.
The following diagram shows the different subsystems of Haramaya city civil and vital
68
5
Haramaya city civil

and vital registration
system
Account Registration Report

management management management
User management
Storage
Database
69
5
Figure 32: Haramaya city civil and vital registration system decomposition
4.3. Current Software architecture

Currently, Haramaya city don’t have any kind of automated civil and vital registration. The
current system is manual. The proposed system will be the first of its kind for Haramaya city.
4.4. Proposed Software Architecture
Haramaya city civil and vital registration system will be web based system, which is used to
automate the current manual system. Because of this, the system will have its own software
architecture. In order to propose the Haramaya city civil and vital registration system software
architecture, we will user 3-tier architecture. The reason why we choose this type of
architecture is; because of latest web applications are deployed in this type of architecture.
 Tier 1: Presentation layer (tier on the top)
In this tier, Haramaya city civil and vital registration system users browse in order to
display user data using graphical interface.
 Tier 2: Business layer (tier in the middle)
Haramaya city civil and vital registration system business layer uses Haramaya city
web server to handle the data validation.
 Tier 3: Data access layer (tier at the bottom)
Haramaya city civil and vital registration system data access layer uses the MYSQL
database server to communicate with the database by constructing different SQL
queries.
The proposed software architecture of Haramaya city civil and vital registration system is
presented below.
70
5
Database
Management
Client Web server
system
(DBMS)
User running running
Database
web
web browser
applications
Figure 33: proposed software architecture
4.5. Hardware / Software mapping

Haramaya city civil and vital registration system will a web based system. All functionalities
and services will be accessed through the Haramaya city LAN. Because of this, it is necessary
to specify the nodes and the communication between these nodes of the system. Therefore, we
don’t get confused to deploy the system.
As we have stated in the system development tools , the web server will run over WAMP 4.0
server, the web development tools of the system could be PHP5 and some scripting language
such as Hyper text markup language(HTML), java script(JS) , JQuery , Cascading style sheet
(CSS) and we will use MYSQL version 5.0.51b as the database management system.
For more, the following enterprise application diagram illustrates the hardware/software
mapping of Haramaya city civil and vital registration system.
71
5
Haramaya city civil and vital

registration system users
HTTP
ODBC
Haramaya city Web server Database server

(Apache) (MYSQL)
Figure 34: hardware/software mapping
4.6. Persistent Data management
Haramaya city civil and vital registration system will have its own persistent data management
in order to describe the data stored by the system and the data management infrastructure
required for it. This helps us to permit different users of Haramaya city civil and vital
registration system to have different views of the system, to store any data related to
management system and to allow concurrent access to the system.
A relational database management will be used to maintain the persistent data in its advantages
that it provides several services and utilities that help to attain the design goals of Haramaya
city civil and vital registration system.
The following figure shows the persistent data management system of Haramaya city civil and
vital registration system.
72
5
Account
PK Account_ID User_Type Kebele
Username PK User_ID PK Kebele_NO
Password User_Description Kebele_Name
Address
Death Kebele_Leader_
FullName
FK Resident_ID Administrators
FK Chid_ID PK Admin_ID Divorce

Place_of_Death User_type FK Marriage_ID
Date_of_Death Full_Name Divorce_Date
Summery_Of_ phone Summery_of_

Death number Divorce
Informant_Full_ Sex
Name
Responsiblity Marriage
PK Marriage_ID
Birth
PK Child_ID Residents FK Resident_ID
PK Resident_ID Marriage_Date
FK Informant_ID
FK House_NO Visitors's_Full_Name
FName
FK User_Type Visitors's_Permanent_
Mname
Address
LName FName
Visitors's_Photo
Date_of_Birth MName
Visitors's_Phone_NO
Family_Phone_NO LName
Visitors's_Occupation
Mother_Name Sex
Place_Of_Birth Age
House
Religion_of_Family Photo
PK House_NO
Father's_ Educational_
Occupation Status FK Kebele_NO
Mother's_ Occupation Ownership

Occupation
Religion
Birth_Weight
Mother's_Age
Father's_Age
Pregnance_
Duration
73
5
Figure 35: persistent data management
4.7. Data Dictionary

Haramaya city civil and vital registration system will have a data dictionary or simply a
repository to store information about all data items of the system. Our system will keep its data
dictionary hidden from users to prevent them from accidentally destroying its contents.
Haramaya city civil and vital registration system will have the following different data
dictionaries.
Data dictionary for Resident registration
NAME DATA TYPE CONSTRAINT

RESIDENT_ID VARCHAR(20) PRIMARY KEY
HOUSE_NO VARCHAR(20) FORIGN KEY
USER _TYPE CHAR(20) FORIGN KEY
FNAME CHAR(20) NOT NULL
MNAME CHAR(20) NOT NULL
LNAME CHAR(20) NOT NULL
SEX CHAR(6) NOT NULL
AGE UNSIGNED INT NOT NULL
PHOTO BLOB NOT NULL
EDUCATIONAL_STATU CHAR(50) NOT NULL
S
OCCUPATION CHAR(50) NOT NULL
RELIGION CHAR(20) NOT NULL
Table 22: data dictionary for resident registration
Data dictionary for Account
NAME DATA TYPE CONSTRAINTS
ACCOUNT_ID VARCHAR(20) FORIGN KEY

USERNAME VARCHAR(20) NOT NULL
PASSWORD VARCHAR(20) NOT NULL
Table 23: data dictionary for account
74
5
Data dictionary for Marriage Registration

MARRIAGE_ID VARCHAR(20) PRIMARY KEY
MARRIAGE_DATE DATE NOT NULL
RESIDENT_ID VARCHAR(20) FORIGN KEY
VISITOR’S_FULL_NAME CHAR(50) NOT NULL
VISITOR’S CHAR(50) NOT NULL
_PERMANENT_ADDR
VISITOR’S _PHOTO BLOB NOT NULL
VISITOR’S _PHONE_NO UNSIGNED INT NOT NULL
VISITOR’S CHAR(30) NOT NULL
_OCCUPATION
Table 24: data dictionary for marriage registration
Data dictionary for Death registration

PLACE_OF_DEATH CHAR(30) NOT NULL
DATE_OF_DEATH DATE NOT NULL
SUMERRY_OF_DEATH CHAR(80) NOT NULL
INFORMANT_FULLNAM CHAR(50) NOT NULL
E
Table 25: data dictionary for death registration
Data dictionary for Birth Registration

CHILD_ID VARCHAR(20) PRIMARY KEY
FNAME CHAR(20) NOT NULL
MNAME CHAR(20) NOT NULL
LNAME CHAR(20) NOT NULL
DATE_OF_BIRTH DATE NOT NULL
FAMILY_PHONE_NO UNSIGNED INT NOT NULL
MOTHER_FULL_NAME CHAR(50) NOT NULL
75
5
PLACE_OF_BIRTH CHAR(40) NOT NULL
RELIGION_OF_FAMILY CHAR(30) NOT NULL
FATHER’S CHAR(40) NOT NULL
_OCCUPATION
MOTHER’S_ CHAR(40) NOT NULL
OCCUPATION
BIRTH_WIGHT UNSIGNED NOT NULL
MOTHER’S _AGE UNSIGNED INT NOT NULL
FATHER’S_AGE UNSIGNED INT NOT NULL
Table 26: data dictionary for birth registration
Data dictionary for User Type

USER_ID VARCHAR(8) PRIMARY KEY
USER_ DESCRIPTION CHAR(20) NOT NULL
Table 27: user type data dictionary
Data dictionary for House

HOUSE_NO VARCHAR(20) PRIMARY KEY
KEBELE_NO UNSIGNED INT FORIGN KEY
OWNERSHIP CHAR(30) NOT NULL
Table 28: data dictionary for house
Data dictionary for Divorce registration

MARRIAGE_ID VARCHAR(20) FORIGN KEY
DATE_OF_DIVORCE DATE NOT NULL
SUMMERY_OF_DIVORCE CHAR(80) NOT NULL
Table 29: data dictionary for divorce registration
Data dictionary for kebele
76
5
KEBELE_NO UNSIGNED INT PRIMARY KEY
KEBELE_NAME CHAR(20) NOT NULL
ADDRESS CHAR(50) NOT NULL
KEBELE_LEADER_FULLNAM CHAR(50) NOT NULL
E
Table 30: data dictionary for kebele
Data dictionary for Administrators

ADMIN_ID VARCHAR(10) PRIMARY KEY
FULL_NAME CHAR(50) NOT NULL
SEX CHAR(6) NOT NULL
RESPONSIBILITY CHAR(20) NOT NULL
USER _TYPE CHAR(20) NOT NULL
PHONE NUMBER UNSIGNED INT NOT NULL
Table 31: administrators’ data dictionary
4.8. Access control and Security

We know that Haramaya city civil and vital registration system will be multi user system.
Because of this, different actors have access to different functionality and data. For example,
an everyday actor may only access the data it creates, whereas a system administrator actor
may have unlimited access to system data and other users’ data and so on. As a result, it is
necessary to specify how actors can control access. Depending on the security requirements of
the system, we can also define how actors are authenticated to the system.
The access control for the Haramaya city civil and vital registration system will be
implemented through the capabilities lists. This representation comes up to be compact and
efficient for the system. A capability associates a (class, operations) paired with an actor. A
capability allows an actor access to the operation of the class. Denying access means denying
capability. In our proposed system we will have three capability lists.
The following three tables show the access control and security of Haramaya city civil and
1. City administrator capability lists
Class Operation
Resident search()
77
5
Account create_account()
remove_account()
modify_account()
Population distribution view_population_distribution()
Report vital certificate generate_report()
Table 32: city administrator capability lists
2. Kebele administrator capability lists
Class operation
Resident search_in_kebele()
Population distribution view_population_in_kebele()
Resident registration register_resident()
update_resident_vital_info()
register_marriage()
Account modify_account()
Table 33: kebele administrator capability list
3. Resident capability lists
Class operation
Request vital certificate send_request()
Account modify_account()
Table 34: resident capability list
4.9. Global control flow

We are going to bring into play two global control policies for Haramaya city civil and vital
registration system in order to make it standardized. These are:
 Procedural driven control flow: this control flow advocates that users of Haramaya
city civil and vital registration system should have to follow the system procedures and wait for
the system to give response before using it.
 Event driven control flow: this control flow is responsible for handling different events
of Haramaya city civil and vital registration system and dispatching to the appropriate object
based on information associated.
For more, let’s see activities of both control flows of Haramaya city civil and vital registration
system when a user interacts with system.
78
5
Activity Procedural driven control flow Event driven control
flow
Login  A user of the system enters  To be logged in, the
username and password and then login button should be
they will be authenticated, then pressed.
their Homepage will be displayed.
Resident registration  Kebele administrator fills the  To register resident,
registration criteria, and then the register button is
he/she will get successful pressed.
registration.
Request vital certificate  To send a request for vital  To send a request, the
certificate, resident fills request button should
appropriate request criteria. be pressed.
Report vital certificate  City administrator fills the report  To report for the
criteria, then requester will get request, the request
vital certificate. button should be
pressed.
Search resident  Authorized users fill up the search  The search button
criteria and they will get what the should be pressed to
search search resident
Update resident vital  Kebele administrator fill up the  Press update button to
information update criteria to get updated update residents vital
resident vital information information
Create account  City administrator fills the creating  Press create account
account criteria, then he/she will button to create
add accounts accounts
Modify account  Authorized user fills the account  Press modify account
modification criteria, then button to modify
accounts will be modified accounts
Remove account  City administrator fills the  To remove account,
removing account criteria, then remove account button
he/she will remove accounts should be pressed
Table 35: global control flow
79
5
4.10. Boundary Condition
Haramaya city civil and vital registration system will have boundary conditions to start,
shutdown, and handle failures of the system. As we know, Haramaya city civil and vital
registration system is going to formulate the recognition of Haramaya city by providing vital
services to the residents. Therefore, the system is not expected to be started and shutdown at all
times rather the system should be available all the time to prop up different services to the
residents of the city. But when some conditions like maintenance, security purpose and so on
occur, the system will be shutdown and will start up again. It also considers the need of starting
the system when failure occurs.
The following tables show different boundary conditions of Haramaya city civil and vital
Boundary condition for start up the system
Name Start Haramaya city civil and vital registration system

Actor City administrator
Entry condition Haramaya city Apache server launch
Flow of events 1. The city administrator launches the Apache server
2. The city administrator start up the Haramaya city civil and vital
registration system
3. The system launches the MySQL server
Exit condition Exit when both the MySQL and Apache servers have been launched and
are running.
If either server fails to launch, a diagnostic message is displayed and the

Exceptions Appropriate error log is updated.
Special The city administrator has appropriate access level to control Haramaya
requirement city civil and vital registration system.
Table 36: boundary condition for start up the system
Boundary condition for Shutdown the system
Name Shutdown Haramaya city civil and vital registration system

Entry condition Haramaya city civil and vital registration system on working
80
5
condition.
Flow of events 1. The system instigates the MySQL server
2. The system then also instigates the Apache server
3. The city administrator clicks on shutdown the system
4. Confirmation for shut down displayed
5. Click on shut down the system.
Exit condition
The system shut down when all the connections are cancelled.
Special The administrator has the appropriate access level to shut down the
requirement system.
Table 37: boundary condition for shutdown the system
Boundary condition for database failure
Name Haramaya city civil and vital registration system Database

Entry condition Haramaya city civil and vital registration system connected to the
database
Flow of events 1. The city administrator starts up the Haramaya city civil and
2. Connection between the system and the database created and
the system launches the MySQL server
3. Access the database.
Exit condition The use case ends when connection ends.
If the database fails to launch, a diagnostic message is displayed and

Exceptions the appropriate error log is updated.
Special The city administrator has the appropriate access level to access the
requirement database
Table 38: boundary condition for database failure
81
5
Reference
Books
[1] Object-Oriented Software Engineering Practical Software Development using UML and
Java Lethbridge/Laganière 2005
[2] The Unified Modeling Language Reference Manual, James Rumbaugh, Ivar Jacobson and
Grady Booch, Addison Wesley, 1999.
Websites
[1] http://www.cs.mu.oz.au/
[2] http://www.developer.com/design/article.php/1553851/
[3] http://www.agilemodeling.com/
82
5
short
month form days season
1 tri January Jan. 31 winter
2 lekatit February Feb. 28/29
3 megabit March Mar. 31 spring
4 mazya April Apr. 30
5 gunbet May May 31
6sene June Jun. 30 summer
7 hamle July Jul. 31
8 nehse August Aug. 31
9meskere September Sep. 30 autumn

m
83
5
short
month form days season
10tkmti October Oct. 31
11hidar November Nov. 30
12 tahsas December Dec. 31 winter
84

Haramaya City Civil and Vital Registration System: Chapter One

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Haramaya City Civil and Vital Registration System: Chapter One

Uploaded by

Copyright:

Available Formats

Haramaya City Civil And Vital Registration System 2014/1

1.2. Review of Related Work (Literature Review)

1.3. Statement of the problem

1.4.2. Specific Objective

 To study the current working structure of municipal of Haramaya city.

1.5.3. System Development Tool

1.5.3.1. Web Development Tool

PHP5 with CAKEPHP framework

JQuery magistrate witiness

1.5.2.2 Database Development Tool

MySQL version 5.0.51b

 Because of its unique storage engine architecture, MySQL’s performance is very

Sublime text editor

1.5.2.4. Hardware description

1.6. Scope and Limitation

1.7. Significance of the project

1.8. Work breakdown

SYSTEM REQUIREMENT AND SPECIFICATION

2.1. Existing System

2.2. Proposed System

2.2.2. Functional Requirement

Requesting vital certificate

Reporting vital concerns

2.2.3. Non functional requirement

2.3. Feasibility Study

SYSTEM MODEL AND DATA DESCRIPTION

3.1. Use Case Model Modeling

Actors of the system

NO Actor name Description

Figure 1: essential use case diagram

Resident Remove account

Search <<include>> Search resident

Figure 2: system use case diagram

Use case Description

Use case Identifier

Login use case description

Use case name Login

2. The System displays the login page.

4. The system validates the account.

5. The system displays the appropriate home page.

6. The user access the system.

7. Use case end.

Register Resident use case description

Use case name Register Resident

Update Resident vital information use case description

Use case name Update resident vital information.

1. Kebele administrator wants to update citizen’s vital information.

Alternative course of action A: if the Kebele administrator doesn’t obtain all

A.2. use case ends.

Alternative course of action B: If the Kebele administrator enters invalid information

B.5. the system determines that the entered information is invalid.

B.6. the system displays “invalid information”.

B.7. Use case ends.

Search Resident use case description

Use case name Search resident

1. City administrator wants to search for citizens of the city.

Alternative course of action

Alternative course of action A: if the city administrator enters invalid personal

A.5. use case ends.

Search resident in kebele use case description

Use case name Search resident in kebele.

1. kebele administrator wants to search for citizens of the city.

Alternative course of action A: if the kebele administrator enters invalid personal