You are on page 1of 81

CHAPTER -1-

INTRODUCTION OF SYSTEM OR APPLICATION


1.1. Introduction
As a professional project developer we are going to develop precise and useful web application for customers
regarding to postal as well as other related services easily from one place to another. The project has two main
important parts, namely phase one documentation part and phase two implementation as well as testing part. Each part
has its own planned time to be fulfill all the necessary things and finally we will collect them in one well formatted as
well as well installed application.
So our project also has a great goal for customers throughout the world. It is mainly focuses on how can
customers send and receive their materials through postal system throughout the world and they can easily check their
materials online in the tracking system
1.2. Background (including both Organization and System or Application)
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.
Ethiopia has at present 1139 post offices. Out of this 746 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 79016 inhabitants while one private box serves 529 people.
1.3. Statement of Problem
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,


 Difficult to update data,

 Wastage of resources,

 Needs more space to store file cabinet,

 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 organizations’ safety.
 Date or time limitation problem in which the system doesn’t keep track of sending and receiving different
materials deliver in the customers’ expected time and date. Example, postponing the expected time or date.
The problems that raised in the above limit the organization not to give reliable and fast service to its customers.
1.4. Objective
1.4.1 General Objective
The general objectives of this project is to develop and implement Online postal service for Ethiopia .That is to
develop and provide a full internet application or web based application, then can be accessed by any customers
throughout the world as well as branch organizations are communicate each other through online network application.
It helps customers to use their time and other resources effectively and efficiently whenever they use postal service.
1.4.2 Specific Objective (step by step tasks to achieve the general objective).
The specific objectives are listed below:-
 To minimize resources
 To minimize the time consumption and work load for both the organization and customers
 To minimize the data storage space
 To encourage data security
 To design central and well-structured database management system
 To eliminate redundancy of data
 To make online with web based application through an internet connection.
 To keep truck mails.
1.5. Proposed System
In this proposed system we have tasks to do and needs to fulfil this project currently, where the technological
innovations and the use of computerized and mobilized systems are highly being increasing from time to time, the
knowledge of mobile and computers and knowing how to operate with them is very much important.
1.6. Literature Review and Related Work
Based on the discussion with quality and security department of the Ethiopian postal service department on time
delivery is basically all about delivery on agreed time which is within 48 hours after acceptance (is about punctuality
instead of speed, percentage of all deliveries on time and deliveries at the desired time windows at acceptable cost) and
completeness and accuracy of orders delivered which is all about quality of delivery and it may include (received
quantity corresponds with delivered quantity, avoiding loosing of goods to maintain delivery obligation, very low rate
of returns due to shipment damage & shipment errors and percentage of accurate deliveries). In addition to this on time
a package is considered on time if tracking information is recorded within 48 hours of entering the shipment
confirmation.
1.7. Scope and Limitation (Limitation should be with detail reason)
a. Scope
The proposed system that we will try to automate is limited and bounded on the Ethiopian postal services. It will
perform how to:-
 Track the sent messages of customers through their user account
 Update information
 Box management
 Mail management
 Search information
 Store data in data base
 Automate and make online service

b .Limitation
The Ethiopian postal service system provides services to its customers using manual system and somewhat automated
to provide service to its customers. Due to this reason the systems have the following drawbacks:-
 It take much time to perform a single task
 The system cannot seek the given data
 It is no cascading sheet style but it simply implemented by frame
 The system does not performing tracking well
 Take time to retrieve data
 It need more space to store files or cabinets
1.8. Methods and Tools
1.8.1 Data Source and Data Collection Methods

When we propose this project, we have used the following data collection method.
To gather the requirement of the system we use different types of fact finding methods those are:-
Interview
To know how the postal service system is work, we prepared questions concerning on postal service and
interviewed the counter and manager of Hosanna town post office. The counter is person who performs managing
the all transactions inside the post office, as well as the manager is a person who controls and manages the overall
system. He also called postmaster. So from the manager we gained the overall description of the system, and from
the counter we gained how the postal service transactions are going on.
Observation
By observing the current working environment of Hosanna post office, we collect data which necessary for
automating of Hosanna 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.

Document analysis: -We also see different documents in order to obtain the information about
the practices and problems of the current manual system. We gathered information in regards to
practices and problems of the existing manual system.
1.8.2 System Analysis and Design Methods
 System Analysis: - requirement engineering like use case model object model etc.
 System Design: - physical data base design like physical data base design, design elements, design system
