Institute of Technology

Faculty of Informatics
Department of Computer Science (CEP)
Final Project
Title: ONLINE AUTOMATED ETHIOPIAN POSTAL SERVICE
By
GROUP NAME……… …………ID NO

1. Yacob Yohannes……………………………….EVCS/1206/09

2. Abraham Beyene……………………………….EVCS/005/09

3. Abduselam kasim……………………………….EVCS/198/09

Hawassa, Ethiopia
May, 2021

Advisor: Ayele S.
Contents
Abstract ................................................................................................................................................. vii

Acknowledgement ............................................................................................................................... viii

CHAPTER ONE: .................................................................................................................................... 1

INTRODUCTION .................................................................................................................................. 1

1.1. Background of the Study ............................................................................................................. 1

1.2. Statement of the Problem ............................................................................................................. 2

1.3. Objectives of the Project .............................................................................................................. 2

1.3.1. General Objective ................................................................................................................. 2

1.3.2. Specific objectives ................................................................................................................ 2

1.4. Scope of the Study ....................................................................................................................... 3

1.5. Limitation of the Study .............................................................................................................. 3

1.6. Methodology ............................................................................................................................. 3

1.6.1. Data Collection Methodology ......................................................................................... 3

Observation .................................................................................................................................. 3

1.6.2. System Analysis and Design Methodology ........................................................................ 4

1.6.3. System Implementation......................................................................................................... 4

1.6.4. Testing and Deployment Methodology................................................................................. 4

1.6.5. Development Environment ................................................................................................... 5

1.6.6. System Requirement. ............................................................................................................ 5

CHAPTER TWO .................................................................................................................................... 6

DESCRIPTIONS OF EXSTING SYSTEM ........................................................................................... 6

2.1. Introduction of the Existing System. ............................................................................................ 6

i
 2.2. Proposed System Description. ..................................................................................................... 8

2.3. Strength of Existing System......................................................................................................... 8

2.4. Weakness of Existing System. ..................................................................................................... 8

CHAPTER THREE ................................................................................................................................ 9

SYSTEM FEATURES............................................................................................................................ 9

3.1. Introduction .................................................................................................................................. 9

3.2. Functional Requirements ............................................................................................................. 9

3.3. Non-Functional Requirements ................................................................................................... 10

3.4. Analysis Models......................................................................................................................... 11

3.4.1. Use Case Diagrams ............................................................................................................. 11

3.4.2. Sequence Diagram .............................................................................................................. 36

3.4.3. Activity Diagram .................................................................................................................. 49

3.4.4. Class diagram ...................................................................................................................... 53

CHAPTER FOUR................................................................................................................................. 54

SYSTEM DESIGN ............................................................................................................................... 54

4.1. Introduction ................................................................................................................................ 54

4.2. Purpose of the System Design Document .................................................................................. 54

4.3. Architectural Design of the System ........................................................................................... 55

4.3.1. Logical View of the Architecture ......................................................................................... 55

4.3.2. Process View ....................................................................................................................... 56

4.3.3. Deployment View ............................................................................................................... 57

4.4. Database Design......................................................................................................................... 58

4.5 User Interface Design ................................................................................................................. 59

ii
CHAPTER FIVE .................................................................................................................................. 62

CONCLUSION AND RECOMMENDATION .................................................................................... 62

1.1. Conclusion ................................................................................................................................. 62

1.2. Recommendation ....................................................................................................................... 62

References ..................................................................................................................................... 63

Appendix ............................................................................................................................................... 64

Definitions, Acronyms and abbreviations ......................................................................................... 64

Definitions ..................................................................................................................................... 64

Acronyms and Abbreviations ........................................................................................................... 64

iii
 List of Figures

Figure 1.Use case diagram for system administrator ............................................................................ 12

Figure 2.Use case diagram for counter ................................................................................................. 13

Figure 3.Use case diagram for system Postman.................................................................................... 14

Figure 4.Use case diagram for Customers ............................................................................................ 15

Figure 5.Sequence diagram for login to the system .............................................................................. 36

Figure 6. Sequence diagram for user registration ............................................................................... 37

Figure 7. Sequence diagram for renting post box ................................................................................. 38

Figure 8. Sequence diagram for material registration .......................................................................... 39

Figure 9. Sequence diagram for sent airmail registration ..................................................................... 40

Figure 10. Sequence diagram for received airmail registration ............................................................ 41

Figure 11. Sequence diagram for searching material information from the database ........................... 42

Figure 12. Sequence diagram for searching airmail information from the data base ........................... 43

Figure 13. Sequence diagram for searching post box information from the data base ......................... 44

Figure 14. Sequence diagram for updating post box information to the database ................................ 45

Figure 15. Sequence diagram for deleting post box from the database ................................................ 46

Figure 16. Sequence diagram for create account .................................................................................. 47

Figure 17. Sequence diagram for Check_Track.................................................................................... 48

Figure 18. Activity diagram for administrator ...................................................................................... 49

Figure 19. Activity diagram for counter ............................................................................................... 50

Figure 20. Activity diagram for Postman.............................................................................................. 51

Figure 21. Activity diagram for Customers .......................................................................................... 52

Figure 22. Class diagram for the system ............................................................................................... 53

Figure 23. Logical View of the Architecture ........................................................................................ 55

Figure 24.Process View ........................................................................................................................ 56

iv
Figure 25.Deployment diagram ............................................................................................................ 57

Figure 26.Database Design ................................................................................................................... 58

Figure 27 .Admin Login page interface ................................................................................................ 60

Figure 28.Counter Login page interface ............................................................................................... 61

Figure 29.User Login page interface..................................................................................................... 61

v
 List of Tables

Table 1.development tools ...................................................................................................................... 5

Table 2.Use case Description of Login ................................................................................................. 16

