Table of Contents

System Design Document............................................................................................................................2

1. Introduction.........................................................................................................................................2
1.1 Overview.........................................................................................................................................2
1.2 Purpose........................................................................................................................................2
1.3 Design Goal/Objective.................................................................................................................3
1.4 Scope of the development project................................................................................................3
1.5 Definitions, acronyms, and abbreviations....................................................................................4
2. System Design Model..........................................................................................................................4
2.1 Sub System Decomposition.........................................................................................................4
2.2 Diagrammatic Representation of our subsystems........................................................................7
2.3 High-Level Deployment Diagrams to show Hardware or Software Mapping..............................7
2.4 Deployment Diagram for the system...........................................................................................9
3. Detailed Design.................................................................................................................................10
3.1 Component template description...............................................................................................10
3.2 Class/Package Diagram.............................................................................................................11
3.3 Collaboration Diagram..............................................................................................................13
3.4 Activity/State Diagrams.............................................................................................................16
4. Access Control & Security..................................................................................................................21
5. User Interface Design Issues.............................................................................................................22
6. References.........................................................................................................................................31

1
System Design Document

1. Introduction

1.1 Overview
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.

1.2 Purpose
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.

2
 1.3 Design Goal/Objective
Design goals identify the qualities that our system should focus on. And provide a consistent
set of criteria that must be considered when making design decisions. The design goals are
derived from the non-functional requirements. So based on those non-functional requirements
the following design goals will have to achieve in order to qualify the system as successful.
 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 user friendly 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

N.B: The goal of system design is to manage our system complexity by dividing the system into
smaller, manageable pieces in general.

1.4 Scope of the development 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 the sent messages of customers through their user account

 Update information

3
  Box management
 Mail management
 Search information
 Store data in data base
 Automate and make online service

1.5 Definitions, acronyms, and abbreviations

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. System Design Model

2.1 Sub System 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

4
  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 module subsystem
This subsystem is responsible for the following functionalities which can be performed by the
Counter.
 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: delete materials 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 subsystem in 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.

5
  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

6
 2.2 Diagrammatic Representation of our subsystems

Fig. 1 subsystem diagram

2.3 High-Level Deployment Diagrams to show

Hardware or Software Mapping
We are developing the Ethiopian Postal service that will be a web based for any customers
i.e. which can be run anywhere through a browser. And the system will also run over any
operating systems. The web server will run over wampserver and the programming languages
used for developing this system are;

7
  Html(Hypertext Markup Language)
 Css(Cascading Sheet Style)
 Js(Java Script)
 Php(Hypertext Preprocessor)
 MS-Office 2010
 Edraw Max (Trial version ) 7.9
 Star UML 5.0 and also star UML 2.01
We have also selected MySQL database as the database management system.

8
 2.4 Deployment Diagram for the system

Application Server

MYSQL Database
Web Server

Service provider

Client: PC

Web Browsers

Fig. 2 Deployment diagram

9
 3. Detailed Design
3.1 Component template description

Component Description/Purpose
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 object are entities that encapsulate state and behavior of
a set of objects.
 Objects are instances of classes that are created, modified, and destroyed
during the execution of the system.
 Objects have state that includes the values of its attributes and its
relationships with other objects.
 The main activities of system Admin is controlling over all activities in
the page like: manage counters, administer track and material page.
 The Post man directly relate with Counter to post materials.
 The Customer tracks the materials accordingly with their shipment id.
 The Counter have an authority to service users and advices them how to
use the applications of the system.
Collaboration  UML Collaboration diagrams (interaction diagrams) illustrate the
Diagram relationship and interaction between software objects.
 The collaboration diagram illustrates messages being sent between
classes and objects (instances). A diagram is created for each system
operation that relates to the current development cycle (iteration).
 So based on the above concepts, we have just try to illustrate the
relationship and interaction between our system objects and link each
object according to their interaction without the time expectation.

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

10
 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).
 The Admin of the system have a full authority of register user, update
user, delete user, search user, view and post notice.
 The Counter have right of doing the following tasks register airmails,
update airmails, delete airmails, search airmails, view airmails.
 The Postman have a responsibility of performing the bellow operations
register materials, send, receive, update materials, search materials,
delete materials.
 The Customers of the system can do the following tasks according to
their rights, they can create an account if they have no account and after
the can track their materials where it reaches through their shipment id as
International items and Domestic Items. Also if the already have an
account the can easily track their materials where it reaches through their
shipment id International items and Domestic Items.

3.2 Class/Package 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.

11
Fig. 3 Class diagram of the system

12
 3.3 Collaboration Diagram

Fig. 4 collaboration diagram for Administrator

13
Fig. 5 collaboration diagram for Counter

14
Fig. 6 collaboration diagram for Postman

15
Fig. 7 collaboration diagram for Customer

3.4 Activity/State Diagrams

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

16
Fig. 8 activity diagram for Admin module

17
Fig .9 activity diagram for counter module

18
Fig. 10 activity diagram for postman /material page

19
Fig. 11 activity diagram for customer page

20
 4. Access Control & Security
The main actors of the system are customers, postman, counter, and Admin.
Accordingly, the following access control list is given for the system. Each column`s name
specifies the class and the rows specify users whose access is to be controlled. If there are
operations (of the class specified in the corresponding column) in a given cell (column and row
intersection) then the user in that row is said to be given an access to these operations. If there is
no entry in a given cell then it can be considered as that user has no way of contacting or using
the class through the operation corresponding to the column of the cell.

Table 1 access control

Classes
Actors
User Box Post Comment Material Airmail Account Password
notice
Administrator Register() Post() View() Create() Set()
Search() Change()
Update()
Delete()
View()

Postman

receive()
Send()
Counter Manage() Register()
Rent() Search()
Update()
Delete()
View()
Send()
Receive()
Customers Renting() Comment() Track () Track() Create()
Login()
Logout()

21
 5. 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: 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

a. User Interface: Home page interface

22
23
b. User Interface: Admin Login page interface

24
c. User Interface: Admin page interface

25
d. User Interface: User registration page interface

26
e. User Interface: Tracking page Interface

27
f. User Interface: Contact us Interface

28
g. User Interface: Feedback Interface

29
30
6. 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. http://www.Ethiopostalservice.com

31