architectures, design component.
1.8.3 System Implementation Methods and How to use Methods
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, Xamp2.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.8.4 Development Environment and Programming Tools
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.
Programming Tools
The tools that we are going to use throughout our project are listed in the following table as grouped into hardware
tools & software tools

Tools
Hardware Software
 Processor: Intel(R) core(TM).i3-  Microsoft 2010 :to write the entire documents
2120cpu@3.30GHZ  Power point 2010 :for presentation for both
 Flash Disk : at minimum 8GB phase1 and phase 2
 RAM : to the maximum of 1.90GB  Wamp server 2.5 :To run the site on the tool
 Hard Disk: to the maximum of bar
464.6GB  npp.6.5.5.Installer : To edit the entire
 CD-R : to the maximum of 700MB implementation code
 SQL database server: To store data
 Visual paradigm for UML 10.2 : to draw
UML diagrams

1.9. Significance of the Project


The proposed project has many benefits. Those are listed below:-
 Speed up the system
 Perform data updating easily
 Reduce resource wastage
 Protect data/files from unauthorized users
 Reduce work load of the employee of the organization
 Enable the organization to has centralized DBMS

1.10. Beneficiaries of the System or Application


Users of these system includes admin, seller/owner, customer/buyer and users that registered as
members of the post office to make communication between seller and customer and etc.

Owner/Seller
Buyer
Agent
Administrator/manager of the organization.
1.11. Feasibility Study
Feasibility study is a study that determines whether a proposed system is technically, financially, and operationally
viable.Preliminary Investigation is the first phase in any system developing life cycle. The Feasibility Study is a major
part of this phase.
Feasibility Study means selecting the best system that meet the performance requirement.The feasible development of
the software is going to be in terms of the following aspects:
1.11.1Technical Feasibility Study
The system to be developed by using technologically system development techniques such as asp.net, Java script,CSS
and MYSQL database server without any problems and the group members have enough capability to develop the
project. So the system will be technically feasible.
1.11.2Economic Feasibility Study
The purpose of the economic feasibility assessment is to determine the positive economic benefits to the organization
that the proposed system will provide. It includes quantification and identification of all the benefits expected. This
assessment typically involves a cost/ benefits analysis.
1.11.3Operational Feasibility Study
Operational feasibility it measures the degree of how much the proposed system reduce the existing system problems.
The system to be developed will provide accurate, active, secured service and decreases labor of workers and also it is
not limited to particular groups or body. And also it is plat form independent i.e. it run’s in all operating system
1.11.4Legal Feasibility Study
The system to be developed is not conflict with any government directives, because it
gives services for the people effectively and efficiently, all the stakeholders also
agreed before the system developed. So the citizen is profitable and the system will be
politically feasible.
1.12. Project Plan
A project plan defines project goals and objectives, specifies tasks and how goals will
be achieved, identifies what resources will be needed and associated budgets and
timelines for completion. A project plan defines all work in a project and identifies
who will do it.
1.12.1 Time Schedule

no task Duration Nov. Dec Jan Feb Mar Apr


2015 2015 2015 2015 2015 2015
Two Three Four 2 2 2
Weeks weeks weeks weeks weeks weeks

1 Information
gathering
11 day

2 Project
information and
12 days
planning

3 Project Analysis 43 days

4 project design 11 days

5 Project 75 days
Implementation
1.12.2 Budget Plan

no Quantity Total price(birr)

1 Computer and laptop Computer and laptop free

2 Printing 200~300

3 Ms visual studio free

4 Visio free

5 Ms office free

6 paper 100

7 MySQL database server free

8 Xamp server free

9 Notepad++ free

10 Ed-row max free

TOTAL ~400
CHAPTER -2-
DESCRIPTION OF THE EXISTING SYSTEM OR APPLICATION
2.1. Introduction
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
 Income tax Collection
 Duties stamp sales
 Tele agency license tax collection
 Boucher Card sale

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, cost and price) in three copies on the form. Finally
the customer pays the price and receives the receipt. Then 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.

2.2. Business Rules and Constraints


Business rule is an operating principle or policy the system follows. The business
rules are:-
 An airmail to be sent must have full address of sender and receiver
 The retention period of an item is one month for local, two month for
international. After this time it will be returned.
 Every year from July 1 to 30, the customer must pay the annual post office