Table 3.The scenario or use case description of the user registration use case..................................... 17

Table 4 The scenario or use case description of the rent post box use case.......................................... 18

Table 5.The scenario or use case description of the material registration use case. ............................. 19

Table 6. The scenario or use case description of the sent airmails registration use case. ..................... 20

Table 7.The scenario or use case description of the received airmails registration use case. ............... 21

Table 8.The scenario or use case description of the search user use case............................................. 22

Table 9.The scenario or use case description of the update user use case ............................................ 23

Table 10. The scenario or use case description of the delete user use case .......................................... 24

Table 11.The scenario or use case description of the Search airmail use case ..................................... 25

Table 12.The scenario or use case description of the update airmail use case ..................................... 26

Table 13.The scenario or use case description of the delete airmail use case....................................... 27

Table 14.The scenario or use case description of the search materials use case ................................... 28

Table 15.The scenario or use case description of the update materials use case .................................. 29

Table 16.The scenario or use case description of the delete materials use case ................................... 30

Table 17.The scenario or use case description of the search post box use case.................................... 31

Table 18.The scenario or use case description of the updated post box use case ................................. 32

Table 19.The scenario or use case description of the delete post box use case .................................... 33

Table 20.The scenario or use case description of the Check_Track use case ....................................... 34

Table 21.The scenario or use case description of the Create_account use case .................................... 35

Table 22.Database Normalization ......................................................................................................... 59

vi
 Abstract

Postal service system is one of the widely used communication media in the world. Now a

day’s technology is highly accelerating throughout the world. Due to this reason

computerizing the postal service system has a lot of advantages. This project is aimed to

automate Ethiopian postal service system. The proposed system will have the capabilities to

store information about airmail transaction, update information, search information, store

information about material that stored in store room and store contact information of renting

post box.

vii
 Acknowledgement

First of all we would like to thanks our God (Allah) because helps us in every success of our

work. Next to this we would like to express deepest gratitude to our advisor Ayele S. for his

excellent advice and passionate guidance throughout this project. Finally we would also like

to thanks our team members for our contribution and shared ideas for the successful

completion of the project. We also thank our department as well as the project coordinator of

CEP program for their commitment make us to conduct this study.

viii
 CHAPTER ONE:
INTRODUCTION
1.1. Background of the Study
The origin of postal service dates back to the middle Ages and was developed from the medieval
system of royal messengers whom employed to carry government documents from one place to
another. In most countries, the postal service developed in the 18th century when different means of
transport such as mules, horses, camels and stage-caches were used to carry mail. In some Middle-
Eastern countries even falcons were specially trained to carry written messages from one place to
another. The first railway mails were carried in Europe in 1830. The establishment of the Universal
Postal Union (UPU) in 1875 is what greatly promoted international mail services. Prior to the
establishment of the postal service in Ethiopia on March 9, 1894 following an imperial edict,
correspondence was conducted through messengers known as „melektegnas or postegnas‟. These
tough individuals travelled great distances, often on foot, overcoming rough landscape and weathering
hostile climate. They endured the pangs of hunger and thirst and carried their letters over their heads,
on cleft sticks (which later became the symbol of the post office still today) until they reached their
destination. Ethiopian Postal Service was established nearly two decades after the birth of UPU. The
second half of the 19th century in Ethiopia was characterized by the establishment and consolidation
of the empire state under the protection of Emperor Menelik. Menelik found in the postal service, like
the telephone and the telegraph, a vital means of exchanging information, first for political and
administrative purposes and later on for public correspondence [7].

The construction of the Djibouti - Addis Ababa train made it possible for letters, parcels and

merchandise, which were previously transported on camel back. This was a crucial factor that greatly

improved the pace and efficiency of the postal service while it laid the basis for the international

exchange of mail. Then Ethiopia became a member of the Universal Postal Union in 1908.

Ethiopia has at present over 1,200 post offices. Out of this 1,016 Permanent post offices,130

Departmental sub-post offices, 261 Sub-post offices and 2 Visiting postmen in rural areas and over

170000 post boxes. It is estimated that one post office is serving 79,116 inhabitants while In the result

of opportunities and challenges, Ethiopian postal service establishes EMS (express mail service) in

1989. The introduction of EMS has made the Ethiopian Postal Service competitive in the express

delivery market. Today Ethiopian postal service is under the implementation of business process

1
reengineering (BPR), which had been study for 18 months. Due to this the structure become process

and customer oriented. The managers and the employees are doing their best to accomplish the needs

of their customers. while one private box serves 558 people [7].

1.2. Statement of the Problem

In fact, Ethiopian postal service is one of the most crucial as well as backbone of the people by giving

postal related services as well as any other services which can be transfer through postal system, still

the system generally does follow or perform the manual system or paper based system and somewhat

automated to provide service to its customers. So that using manual system has a lot of problems in

many cases.

Moreover, the following are problems that are present in the current system of postal service