box rent. If the annual rent is not paid with due date, the box shall be rented
to another. If the customer lost his/her post box key, he/she must pay 20birr.
 Customer can rent only one post box
 To rent post box, western union service, to receive registered and parcel
airmail, to buy SIM card, the customer must have an ID card.
 The postal system doesn’t give sending service to historical heritage, Gold,
coffee, weapons, liquids, drugs….etc. But the customer can send a sample
off coffee and grain if the customer have license from the government. For
example Ethiopia Grain Trade Agency.
Constraints
There are many constraints that we would face to do this project. Those are:-
I. Transportation:
It is very far from wachemo university to Addis Ababa. Due to this reason we will not
go to Addis Ababa for observation instead we make observation on hossaana postal
service office.
II. Financial
Because we are dependent on our family, we in face lack of money to pay for taxi
services and other different material used to do this project well.
III. Laboratory
We could not get enough laboratories and internet access as we need i.e. there is no
fixed laboratory and internet access because of power off and connection interruption
2.3. Naming Convention and Definition
Shipment id: -shipment identification, it is a simple tool to identify shipments and
can uniquely identify shipments where required.
PC: -personal computer
UML: - Uniform Modeling Language
WWW: -World Wide Web which provide services for an internet

2.4. Functions or Main Activities of Existing System


 Ethiopian postal service  provides an express mail service, letter post delivery, and
agent-based financial business services, item tracking and tracing, and philatelic sales
to the public.

The new digitization roadmap is expected to modernize the existing services and even
add new innovative service packages.

According to a study by the universal postal service potential digital services the post
can provide includes online postal shopping portal, online customs declaration,
integration of postal web services with e-merchant sites, online bill payment, online
postal products shop, online lookup, online customer service, electronic postal
invoicing, enhanced item tracking and electronic notification.

Ethiopian Postal Service has recently started  a process to establish its own bank and
a mobile money service.

2.5. Players of Existing System or Application


Users of these system includes admin, seller/owner,
customer/buyer and users that registered as members of the
post office to make communication between seller and
customer and etc.
2.6. Organization Structure

2.7. Documents used in the Existing System or Application


2.8. Strength and Weakness of the Existing System or Application
2.8.1 Strength of the Existing System or Application
The employees provide service to the society by:-
working overtime
Loyal able to the customers.
Punctual to the society.
Honesty to the users
2.8.2 Weakness of the Existing System or Application
The weaknesses of the existing system are:-

F Use more human power: - since the system is not some more
computerized it use more human power to give service.
F There is duplication of data:-because of the data are not well
organized and structured.
F There is disorder of data: - because the data are not stored
sequentially.

2.8.2.1 Alternative Solutions


The alternative solutions are :
 Decrease human power :- since the system is more computerized it not use human
power to give service.
 Unduplication of data :-data are well organized and structured
 Time accuracy
 By reducing system complexity
 Improving security issue
 Improving efficiency
CHAPTER -3-
REQUIREMENT SPECIFICATION AND ANALYSIS
3.1. Introduction
3.2. Description of the Proposed System or Applications
The proposed system that we will try to automate is limited and bounded on the
Ethiopian postal services. It will perform how to:-
 Track the sent messages of customers through their user account
 Update information
 Box management
 Mail management
 Search information
 Store data in data base
 Automate and make online service

3.2.1 User Characteristics


User requirement users can be access the system as they want and can access all
expected requirements also can manage their account easily through the system.
3.2.2 Constraints
There are many constraints that we would face to do this project. Those are:-
 Transportation:
It is very far from hossaana to Addis Ababa. Due to this reason we will not go to
Addis Ababa for observation instead we make observation on hossaana postal service
office.
 Financial
Because we are dependent on our family, we in face lack of money to pay for taxi
services and other different material used to do this project well.
 Laboratory
We could not get enough laboratories and internet access as we need i.e. there is no
fixed laboratory and internet access because of power off and connection interruption

3.2.3 Assumptions and Dependencies


After we have finished our project, the installed database should be duplicated for all
Ethiopian Postal Service branches and throughout the world.
3.3. Requirement Specifications
3.3.1 Functional Requirement
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
 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.2 Non-functional Requirement


Nonfunctional 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.

3.4. System Modeling


The system model of Ethiopian postal service system is composed of the functional
model represented by Use cases, the dynamic model represented by the sequence
diagram and object model represented by class diagram.

3.5.1 Actor Identification


Administrator: is a person who registers user, update and delete information about
the user.
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.

3.5.2 Use-Case Identification


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
 Register user
 Renting post box
 Register material
 Register sent airmail
 Register received airmail
 Search user
 Update user
 Delete user
 Search airmail
 Update airmail
 Delete airmail
 Search material
 Update material
 Delete material
 Search post box
 Update post box
 Delete post box
 Check track
 Create account
 Actors
 Administrator
 Counter
 Postman
 Customers
3.5.3 Use-Case Diagram
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 diagram of our system is shown as follows with respective
description.

Fig.1 use case diagram for system administrator


Fig.2 use case diagram for counter
Fig.3 use case diagram for system Postman
Fig 4 use case diagram for Customers
3.5.4 Description of Use-Case
Table1. The scenario or use case description of the Login use case
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.
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.
UC-01

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 A1: Information Not Filled Message
of 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.
Table2. 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.
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
UC-02

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 A1: Wrong data Entry Message
course of 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.
Table3. 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.
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]
UC-03

4. The system display “Renting is successfully completed”


message.
5. Use case ends.
Post condition The account of the users registered (created).
Alternative course A1: The post box was rented by other user.
of action 1. The system displays “The post box was rented by
another user!” message.
2. The system resumes at step 2.
Table4. The scenario or use case description of the material registration
usecase.
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
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
UC-04

data.[A1:A2]
4. The system displays “material information
recorded” message
5. Use case ends
Post condition Material information is registered.
Alternative A1: Wrong data Entry Message
course of 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.
3. The system resumes at step 2.
Table5. 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.
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
UC-05

recorded” message
5. Use case ends
Post condition Sent airmail information is registered
Alternative A1: invalid data
course of 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
Table6. 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.
2. Counter completes and submits the received airmail
registration form by clicking “Add” button.
3. The system checks and validates the entered data. [A1].
UC-06

4. The system displays “airmail is successfully registered”


message
5. Use case ends.
Post condition Received airmail information is registered
Alternative A1: invalid data
course of 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.
Table7. 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.
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
UC-07

number[A1]
4. The system display and view the searched information
5. Use case ends.
Post condition Administrator will view the searched information.
Alternative A1: invalid registration number
course of 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.
Table8. 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.
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.
UC-08

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 A1: invalid data
course of 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.
Table9. 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.
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.
UC-09

6. The system displays “Data is deleted” message.


7. Use case ends.
Post condition Data will be deleted from the database.
Alternative A1: Warning!
course of 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.
Table10. 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.
2. The system requests the user to enter correct
registration number.
3. The system checks and validates the entered
UC-10

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 A1: invalid data
course of 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.
Table11. 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.
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.
UC-11

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 A1: invalid data
course of 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.
Table12. 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.
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
UC-12

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 A1: Warning!
course of 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
Table13. 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.
2. The system requests the user to enter correct
UC-13

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.
Table14. 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.
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.
UC-14

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 invalid data
course of 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.
Table15. 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.
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.
UC-15

8. The system displays “Data is deleted” message.


9. Use case ends.
Post condition Postman will have deleted the material.
Alternative A1: Warning!
course of 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
Table16. 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.
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
UC-16

registration number
4. The system display and view the searched
information.
5. Use case ends.
Post condition Counter will view the searched information.
Alternative invalid data
course of 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.
Table17. 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.
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.
UC-17

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 A1: invalid data
course of 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.
Table18. 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.
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.
UC-18

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 A1: Warning!
course of 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
Table19. 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.
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].
UC-19

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 A1: Information Not Filled Message
of 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.
Table20. 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
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.
UC-19

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 A1: Information Not Filled Message
of 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.
3.5. Requirement Analysis
3.5.1. 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).

Administrato
r

Administrative login/system login

Check Admin UN and


PW

Invalid Valid

Select
Action

update user

Manage
Manage system
Register
users
user Control
Delete airmails
user
Search user

Fig.19 Activity diagram for administrator


Counte
r

Login/system login

Check UN and PW

Invalid Valid

Select
Action

update airmails
Manage post box
Rent post box
Register Airmails
Control
Delete airmails airmails
Search airmails

Fig.20 Activity diagram for counter


Postman

Login/system
login

Check UN and
PW

Invalid Valid

Select
Action
 

Update
Register material
materials Delete
materials
Search
material

Fig.21 Activity diagram for Postman


Customer
s

Login/system
login

Check UN and
PW

Invalid Valid

Select
Action

Create
Check account
track

Fig.22 Activity diagram for Customers


3.5.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.