system in general. Because of this reason the organization faced to many problems. The problems are:-

 Work load of the Employers is very high means takes much time to perform simple tasks.
 Takes time to retrieve data means it has spent of time to get necessary data from stored data.
 Difficult to update data means its very hard to modify past data.
 Wastage of resources (like cabinet, paper…etc.
 Loss of data and poor organized and unsecured data. This also leads to Security problem not
protect the data from an unauthorized person and doesn‟t keep the organization‟s safety.
 Date or time limitation problem in which the system doesn‟t keep track of sending and
receiving different materials deliver in the customer‟s expected time and date. Example,
postponing the expected time or date.

N.B: The problems that raised in the above limit the organization not to give reliable and fast service

to its customers.

1.3. Objectives of the Project

1.3.1. General Objective

The general objective of this project is to develop and implement online postal service for Ethiopia.

1.3.2. Specific objectives

The specific objectives are listed below:-

2
  To design central and well-structured database management system.
 To eliminate redundancy of data.
 To develop web based application through an internet connection.
 To makes fast searching and give information about Postal service.
 To indicate the address of the Postal Office through an internet connection.

1.4. Scope of the Study

Scope of this project means the boundary that we are performing tasks in this project. The proposed

system that we will try to automate is limited and bounded on the Ethiopian postal services. It will

perform how to:-

 Track management that checks the sent messages of customers through their user account.
 Rent post box services.
 Employee management.
 Store data in data base.
 Mail management.

1.5. Limitation of the Study

There are many factors that limited us to minimize our scope, such as time limitation, resource,

place, and complexity of the system. In general our proposed system is limited to perform the

following tasks because of the above mentioned factors.

 Paying pension.
 Forming DV lottery.
 Selling SIM cards, CDMA/WCDMA, mobile cards.
 Western Union services.
1.6. Methodology

1.6.1. Data Collection Methodology

To gather the requirement of the system we use different types of fact finding methods those are:-

Observation

By observing the current working environment of Hawassa post office, we collect data which

necessary for automating of Hawassa postal service system. In our observation we have tried to

observe things mentioned below

 The general system of providing service in the current system.

 How the system handles and store material‟s information.

3
  A type of document format is there printed or non-printed.

1.6.2. System Analysis and Design Methodology

Here for the analysis of our project we have selected object oriented system analysis and design
method specifically UML (Unified Modeling Language) model. We have selected this because of the
following advantages:-
 To simplify the design and implementation of complex program.
 To make it easier for teams of designers and programmers to work in a single software project.

 To enable a high degree of reusability of designs and of software codes.

 To decrease the cost of software maintenance.
 Increase reusability.
 Reduce maintenance burden.
 Increased consistency among analysis, design and programming activities.

 Improved communication among users, analysis, design and programming

1.6.3. System Implementation

Implementation is a realization of a technical specification or algorithm as a program, software

component through programming. there are different types of tools available to implement the system

from those tools we select php to develop front end of the system, Wamp2.5 server to develop back

end of the system ,UML editor to sketch different UML diagrams and Microsoft word 2010 to prepare

the documentation part of the project .

1.6.4. Testing and Deployment Methodology

Testing methodologies are approaches to testing, from unit testing through system testing and beyond.

There is no formally recognized body of testing methodologies, and very rarely will you ever find a

unified set of definitions. But here are some common methodologies:

Unit testing: The act of testing software at the most basic (object) level. Generally performed by

developers, run in "friend classes" with code-level access to read and manipulate objects.

System testing: Testing the project as a collective system. System testing generally combines multiple

features into an end-to-end process or scenario.

4
 1.6.5. Development Environment

The development method we are using to develop the proposed system is the Waterfall approach.

Waterfall Methodology: All projects can be managed better when segmented into a hierarchy of

chunks such as phases, stages, activities, tasks and steps.

1.6.6. System Requirement.

The tools that we are going to use throughout our project are listed in the following table as grouped

into hardware tools & software tools.

Table 1.development tools

Tools

Hardware Software

 Wamp server 2.5 :To run the site on the tool

 Flash Disk : at minimum 8GB
 CD-R: to the maximum of 700MB
bar
 npp.6.5.5.Installer : To edit the entire
implementation code
 Sql database server: To store data
 Visual paradigm for UML 10.2 : to draw
UML diagrams

5
 CHAPTER TWO
DESCRIPTIONS OF EXSTING SYSTEM

2.1. Introduction of the Existing System.

Currently the Ethiopian Postal Service System mostly follows manual based system and somewhat

automated to provide service to its customers. The services provided by the system are:-

 Sending and receiving airmail.

 Renting post box.

 Giving western union service.

 Paying pension

 Forming of DV lottery

 Selling SIM ,CDMA/WCDMA, mobile cards

i. Sending and receiving airmail

There are different kinds of airmail. Those are

 Ordinary airmail

 Registered airmail

 EMS

 First order airmail

 Parcel airmail

a. Sending airmail

On the process of sending airmail if a customer want to send an airmail, first she/he contact the

counter, then he/she must select the types of airmail, the counter receives the airmail to check whether

the address of both sender and receiver are valid or not .Second, the counter measures the weight of

the airmail, attach postage stamp and record the information available on airmail (date of sending,

registration no, sender address, receiver address, weight, barcode number(for EMS air mail), cost and

price) in three copies on the form. Finally the customer pays the price and receives the receipt. Then

6
the counter starts to collect daily received airmails and group together according to their destination,

then packed and gives to the messenger/postman. The messenger/postman takes the packed airmails to

the bus station and distribute to different expected sites of the customers.

b. Receiving airmail.

Every day the messenger/postman brings the packed airmails from the bus station and gives to the

counter. The counter registers all received airmails. Then, if the airmail is ordinary or first order

airmail the counter distribute it to the post box of a customer .But type of airmail is either registered or

parcel, the counter distribute registered letter 1st advice form (if the customer received a single

airmail) or collective 1st advice form (if the customer has more than one received letter).

For EMS the messenger/postman directly contact the customer and gives the airmail.

ii. Renting post box

The customer fills contract renting post box form and pay 48 birr for a single post box and 20 birr for
key. Then the counter records the information of the customer.

iii. Giving western union money transfer service

The counter receive a Fax message about the receiver information, sender address ,amount of money
and date of sending .Then ,by recording the above information she/he pay the money sent to the
receiver.

iv. Paying pension

The counter pay the pension for customers according to the list comes from Ethiopia Finance Minister
by recording all necessary personal information such as name, address, status, phone No, etc.

v. Forming of DV lottery

The customers who want to apply DV lottery of a year through postal system fill the form by fulfilling
all requirements. The counter collects and registers all DV lottery forms.

vi. Selling SIM, CDMA/WCDMA, mobile cards

The counter sells SIM card to different customers by registering their personal information such as
name, id. Number, address, phone number, PIN code and PUK code of the sold SIM card.

7
2.2. Proposed System Description.
In fact, postal service is one of the most crucial as well as backbone of the people by giving postal
related services as well as any other services which can be transfer through postal system,

still the system generally does follow or perform the manual system or paper based system. So that
using manual system has a lot of problems in many cases.

We have selected this postal service system, because there are a lot of problem in the postal system

and we are going to change this system to be:-

 Automated or computerized system.

 Secured.
 Date or time limited.
 Online service.
 Store the data in the database.
 Reduce redundancy.
 Reduce work load.

2.3. Strength of Existing System.

The employees provide service to the society by:-

 Working overtime.

 Loyal able to the customers.

 Punctual to the society.

 Honesty to the users.

 Responsible and transparent for their actions.

2.4. Weakness of Existing System.

The weaknesses of the existing system are:-

 Use more human power: - since the system is not some more computerized it use more human

power to give service.

 There is duplication of data:-because of the data are not well organized and structured.

 There is disorder of data: - because the data are not stored sequentially.

8
 CHAPTER THREE

SYSTEM FEATURES
3.1. Introduction

As we mentioned in the above section, in this project, the team members used an object oriented
system development methodology which incorporates principal phases. In this chapter, what the team
will do is the object oriented analysis (OOA).
The analysis of an information system produces the details that clearly describe how a system will
meet the requirements identified during earlier steps. Model is an abstraction of the real world. It
allows us to deal with the complexity current in a real-world problem by focusing on the essential and
interesting features of an application. The techniques and associated notation used for object oriented
analysis and design in incorporated in to a standard object – oriented language called Unify Modeling
language (UML). An important goal of requirement modeling is come to an understanding of the
problem that the new system is to address. This chapter focuses on developing the requirement and
analysis models for the new system using the UML class responsibility and use case model, activity
diagram, Sequence Diagram, Class diagram and . User Interface Design.

3.2. Functional Requirements

Functional requirements describe the interactions between the system and its Environment

independent of its implementation. The environment includes the user and any other external system

with which the system interacts. The system should provide how the system should react to particular

inputs and how the systems behave in particular situations.

The following are the functional requirements of the system:-

 User management

 The system verify user account to login in to the system by checking their information

 The system handles user information

 The system enables Users/Customers to change their password.

 Mail management

 The system register different types of airmails and materials information

 The system provides data manipulation service such as insertion, updating and deletion

9
  The system enable users to search data

 The system should enable Users/Customers to change their password.

 Customers can write comments, suggestions, questions, and thanks on the online service of the

system.

 Box rent management

 The system enables user to rent boxes

 The system enables user to return boxes

 Tracking: the system enables users to track their mails.

3.3. Non-Functional Requirements

Non-functional requirements describe user-visible aspects of the system that are not directly related

with the functional behavior of the system. Nonfunctional requirements include quantitative

constraints, such as response time (i.e., how fast the system reacts to user commands) or accuracy (i.e.,

how precise are the system‟s numerical answers). The nonfunctional requirements of our system will

address are discussed as follows:-

 Robustness: - the system should be robust while validating data during data entry. It also ability to

survive invalid user input

 Security: - the system should be secured and protected from unauthorized user. It should have a

user‟s database and should authenticate each user on login and should grant user specific services.

 User interface:-the system should have friendly user interface

 Performance: - System will have good performance as much as possible this will be attained via

easily loadable interface components and optimal algorithms which make searching, updating,

deleting, inserting and saving easy and fast.

 Error handling mechanism: - the system must have error handling mechanism. It is not stop

functioning rather it must report an error message

 Documentation:-the system will provide the system description document for the client.

10
3.4. Analysis Models

3.4.1. Use Case Diagrams

Use case diagrams for the proposed system are used to represent the basic functionalities of the system

as Use cases focus on the behavior of the system from an external point of view. It also represents user

requirements gathered during requirement elicitation, contains use case, actors, system boundary and

their relationships.

 Use-case modeling

Use-case model consists of the collection of all actors and all use case, a use case is a scenario that

describes the use of the system by an actor to accomplish a specific goals, an actor is a user playing a

role with respect to the system. Scenario is a sequence of step that describes the interaction between an

actor and the system.

 Use cases

 Login  Update airmail

 Register user  Delete airmail
 Renting post box  Search material
 Record material  Update material
 Record sent airmail  Delete material
 Record received airmail  Search post box
 Search user  Update post box
 Update user  Delete post box
 Delete user  Check track
 Search airmail  Create account

 Actors

 Administrator

 Counter

 Postman

 Customers

 Actors Specification

Administrator: is a person who registers user, update and delete information about the user.

11
Counter: is a person who register, update and delete sent and received airmails and rent post box

information.

Postman: is a person who sends and receives airmails as well as materials to and from customers

respectively. Also who can register, update, search and delete materials in the system.

Customers: are people or any users who can send and receive whatever their materials using the

Ethiopian postal service system throughout the world.

 Use Case diagram of our system is shown as follows with respective description.

Figure 1.Use case diagram for system administrator

12
Figure 2.Use case diagram for counter

13
Figure 3.Use case diagram for system Postman

14
Figure 4.Use case diagram for Customers

15
  Use case Description and Scenario

Table 2.Use case Description of Login

UC Name Login

UC Description Enables all users of the system to login.

Actor Administrator, Counter, Postman, Customers

Precondition The users should have an account

Flow of event 1. The user activates the system.

UC-01 2. The system display login window
3. The user type user id and password and click login button.
4. The system checks and validates the entered user id and
password. [A1:A2].
5. The system displays the main window.
6. The system displays access page for the respective user.
7. Use case ends

Post condition The user entered to the system and can access the system.

Alternative course of A1: Information Not Filled Message

action 1. The system displays “Please enter your user name and
password!” message.
2. The system resumes at step 3.
A2: Invalid Entry Message
1. The system displays “Incorrect User Name or Password!”
massage.
2. The system resumes at step 3.

16
Table 3.The scenario or use case description of the user registration use case

UC Name User registration

UC Description Allows administrator to register user information.

Actor Administrator

Precondition The administrator should successfully login into the system.

Flow of event 1. The administrator selects the “Add user” menu.

UC-02 2. The system displays the user registration form.
3. The administrator fills the form and submits it by clicking
“Add” button
4. The system checks and validates the entered data. [A1:A2].
5. The system display “user is registered successfully ”
message
6. The system saves the registered user account of the Users.
7. Use case ends.

Post condition The account of the users registered (created).

Alternative course of A1: Wrong data Entry Message

action 1. The system displays “Wrong data Entry!” message.
2. The system resumes at step 3.
A2: Missing of Required Information Message
1. The system displays “Fill all information!” massage.
2. The system resumes at step 3.

17
Table 4 The scenario or use case description of the rent post box use case

UC Name Renting post box

UC Description Allows rent post box..

Actor Counter

Precondition The counter should have logged into the system

Flow of event 1. The counter selects “Rent post box‟ menu.

UC-03 2. The counter completes and submits the rent post box form by
clicking “Rent” button.
3. The system checks and validates the entered data.[A1]
4. The system display “Renting is successfully completed”
message.
5. Use case ends.

Post condition The account of the users registered (created).

Alternative course of A1: The post box was rented by other user.
action 1. The system displays “The post box was rented by another
user!” message.
2. The system resumes at step 2.

18
Table 5.The scenario or use case description of the material registration use case.

UC Name Material registration

UC Description Allows the postman and counter to recorded information

regarding to material stored in store room.

Actor Counter or postman

Precondition The counter and postman should have logged into the system

UC-04 Flow of event . 1. They selects “Add material” menu.

2. They should complete and submits material‟s registration
form by clicking “Add” button.
3. The system checks and validates the entered data.[A1:A2]
4. The system displays “material information recorded”
message
5. Use case ends

Post condition Material information is registered.

Alternative course of A1: Wrong data Entry Message

action 1. The system displays “Wrong data Entry!” message.
2. The system resumes at step 2.
A2: Missing of Required Information Message
3. The system displays “Fill all information!” massage.
4. The system resumes at step 2.

19
Table 6. The scenario or use case description of the sent airmails registration use case.

UC Name Sent airmail register

UC Description Allows counter to register sent airmails

Actor Counter

Precondition The counter should have logged into the system

Flow of event 1. They selects “Add material” menu.

UC-05 2. They should complete and submits airmail‟s registration
form by clicking “Add” button.
3. The system checks and validates the entered data. [A1].
4. The system displays “airmail information recorded” message
5.Use case ends

Post condition Sent airmail information is registered

Alternative course of A1: invalid data

action A.1 The system informs the counter the entered data is invalid
by displaying “you have entered invalid data” message and
prompts the user to enter the data correctly.
A.2 Use click “ok” button.
A.3 Use case resume at step 2

20
Table 7.The scenario or use case description of the received airmails registration use case.

UC Name Received airmail registration

UC Description Allows counter to register received airmails.

Actor Counter

Precondition The Counter should have logged in to the system.

Flow of event 1. Counter selects “Add received airmail” menu.

UC-06 2. Counter completes and submits the received airmail
registration form by clicking “Add” button.
3. The system checks and validates the entered data. [A1].
4. The system displays “airmail is successfully registered”
message
5. Use case ends.

Post condition Received airmail information is registered

Alternative course of A1: invalid data

action A.1 The system informs the counter the entered data is invalid
by displaying “you have entered invalid data” message and
prompts the user to enter the data correctly.
A.2 Use click “ok” button.
A.3 Use case resume at step 2.

21
Table 8.The scenario or use case description of the search user use case.

UC Name Search user

UC Description Allow administrator to search or view user data from the

database.

Actor Administrator

Precondition The administrator should have logged in to the system.

UC-07 Flow of event 1. The administrator selects the “Search” button.

2. The system requests the user to enter correct registration
number.
3. The system checks and validate the entered registration
number[A1]
4. The system display and view the searched information
5. Use case ends.

Post condition Administrator will view the searched information.

Alternative course of A1: invalid registration number

action A.1 The system informs the administrator the entered
registration number is invalid by displaying “you have entered
invalid registration number” message and prompts the
administrator to enter the registration number correctly.
A.2 Use click “ok” button.
A.3 Use case resume at step 2.

22
Table 9.The scenario or use case description of the update user use case

UC Name Update user

UC Description Allows administrator to update user information to the

database.

Actor Administrator

Precondition The administrator should have logged in to the system.

UC-08 Flow of event 1. The user selects the “Update” button.

2. The system requests the user to enter correct registration
number.
3. The system display and view the searched information.
4. The administrator selects “clear” button.
5. The administrator fills update form
6. The administrator click “Add” Button
7. The system checks and validates the entered data. [A1].
8. The system displays “update is successfully completed”
message.
9. Use case ends.

Post condition Administrator will view the searched information.

Alternative course of A1: invalid data

action A.1 System displays “Invalid data entries please try again”
A.2 User click “ok” button.
A.3 Use case resume at step 7

23
Table 10. The scenario or use case description of the delete user use case

UC Name Delete user

UC Description Allows administrator to delete user information to the database.

Actor Administrator

Precondition The administrator should have logged in to the system.

Flow of event 1. The administrator enter registration number.

UC-09 2. The administrator click “Search” button.
3. The system checks and validates the registration
number.[A1:A2].
4. The system displays the searched information.
5. The administrator click “Delete” button.
6. The system displays “Data is deleted” message.
7. Use case ends.

Post condition Data will be deleted from the database.

Alternative course of A1: Warning!

action 1. System displays “Are you sure to delete this data?”
2. User click either “yes” button or “no” button.
3. Use case resume at step 3.
A2: Invalid registration number
1. System displays” please the correct registration number!”
2. Use case resume at step 3.

24
Table 11.The scenario or use case description of the Search airmail use case

UC Name Search airmail

UC Description Allow counter to search or view user data from the database.

Actor Counter

Precondition The Counter should have logged in to the system.

Flow of event 1. The user selects the “Search” button.

UC-10 2. The system requests the user to enter correct registration
number.
3. The system checks and validates the entered registration
number [A1].
4. The system display and view the searched information
5. Use case ends.

Post condition Counter will view the searched information.

Alternative course of A1: invalid data

action A.1 System displays “Invalid data entries please try again”
A.2 User click “ok” button.
A.3 Use case resume at step 2.

25
Table 12.The scenario or use case description of the update airmail use case

UC Name Update airmail

UC Description Allow counter to update or change user data from the database.

Actor Counter

Precondition The Counter should have logged in to the system.

Flow of event 1. The counter selects the “Update” button.

UC-11 2. The system requests the user to enter correct registration
number.
3. The system checks registration number.[A1]
4. The system display and view the searched information.
5. The counter selects the “clear” button.
6. The counter fills update form.
7. The counter click “Add” Button
8. The system displays “update is successfully completed”
message.
9. Use case ends.

Post condition Counter will view the updated information.

Alternative course of A1: invalid data

action A.1 System displays “Invalid data entries please try again”
A.2 User click “ok” button.
A.3 Use case resume at step 3.

26
Table 13.The scenario or use case description of the delete airmail use case

UC Name Delete airmail

UC Description Allow counter to update or change user data from the database.

Actor Counter

Precondition The Counter should have logged in to the system.

Flow of event 1. The counter enter registration number.

UC-12 2. The counter click “Search” button.
3. The system checks and validates the registration number.
4. The system displays the searched information.
5. The counter click “clear” button.
6. The counter enter registration number
7. The counter click “Delete” button.
8. The system displays “Data is deleted” message.
9. Use case ends

Post condition Airmail data will be deleted from the database.

Alternative course of A1: Warning!

action 1. System displays “Are you sure to delete this data?”
2. User click either “yes” button or “no” button.
3. Use case resume at step 3.
A2: Invalid registration number
1. System displays” please the correct registration number!”
2. Use case resume at step 3

27
Table 14.The scenario or use case description of the search materials use case

UC Name Search material

UC Description Allow postman to search or view material

Actor Postman

Precondition The postman should have logged in to the system.

Flow of event 1. The store keeper selects the “Search” button.

UC-13 2. The system requests the user to enter correct registration
number.
3. The system checks and validates the entered registration
number
4. The system display and view the searched information
5. Use case ends.

Post condition Postman will view the updated information.

28
Table 15.The scenario or use case description of the update materials use case

UC Name Update material

UC Description Allow postman to update or change user materials

Actor Postman

Precondition The postman should have logged in to the system.

Flow of event 1. The store keeper selects the “update” button.

UC-14 2. The system requests the user to enter correct registration
number.
3. The system checks registration number [A1]
4. The system display and view the searched information.
5. The counter selects the “clear” button.
6. The counter fills update form
7. The counter click “Add” Button
8. The system displays “update is successfully completed”
message.
9. Use case ends.

Post condition Postman will view the updated information.

Alternative course of A1.invalid data

action A.1 System displays “Invalid data entries please try again”
A.2 User click “ok” button.
A.3 Use case resume at step 2.

29
Table 16.The scenario or use case description of the delete materials use case

UC Name Delete material

UC Description Allow postman to delete materials.

Actor Postman

Precondition The postman should have logged in to the system.

Flow of event 1. The store keeper enters registration number.

UC-15 2. The store keeper click “Search” button.
3. The system checks and validates the registration number.
4. The system displays the searched information.
5. The store keeper click “clear” button.
6. The store keeper enters post box number.
7. The store keeper click “Delete” button.
8. The system displays “Data is deleted” message.
9. Use case ends.

Post condition Postman will have deleted the material

Alternative course of A1: Warning!

action 1. System displays “Are you sure to delete this data?”
2. User click either “yes” button or “no” button.
3. Use case resume at step 3.

A2: Invalid registration number

1. System displays” please the correct registration
number!”
2. Use case resume at step 3

30
Table 17.The scenario or use case description of the search post box use case

UC Name Search post box

UC Description Allow counter to search or view post box data from the
database.

Actor Counter

Precondition The Counter should have logged in to the system.

UC-16 Flow of event 1. The Counter selects the “Search” button.

2. The system requests the user to enter correct post box
number.
3. The system checks and validates the entered registration
number
4. The system display and view the searched information.
5. Use case ends.

Post condition Counter will view the searched information.

Alternative course of A1.invalid data

action A.1 System displays “Invalid registration number entries
please try again”
A.2 User click “ok” button.
A.3 Use case resume at step 2.

31
Table 18.The scenario or use case description of the updated post box use case

UC Name Update post box

UC Description Allow counter to update or change post box data from the
database.

Actor Counter

Precondition The Counter should have logged in to the system.

UC-17 Flow of event 1. The counter selects the “update” button.

2. The system requests the user to enter correct registration
number.
3. The system checks post box number. [A1]
4. The system display and view the searched information.
5. The counter selects the “clear” button.
6. The counter fills update form
7. The counter click “Add” Button
8. The system displays “update is successfully completed”
message.
9. Use case ends.

Post condition Counter will view the updated information.

Alternative course of A1: invalid data

action A.1 System displays “Invalid data entries please try again”
A.2 User click “ok” button.
A.3 Use case resume at step 5 of basic flow of events.

32
Table 19.The scenario or use case description of the delete post box use case

UC Name Delete post box

UC Description Allow counter to delete or remove post box data from the
database.

Actor Counter

Precondition The Counter should have logged in to the system.

UC-18 Flow of event 1. The counter enters post box number.

2. The administrator click “Search” button.
3. The system checks and validates the post box number.
4. The system displays the searched information.
5. The counter click “clear” button.
6. The counter enters post box number.
7. The counter click “Delete” button.
8. The system displays “Data is deleted” message.
9. Use case ends.

Post condition Counter will delete the post box information.

Alternative course of A1: Warning!

action 1. System displays “Are you sure to delete this data?”
2. User click either “yes” button or “no” button.
3. Use case resume at step 3.
A2: Invalid registration number
1. System displays” please the correct post box number!”
2. Use case resume at step 3

33
Table 20.The scenario or use case description of the Check_Track use case

UC Name Check_Track

UC Description Enables all customers check their materials and airmails

through tracking with which where it reach.

Actor Customers

Precondition The users should have an account.

UC-19 Flow of event 1. The user activates the system or an account.

2. The system displays the main window.
3. The user enters the track number and click on check button.
4. The system checks and validates the entered information.
[A1:A2].
5. The system displays access page for the respective user and
shows information.
6. Use case ends.

Post condition The user entered to the system and can check the material
where it reaches through tracking the system.

Alternative course of A1: Information Not Filled Message

action 3.The system displays “Please enter your user name and
password!” message.
4. The system resumes at step 3.
A2: Invalid Entry Message
3. The system displays “Incorrect User Name or Password!”
massage.
4. The system resumes at step 3.

34
Table 21.The scenario or use case description of the Create_account use case

UC Name Create_account

UC Description Enables all customers to create their account and then they can
have full information about their materials and airmails through
tracking with which where it reach. Generally, they will be a
user member of post office of Ethiopia.

Actor Customers

UC-20 Precondition The users shouldn‟t have an account before

Flow of event 1. The user activates the system page.

2. The system displays the main window.
3. Then displays Create_account page
4. The system displays Create_account interface for the
respective user.
5. Then the user fulfills the entire provided space and click
“Signup “button.
6. The system checks and validates the entered information.
[A1:A2].
7. The system displays “you have successfully created your
account”.
8. Use case ends.

Post condition The customers successfully create their account.

Alternative course of A1: Information Not Filled Message

action 5. The system displays “Please fulfill the entire information!”
message.
6. The system resumes at step 5.
A2: Invalid Entry Message
The system displays “Incorrect data entry!” massage.
6. The system resumes at step 5.

35
 3.4.2. Sequence Diagram

Sequence diagram is a system model that is used to depict the interaction between participating

objects in a given use case. The sequence diagrams for automated postal service system is clearly

show the participating objects in the given use case.

Figure 5.Sequence diagram for login to the system

36
Figure 6. Sequence diagram for user registration

37
Figure 7. Sequence diagram for renting post box

38
Figure 8. Sequence diagram for material registration

39
Figure 9. Sequence diagram for sent airmail registration

40
Figure 10. Sequence diagram for received airmail registration

41
Figure 11. Sequence diagram for searching material information from the database

42
Figure 12. Sequence diagram for searching airmail information from the data base

43
Figure 13. Sequence diagram for searching post box information from the data base

44
Figure 14. Sequence diagram for updating post box information to the database

45
Figure 15. Sequence diagram for deleting post box from the database

46
Figure 16. Sequence diagram for create account

47
Figure 17. Sequence diagram for Check_Track

48
3.4.3. Activity Diagram

An activity diagram describes a system in terms of activities. Activities are states that represent the

execution of a set of operations. The completion of these operations triggers a transition to another

activity. Activity diagrams are also similar to flowchart diagrams in that they can be used to

represent control flow (i.e., the order in which operations occur) and data flow (i.e., the objects that

are exchanged among operations).

Figure 18. Activity diagram for administrator

49
Figure 19. Activity diagram for counter

50
Figure 20. Activity diagram for Postman

51
Figure 21. Activity diagram for Customers

52
3.4.4. Class diagram

Class diagram describe the structure of the system in terms of classes and objects .Classes are

abstractions that specify the attributes and behavior of a set of objects whereas objects are entities

that encapsulate state and behavior. In our system account, airmail, material, user, customer, and

postbox are classes. The class diagram for automated Ethiopian postal service system as shown

below.

Figure 22. Class diagram for the system

53
 CHAPTER FOUR
SYSTEM DESIGN
4.1. Introduction
The overview of the system design document is the transformation of analysis model into design
model according to its function and user interfaces. During design model the system defines the goal
and decomposes the system into subsystems.

Generally throughout this system design the system performs the following tasks to make the system

effective and well designed to the clients; the hardware or software platform, on which the system

will run, the persistent data management strategy, the global control flow, the access control policy

and, the handling of boundary conditions.

Finally, as the result of above mentioned details the system operates its task as follows:

 A clear description of each of these strategies.

 Subsystem decomposition.

 UML deployment diagram representing the hardware/software mapping of the

system

4.2. Purpose of the System Design Document

The purpose of this system design document is to describe the architecture and system design of the

project Online Ethiopian Postal Service. This document helps both the system developers and the

customers by providing detail information on the most important activities which are going to be

implemented. It can also be used as a blue print for the developers before they start construction.

54
4.3. Architectural Design of the System

4.3.1. Logical View of the Architecture

This section describes the most important use case realizations, for example, the dynamic aspects of
the architecture. Design level class diagrams have to be included also to illustrate the relationships.
Describe the abstract descriptions of a system's parts. Used to model what a system is made up of
and how the parts interact with each other. The types of UML diagrams that typically make up this
view include class, object, state machine, and interaction diagrams, between architecturally
significant classes, subsystems, packages and layers.

Figure 23. Logical View of the Architecture

55
4.3.2. Process View

It describes the tasks (procedures and threads) involved in the system„s execution, their interactions
and configurations. It also describes the allocation of objects and classes to tasks .Describe the
processes within your system. It is particularly helpful when visualizing what must happen within
your system. This view typically contains activity diagrams.

Figure 24.Process View

56
4.3.3. Deployment View

Deployment modeling is used to show the hardware of the system, the software that is installed in
the hardware and also the middleware that is used to connect the disparate machines to one and
other. It also shows how the software and the hardware components work together in order perform
the task.

Figure 25.Deployment diagram

57
4.4. Database Design

Database Design is the database structure that will be used as plan to Store and manage the data.
Database se design is the process of producing a detailed data model of a database. This logical data
model contains all the needed logical and physical design choices and physical storage parameters
needed to generate a design in a Data Definition Language, which can then be used to create a
database. Much thought, as data and reporting requirements become more complex, those same
people will simply and produce the required data by incorrectly adding more columns of tables to the
database.

Figure 26.Database Design

58
 4.4.1. Database Normalization
Normalization is the process of organizing data into tables in such a way that the results of using
the database are always unambiguous and as intended. Normalization may have the effect of
duplicating data within the database and often results in the creation of additional tables.

Third Normal Form (3NF)

Table 22.Database Normalization

Airmails (3NF)
Register_no Date of Sender Receiver city type Data of
posting name name receiving

Customer (3NF)
Fname Lname Age Sex C_id position Email Phone_no POBox

Material (3NF)
Register_no Type Quality quantity weight Customer_id

Counter (3NF)
Fname Lname Age Sex Id City salary POBox position address

Postbox (3NF)
Fname Lname Register_no City Phone_no Renting Expired House_no
date date

Postman (3HF)
Fname Lname Age Sex Phone_no address salary position id

4.5 User Interface Design

User interface is the representation of the software or business to the user. User interfaces should be

designed to match the skills, experience and expectations of its anticipated users. System users often

judge a system by its interface rather than its functionality. A poorly designed interface can cause a

user to make catastrophic errors.

Our system user interfaces contribute to a system's quality in the following ways:

59
  Increased efficiency: If our system fits the way its users work and if it has a good design,

users can perform their tasks efficiently. They do not lose time struggling with the

functionality and its appearance on the screen.

 Improved productivity: Our system user interface does not distract the user, but rather

allows them to concentrate on the task to be done.

 Reduced Errors: These so-called 'customers errors' can be attributed to poor user interface

quality. Avoiding inconsistencies, ambiguities, and so on, reduces user errors.

 Reduced Training: A well-designed user interface encourages its users to create proper

models and reinforces learning, thus reducing training time.

 Improved Acceptance: Users/Customers prefer systems whose interface is well designed.

Such systems make information easy to find and provide the information in a form which is

easy to use.

User Login Home page interface

A. User Interface: Admin Login page interface

Figure 27 .Admin Login page interface

60
 B. User Interface: Counter Login page interface

Figure 28.Counter Login page interface

C. User Interface: User Login page interface

Figure 29.User Login page interface

61
 CHAPTER FIVE
CONCLUSION AND RECOMMENDATION
1.1. Conclusion
In this project, we have developed an Online Automated Ethiopian Postal Service that facilitates
various event activities of user. We began our work by identifying the significance of automated
system for the store and the overall techniques to be used in the development process. This involved
defining the system development methodology, identifying process, and setting the deliverable and
scheduled for the project.

The business area Analysis helps the team to truly understand the major functional areas and
processes of the system. Through this we evaluate the existing system weakness and strength.

After that, we performed requirements elicitation to discover user and system requirements. This
phase consisted of drawing the functional as well as non-functional requirements of the system.
Then we have undertaken a major phase in system development process: object oriented Analysis.
Here, we tried to model the new system we proposed using UML diagrams: Use case, sequence, and
activity and class diagrams. Also we designed the new system user interface prototype.

1.2. Recommendation

According to scope of our project the team develops an Online Automated Ethiopian Postal Service
System. Because of the time constraint we have some limitations which should be taken in
considerations, but in the future the team believes that this system can be fully operational by having
some functionality that are not included in the proposed system like user view current location and
appointment place by using global positioning system Tracker.

62
References

1. “Object-Oriented Systems Analysis and Design, (2nd Edition)” by Joey F. George, Dinesh Batra,

Joseph S. Valacich, and Jeffrey A. Hoffer.

2. .“Object-oriented Systems Analysis and Design Using UML “by Simon Bennett, Steve McRobb,

and Ray Farmer.

3. “Object-Oriented Systems Analysis and Design with UML “by Robert V. Stumpf and Lavette C.

Teague.

4. “Object-Oriented Analysis and Design with Application” by Grady Booch.

5. “Principles of Object-Oriented Analysis and Design “by James Martin and James J. Odell.

6. “Object-Oriented Software Engineering, 1e” by Stephen R.s

7. Online access, title – Ethiopia Postal Service, URL: http://www.Ethiopostalservice.com

63
Appendix

Definitions, Acronyms and abbreviations

Definitions

SIM card: - it is a prepaid card used in mobile phones.

Western union: - it is Money transfer service from abroad.

Acronyms and Abbreviations

EMS: - Express Mail Service

UML: - Unified Modeling Language

DBMS: - Data Base Management System

DV: - Diversity Visa

SQL: - Structural query language

64