Fig.5 sequence diagram for login to the system


Fig.6 sequence diagram for user registration
Fig.7 sequence diagram for renting post box
Fig.8 sequence diagram for material registration
Fig.9 Sequence diagram for sent airmail registration
Fig.10 Sequence diagram for received airmail registration
Fig.11 Sequence diagram for searching material information from the database
Fig.12 Sequence diagram for searching airmail information from the data base
Fig.13 Sequence diagram for searching post box information from the data base
Fig.14 Sequence diagram for updating post box information to the database
Fig.15 Sequence diagram for deleting post box from the database
Fig.16 Sequence diagram for create account
Fig.17 Sequence diagram for Check_Track
CHAPTER -4-
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 hardwareorsoftware
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. 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
admin module, counter module or airmail page, postman module or material page,
customer page, and tracking page are classes. The class diagram for automated
Ethiopian postal service system as shown below.
Fig. 3 Class diagram of the system
4.3. Database Model
4.5.1 Entity Relationship Diagram (ERD)
4.5.2 Persistence Modeling
4.5.3 Mapping with Normalization
4.4. Subsystem Decomposition
During the subsystem decomposition of Online Ethiopian Postal Service, we have just
divided the general system into smaller subsystem with strong coherence. So
following are subsystems of our system.
A. Admin Module subsystem
In the admin page interface any administrative activities are performing,i.e. this
subsystem is responsible for the following functionalities by the system
administrator.
 Create login: -the system administrator can have a full privilege to create login

 Set and Modify password: -He/she can have an authority to change and control
the modification.
 Login: administrator can only login to his/her adminpage.

 User registration: - the administrator registers and adds any users through user
registration form into the database table.
 Post notice: - an administrator can post any notice on post page

 View comments: - the system admin can also see what customers may suggest
any kind of comments.
 User modification operations (update user, delete user, search user): -
administrator can have to modify users.
B. Material subsystem
This subsystem is responsible for the following functionalities which can be
performed by the Postman.
 Send materials:- materials can send to the expected destination
 Receive materials: - the Postman should receive materials to the Counter of
the system.
C. Counter modulesubsystem
This subsystem is responsible for the following functionalities which can be
performed by theCounter.
 Register materials: the postman is responsible to insert materials in to the
database table
 Search materials:searching materials from the database
 Update materials:updating materials in the database
 Delete materials:deletematerials from the database
 Search materials: -searching materials from the database
 Register airmails:the counter is responsible to insert airmails in to the
database table
 Search airmails: searching airmails from the database
 Update airmails:-the counter can modify airmails
 Delete airmails: - he/she can delete materials that are may be unnecessary or
out of date from the database.
 View airmails: -view airmails data entry from the database
D. Box management subsystem
This subsystem is the subsystem of counter subsystemin such a way that it
responsible for the following activities that performed by the counter.
 Manage box: providing the management of box to rent service for the users.
 Renting box: renting the boxes for customers.
E. Tracking & Tracing module subsystem
This subsystem is responsible for the following functionalities which can be
performed by the Customers.
 Track: - customers can check track of their sent materials and any postal
related things by clicking this button with their own shipment id.
F. Customers Module subsystem
This subsystem is responsible for the following functionalities which can be
performed also by the Customers.
 Create account: - customers can create their own account in create account
page
 Rent box:The customers can rent the services from the system.
 Login:- the customers can login to their existing account with expected
username and password
 Comment:-the customers writes comment about the system and its services
4.5. Deployment Diagram

Application
Server
MYSQL
Database
Web
Server

Service
provider

Client: PC

We Browser
b s

4.6. System Architecture (Layered Architecture of the System)


4.7. User-Interface (UI) Design

User Interface Design Issues

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:

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:Theseso-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
4.8. User-Interface (UI) Design
a. User Interface: Home page interface
b. User Interface: Admin Login page interface
.

c. User Interface: Admin page interface


d. User Interface: User registration page interface
e. User Interface: Tracking page Interface
f. User Interface: Contact us Interface
g. User Interface: Feedback Interface

4.9. UI Flow Diagramming ss

CHAPTER-5-:
IMPLEMENTATION AND TESTING
5.1. Introduction
5.2. Algorithm Design
5.3. Sample Code
5.4. Testing
5.4.1 Unit Testing
5.4.2 Integration Testing
5.4.3 System Testing
5.5. User-Manual
5.6. User Training
5.7. Start-Up
References:

You might also like