Object Oriented System Analysis Design Project Group1Project

College of computing and informatics
Department of software engineering
Online Trade interaction system
Group member
Name ID
1. Alif Tesfaye CIR/055/07

2. Maregn Baykeda CIR/309/07
3. Leta Tesfaye CIR/298/07
4. Kaleab Yalewdag CIR/274/07
5. Hermela Manchalom CIR/252/07
6. Biniam Samuel CIR/116/07
Submitted to Mr. Ermiyas B
Submission date December 24, 2016

Contents
Chapter one
Project proposal
1.1. Introduction ......................................................................................................................................... 6

1.2. Problem of statement .......................................................................................................................... 7
1.3. Objective ........................................................................................................................................... 7
1.3.1 General objective ......................................................................................................... 7
. 1.3.2 Specific objective ......................................................................................................... 7
1.4. Scope ................................................................................................................................................. 8
1.5. Significance of the Project................................................................................................................. 8
1.6. Feasibility Study ................................................................................................................................ 9
. 1.6.1. Operational Feasibility ................................................................................................ 9
1.6.2. Technical Feasibility ................................................................................................... 9
1.6.3. Economic Feasibility .................................................................................................. 9
1.7. Methodology ................................................................................................................................... 10
1.7.1. System Development Tools ..................................................................................... 11
1.7.2. Object oriented Requirement Model and Analysis .................................................. 12
1.8. Limitation ........................................................................................................................................ 12
1.9. Team members activity and responsibility ...................................................................................... 13
1.10. Plan ............................................................................................................................................... 13
1.10.1. Resource plan .......................................................................................................... 13
1.10.2. Budget plan ............................................................................................................. 14
1.10.3. Work .......15
Chapter two
Study of The Existing System
2.1 Introduction16
2.2. Current System ..16
2.3. User of The Current System 16
2|Page
Chapter Three
Software Requirement Specification
3.1. Introduction........17
3.2. Functional Requirements ......17
3.3. Non-Functional Requirements.18
3.4. System Models.19
3.4.1. Use case Models.19
3.4.2. Scenario.......28
3.4.3. Object Model..33
3.4.4. Dynamic Models35
3.4.5. User Interface41
Chapter Four
System Design Document
4.1. Introduction.42
4.2. Design Goal..42
4.3. Proposed Architecture ..........43
4.3.1. Overview..43
4.3.2. Subsystem Decomposition44
4.3.3. Hardware/Software Mapping.45
4.3.4. Persistent Data Management.46
4.3.5. Access Control and security....46
4.3.6. User Interface Design...46
Chapter Five
Object Design Document
5.1. Introduction ...........48
5.2. Object Design Traded-offs...........48
5.2.1. Development Cost Verses Functionality..48
5.2.2. Understandability verses Functionality.48
5.2.3. Security Verses Availability..48
3|Page
5.4. Interface Documentation Guideline48
4|Page
Acknowledgment
We want to thank and acknowledge individual person, groups and industries that helped us to
peak the top of our project.
Our first gratitude goes to our OOSAD instructor Mr. Ermiyas because of his contribution to
learn us how system is documented and analyzed. He also played a great role by contributing in
the correction of our sample system documentation.
Furthermore, we want to thank our group and classroom advisor Mr. Sime to his help and
support to show the best way how the project has to be done, by giving moral initiation by
allowing open counselling at any time we want and also by correcting our error on the journey of
our project.
All industry related information are gathered from Semira Food Complex Ltd. So we want to
give thanks for the manager and and all employees that cooperated us to obtain information.
The last but not least of my gratitude goes to our interviewee shopkeepers Mr.Muder and
Mr.Fuad to their willingness to be our interviewee. They played a great role at the requirement
gathering stage.
5|Page
Chapter One
Project Proposal
1. Project proposal
1.1. Introduction
Introduction The Trade Industry is the most important and influential business in the world. In the
trade process different actors are involved in different ways, these actors are factory owner,
store, distributors and users. Different product is produced in the factory that satisfy the users
interest. User wants different product mostly from the distributor. Our system simplifies this way
of trade practicing now in our daily life.
Traditional working ways and conditions usually are not better and they dont have clear labor
division and income audit. With that working condition the profit of the owner decreases, the
quality of products of the factory will be disturbed because of expiration and back warded
transportation system. Not only this the products in the store could not be delivered on time to
the distributors.
A lots of Intermediaries will be paid a lot. This have negative effect on the profit of the factory.
This leads to make the price of the goods expensive. Then when it come to the distributor the
users are not able to buy it with fair price. This again leads the users to go to other competitive
good.
This Online Trade Interaction System simplifies it all by creating good trade interaction. This
system starts at the factory goes through the stores, intermediaries, distributors and ends at the
users. When we start from the factory level it will produce depends on the well calculated
demand. This saves the factory from producing extra goods that cant be sold at the planned
time. This leads to efficient utilization of raw materials. The factory knows the demand that is
going to be delivered to the Acceptors. And the factory receives limited amount of goods from
the factory. This makes the goods at store up to date. Stores can be registered to be customers for
the factory. They can order how much they want online. It can also register distributors and
receive their orders how much they want.
Background
As expressed under introduction part most of Ethiopian trade chains are based on the traditional
system. The factory first produce goods and stores them at the store. It produces continuously
regardless of how much good is capable to be stored. The factory usually has its own store or it
6|Page
may rent stores from store holders (owners). The factory has direct relationship with the
intermediaries or cajolers. These intermediaries seek customers or Acceptors that can be whether
preexisting or new coming by promoting or advertising about the goods and better sides of the
selected good, and then by contacting them to the factory if they dont have their own store. The
factory pays for the intermediary for his/her contribution for the trade chain. The distributor
often has shop that the users directly come to buy those goods. These users will be the end for
this trade line.
1.2. Problem of Statement

Till now the traditional system is being implemented even though its known that it is back
warded because of lack of efficient system that is easy to implement. Its cons are
polydimensional and can be expressed by different point of view.
Economically:
Unnecessary expense for payment to the cajoler (the intermediary) because of indirect
market
Since the market is not stable, all of produced goods will not be consumed at a time
which leads to lesser quality and may be the good could be get out of the market.
Time:
The overall time that the intermediary takes to seek the distributors is not small.
The time to finish transaction is delayed.
Quality and labor:

Since the market is not stable, all of produced goods will not be consumed at a time
which leads to lesser quality and may be the good could be get out of the market.
Requires more labor to manage data.
1.3. Objective
1.3.1. General Objective

Its general objective is about showing the way of simple and more efficient way of trade chain
by developing Online Trade Interaction System.
1.3.2. Specific Objective

The specific objectives are these that are listed below:
Analyze the current system they are using and developing a new database system.
To speed up the management of the industry, distribution place and shopping mall.
To manage the resources (human power) in the industry, distribution place and
shopping mall.
7|Page
To Increase the interrelationship between industry, distribution place and shopping
mall
1.4. Scope
From the factory point of view: the factory first identifies how much producing goods can be
stored properly depending on the available storing capacity. It then stores the goods (products) at
the available space.
From the Retailor point of view: the acceptor is part of the trade chain that firstly buy from the
factory at highest quantity to sell to the distributors. These acceptors register at the system to
order required amount from the factory.
From the Distributor point of view: the distributor registers at the system interface where the
distributors can register to order the required amount from the acceptors without going to the
acceptors. But they have direct relationship with the end users.
From the End user point of view: the end user not directly interact with our system. This means
that the user is not the direct beneficiary of the system. Because of the cost for the intermediaries
is eliminated and have good and simplified trade chain the user can buy the good at lower price.
So the user can be beneficiary indirectly.
Here are the things those are out of our project boundary
Our system does not allow the End user to buy the goods from the retailor by
using their devices
In our system the retailor does not allow to distribute their goods to their
customers.
The system does not include the tax of the goods that the industry , the distributer
and the retailor pay for the government.
1.5. Significance of the project

The main significance of the system is that it is coastwise, time saving, quality confidential and
easy. It is coastwise because the payment for the intermediaries (cajolers) is eliminated. The
transportation to order and to make a deal with the factory is eliminated. It is time saving because
the time to wait until the intermediary seek the customer (acceptor) is eliminated. The time
wasted by the acceptor to contact to the factory and the time wasted by the distributor to the
acceptor is eliminated. The system is quality confidential because the factory produces according
to the storing capacity. The produced goods sold to the market at the time. And they are
consumed before expiry because the system makes the market stable. The system is modernized
and shows the easy way that is parallel with the present technology.
8|Page
1.6. Feasibility Study of the System
The feasibility study is the preliminary study that determines whether a proposed system project
is financially, technically and operationally. Feasibility study is essential to evaluate the cost and
benefits of the new system. The alternative analysis usually include as part of the feasibility study,
identifies viable alternatives for the system design and development.
1.6.1. Operational Feasibility

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. The system will easily operational,
as it doesnt affect the existing organizational structure and support the current system. So the
system will be operationally feasible.
1.6.2. Technical Feasibility

The system to be developed by using technologically system development techniques such as PHP,
Java script, CSS and MySQL database without any problems and the group members have enough
capability to develop the project. Our focus is to develop well organized dynamic web site that is
technically efficient and effective for managing the Online Trade interaction system. Therefore, it
can be concluding that the system is technically feasible.
1.6.3. Economic Feasibility

The system to be developed is economically feasible and the benefit is outweighing the cost. Since
this project already computerizes the existing system and more advanced than the current system
reduces and change the labor force to computerizes system. Reduces the cost of the material used.
1.7. Methdology
Using Waterfall model
The waterfall model is a sequential design process, used in software development processes, in
which progress is seen as flowing steadily downwards (like a waterfall) through the phases of
Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and
Maintenance.
The Merit of Waterfall model in our project:
Reason for choosing Waterfall Model
9|Page
This model is simple and easy to understand and use.
This is Small Project and Requirements Are Well understood.
In this model, output is generated after each stage (as seen before), therefore it has high
visibility. The client and project manager gets a feel that there is considerable progress.
Here it is important to note that in any project psychological factors also play an
important role.
This Project Is Conversion from Manual to Automatic
In this model phases are processed and completed one at a time. Phases do not overlap.
Fig 1. Waterfall Model
1.7.1. System Development Tool
Activities Tools
Documentation MS word 2016
Design Star UML and Visio 2016
Editing Paint, Adobe.Photoshop.CS6, snapshot,
Notepad++ and PhpStrom
Script languages and languages PHP, JavaScript, CSS, HTML
10 | P a g e
Web server Xamp server
Table 1.1. system development tools
1.7.2. Object Oriented Requirement Model and Analysis
The Method and techniques used to analyze the existing system and designing electronic system
includes, interview, questionnaires and Brainstorming. Those methods which help us to gather the
required data to analyze our project and those methods selected due to the time and the
organizations willingness.
Interviewing:
It is the primary technique used to elicit the necessary information from the manager of Muder
Acceptor company who takes the responsibility to manage Muder. The manager of Muder gives
us valuable information about the company and Fowad shopping manager. Delivery some question
about their company Directly continue for the question and answer.
Interview one
Question1: Thanks, the willingness of about this interview?
Manager: no matter I am happy
Question2: When did you start to distribute the product?
Manager: Four year Ago
Question3: Say something about your company?
Manager: our company is mostly used labor force and traditional use of working system and
profitable at minimum level. Try to improvement the current system I think to solve the
problem of our company.
11 | P a g e
Question4: Thank you help this interview
Manager: I am happy to discuss to you
Interview Two
Question1: Thanks, the willingness of about this interview?
Fowad: no matter I am happy
Question2: When did you start to distribute the product?
Fowad: Two year ago
Question3: Say something about their company?
Fowad: our shopping is mostly used labor force and traditional use of working system and
profitable at minimum level. Try to improvement the current system I think to solve the
problem of our shopping and develop the profit of our shopping process.
Question4: Thank you help this interview?
Fowad: I am happy to discuss to you I think to solve our problem of the current system.
Brainstorming
At brainstorm level our group discussed about how to implement the system. These are our main
questions that we talked about.
What kind of tools have to be used to develop the system?
who is our main concern (the factory, the acceptor, the distributor or the end user)?
which to take as a factory?
12 | P a g e
1.8. Limitation of The Project
Because of the proposed system is computer base, it cant be accessed without computer
devices.
This system will be comfortably used by only computer literate people
May be affected by performance of external and internal factors such as finance,
experience etc.
The system depends on electrical power and electronic device.
1.9. Team members and Their Activities

Table 1.2 team member activity
No Full Name ID NO. Email Address Responsibilities
Aliftesfaye7@gmail.com - group Coordinator
1. Alif Tesfaye CIR/055/07 - Data gathering
- Implementation
2. Maregn Baykeda maregnbaykeda@gmail.c -Implementation
CIR/309/07 om -Testing
3. Leta Tesfaye CIR/298/07 Lati.lataaf@gmail.com -Data gathering
4. Kaleab Yalewdag CIR/274/07 Kaleabyalewdeg46@gm -Documentation

ail.com -Testing
-Implementation
5. Biniam Samuel CIR/116/07 biniamsamuel12@gmail. - Data gathering
com -Designer
6 Hermela Manchalom CIR/252/07 hermela21@gmail.com -Data gathering and
casher
1.10. Plan
1.10.1. Resource
Reference tool
- Reference different type of website and book use.
13 | P a g e
Hardware tool as Resource
Resources Amount
A4 paper 1/2 packet
Pen 2pcs
Printing Twice
Flash disk 1
Table 1.3. hardware tools we used
1.10.2. Budget
Hardware tool as Resource cost
Resources Amount Price (ETB)

A4 Paper 1/2 packet 60 birr
Pen 4pcs 16 birr
Printing Twice 160 birr
Flash disk 1 110 birr
Total 346 birr
Table 1.3. hardware tools we used
System Tool Cost

Activities Tools Price
Documentation MS word 2016 Free Download
Design Star UML and Visio 2016 Free Download
Editing Paint, Adobe.Photoshop.CS6, Free Download
snapshot, Notepad++ and PhpStrom
Script languages and languages PHP, JavaScript, CSS, HTML Free Download
Web server Xamp server Free Download
Table 1.4. system tools
14 | P a g e
1.10.3.Work Plan
Project scheduling
Table 1.5. scheduling
Time year 2009 E.C
Nov 02-
Nov 22
Dec 15
Dec 22
Dec 1-
Activities
Project proposal and
Requirement Analysis
System Design
Implementation and
Presentation
15 | P a g e
Chapter two
Study of The Existing System
2. Study of The Existing System
2.1. Introduction
In the current system the industry cannot connect to the retailor or there is no any means that the
industry can chat with the retailor.
2.2. Current system

Major function of the current/existing system is manually and computerized using MS Excel
to record data.
Major function of the existing system is sell the goods to the customer by manual means of store
different goods. and the industry cannot connect to the retailor.
The function of existing system would be designed to help make the rigorous activities carried
out in the industry, in the distributer store, in the retailor store much easier by providing the
statistics of goods in stock, monitoring goods movement in the industry, in the distributer store,
in the retailor store and ensuring effective policing of the activities in the industry, in the
distributer store, in the retailor store.
The new system will be designed to provide the following benefits in the interest of
the industry, in the distributer store, in the retailor store.
The system would enhance management services and improve productivity.
The system would enhance User/System interface.
The system would be cost effective.
The system would improve information quality and accessibility.
2.3. User of the Current System

Manager of the industry
Owner of the distributer
Retailor of the shop/supermarket
The driver of the industry car
Casher of the distributer
Casher of the shop/supermarket
16 | P a g e
Chapter three
Software requirement specification
3. Study of The Existing System
3.1. Introduction
The online trade interaction System is a new application that enables industry, distributer, retailor
to more efficiently and quickly supply goods between them self and to the customer through
automation.
Industry manager, retailor, shop/supermarket casher, delegator and delegation place casher are
provided with interfaces to the Online Trade interaction
3.2. Functional requirment

The official definition for a functional requirement specifies what the system should do:
"A requirement specifies a function that a system or component must be able to perform."
Functional requirements specify specific behavior or functions, for example:

"Control the goods that are manufactured, how many goods produced per day, for whom those
goods that are produced distributed, how many cars need to distribute the goods is connected to
industry manager."
The Online trade interaction System will provide the following major functions:
Actors Functions
Industry produce Goods
delegate Goods
distribute Goods
delegator Log In
Log out
Enter Good Information
Retailor Add Goods and Fill Goods Information
Delete Goods
Search and Display Stock Details
Log In
Log Out
Retailor Casher Register Sales Goods
Login
Logout
Goods Add on to database
Delete from database
Search and display its information
Taken or uses
Customer Accept Order
Reject Order
17 | P a g e
Distributer Casher Register Sales Goods
Login
Logout
Table 2: Functional Requirements
3.3. Nonfunctional requirements

The official definition for a non-functional requirement specifies how the system should behave:
"A non-functional requirement is a statement of how a system must behave, it is a constraint upon
the systems behavior."
Non-functional requirements specify all the remaining requirements not covered by the functional
requirements. They specify criteria that judge the operation of a system, rather than specific
behaviors.
Hardware Interfaces
Hardware interfaces between all systems regardless of any pre-existing network that supports
TCP/IP, since Online Trade Interaction is not web based rather it is Desktop based application.
Software Interfaces
The software interfaces between all systems will be implemented on all operating systems at which
it is compatible with software frameworks:
Other Nonfunctional Requirements
I. Performance Requirements
The system should respond within a short period of time. It depends on the performance of the
hardware environment such as RAM and processor.
II. Security Requirements
Privacy and security requirements: are concerned with keeping the information private and
confidential. The Online Trade Interaction needs to provide for all the communication sessions
conducted between two parties or more the complete and ultimate privacy, away from the
interference of outsiders. The data and information exchanged between any two peers or more in
the Online Trade Interaction are considered highly private, and some of the information is
inaccessible, even for the Retailor, to look at them. Moreover, the system should only permit the
parties or peers that their usernames and passwords match the ones saved in the database from
logging into the system. Unauthorized peers cannot log in or access the system, as this step is
called the authentication.
III. Software Quality Attributes
18 | P a g e
IV. The system shall be intuitively usable by pharmacy professionals.
Input fields shall be clearly labeled with terms meaningful to a retailor,
distributer, industry Manager.
Buttons shall be clearly labeled with terms meaningful to the retailor,
distributer, industry Manager.
V. Business Rules (Security Issues)
Any of system users shall never log in to another system user. This secured
for each system interface from accessing authorized users through
authorized the database table only for those user who have a special
privilege.
3.4. System Models
3.4.1. Use Case Models

A use-case model is UML (Unified Modelling Language) which is a de facto standard for object-
oriented modelling, so use-cases and
Use-casebased elicitation is increasingly used for requirements elicitation. Model of how
different types of users interact with the system to solve a problem. As such, it describes the goals
of the users, the interactions between the users and the system, and the required behavior of the
system in satisfying these goals.
A use-case model consists of a number of model elements. The most important model
elements are: use cases, actors and the relationships between them.
Actor identification
An Actor is something that accomplishes use cases upon a system. It is just an entity, meaning it
can be a Human or other system that directly play an external role in the system.
Different Actors in the Online Trade Interaction are:
Administrator:
He/she checks the whole details for stock maintaining, purchasing details by each sub
administrator, Goods sales details and checking reports for each and every sub detail in the system.
Details to update products into database and maintain transactions of customers. He/she also
control the sub administrator.
Industry administrator
He/she checks the whole details for stock maintaining, purchasing details, Goods sales details and
checking reports for each and every module in the Industry. Details to update products into
database and maintain Transactions of customers in the industry.
Distribution place administrator

checking reports for each and every module in the Distribution Place. Details to update products
into database and maintain Transactions of customers in the Distribution Place.
Shopping Mall Administrator
19 | P a g e
checking reports for each and every module in the Shopping Mall. Details to update products into
database and maintain Transactions of customers in the Shopping Mall.
Industry Casher
He/ She is a person, who is done to sell the goods in the industry store to the Distributer.
Distribution Place Casher

He/ She is a person, who is done to sell the goods in the distribution store to the Shopping Mall.
Shopping Mall casher

He/ She is a person, who is done to sell the goods in the Shopping Mall to the customer.
customer
He/ She is a person, who uses the goods taken from the shopping Mall.
Use case identification

Use case identifies the individual interaction within the system, so in our case, project we identified
the following use cases: -
1. Login
2. Add
3. Purchase
4. Delete
5. Search
6. Register
7. Update
8. Logout
9. Order (prescription)
10. Control
11. chat
Use case diagram
Use case diagrams model behavior within a system and helps the developers understand of what
the user requires. The stick man represents whats called an actor.
An actor represents an outside entity- either human or technological. In this example its
human (Stick man). Notice the curved rectangle on the diagram this represents the system
boundary everything inside that is part of that system, and everything outside are actors (basically
not part of system).
Use case diagrams can be useful for getting an overall view of the system and clarifying
who can do and more importantly what they cant do.
Use case Diagram consists of use cases and actors and shows the interaction between the
use case and actors.
20 | P a g e
System
Login
control Industry Administrator

Administrator
Add
Chat
search Shopping Mole administrator

Industry Casher
Update
Register
Shopping Mole Casher

Distribution place administrator
Delete
Comment
Order Customer
Distribution Place casher
Logout
Fig 2: Use case diagram
Description 1
Use case name Login
Use case number 1
Use case description Allows to enter, update, delete, search, display and
registering goods and entering goods information.
Participator actor Industry Administrator, distribution place
administrator ,Shopping mall administrator, Administrator,
Industry casher, distribution place casher, Shopping mall
casher.
Pre-conditions The users must open the online trade interaction system.
Flow of events The Industry administrator are adding, deleting, updating
the goods that it produced
distribution place administrator and Shopping mall
administrator can also add, delete and update and search
goods and goods information in their database table
Administrator control what the industry administrator,
distribution place administrator and shopping mall
administrator add, delete and update.
Industry casher, distribution place casher and Shopping
mall casher register the sales goods to the system
21 | P a g e
Post-conditions The Industry administrator, distribution place administrator
and distribution place administrator, administrators,
Industry casher, distribution place casher and Shopping
mall casher register are logout the system.
Alternative flow of If he/she fills the form in incorrect place the system
events responds with warning message to add, delete, update and
search goods and goods information. It displays leave or
stay message.
Description 2
Use case name Control
Use case number 2
Use case description The administrator control the other
administrators at different level
Participating actor Administrator
Pre-condition The administrator must login the online
trade interaction system
Flow of events Administrator control what the industry
administrator, distribution place
administrator and shopping mall
administrator add, delete and update.
Post-conditions Administrator successfully logout the
system
Alternative flows of events If he/she fills the form in incorrect place
the system responds with warn message,
it display leave or stay message.
Description 3
Use case name Add
Use case number 3
Participating actors Industry Administrator, distribution place
administrator and Shopping mall
administrator
Use case description Industry Administrator, distribution place
administrator add goods to different table
of the system.
Pre-condition The Industry Administrator, distribution
place administrator and Shopping mall
administrator must login the online trade
interaction system
Flow of events The Industry Administrator, distribution
22 | P a g e
administrator click the navigation button
to logging in.
The system displays the format form with
different option button. He fill the form
and click Submit button to submit once
the appropriate information are filled in
required place.
Post-conditions The Industry Administrator, distribution
administrator logout the system.
Abnormal flow of events or Alternative If he/she fills the form in incorrect place
conditions the system responds with warn message,
it display leave or stay message.
Description 4
Use case name Chat
Use case number 4
administrator ,Shopping mall
administrator, Administrator
administrator, Administrator chat each
other to shear idea about the goods that
the industry produce
place administrator, Shopping mall
administrator and administrator must
login the online trade interaction system
Flow of events When one of the administrator opens the
system then they can see which user is
online and they can chat about their
products
Post-condition The Industry Administrator, distribution

place administrator, Shopping mall
administrator and administrator logout
the system.
23 | P a g e
Description 5
Use case name Search
Use case number 5
Participating actor The Industry Administrator, distribution
administrator
Use case description The Industry Administrator, distribution
administrator search the goods and they
get the information about the goods that
they search.
administrator must login to the system.
Flow of events She /he click the search button
The online trade interaction system
displays the format of the searching item
button.
The Industry Administrator, distribution
administrator can search the available
goods information.
Post-conditions The pharmacist assistance must logon to

the system.
Alternate flow of events If he/she clicks a button on incorrect
place the system responses with options
leave or stay page.
Description 6
Use case name Update
Use case number 6
Participating actor The Industry Administrator, distribution
administrator
Use case Description The Industry Administrator, distribution
administrator search the goods and they
can update the information of the goods
that they search .
24 | P a g e
administrator must be login to the
system.
Flow of events She /he click the update button
The online trade System displays the
format of the update button.
administrator can update the information
that they see in the update form.
Post-condition The Industry Administrator, distribution

administrator logout to the system.
Alternative flow of events If he/she clicks a button on incorrect
leave or stay page.
Description 7
Use case name Register
Use case number 7
Participating actor Industry casher, distribution place casher
and Shopping mall casher
Use case description Industry casher, distribution place casher
and Shopping mall casher register the
sells goods to their own table
Pre-condition They must be Login in to the system.
Flow of events She /he click the Register button
The online trade interaction System
displays the format of the register button.
These different cashers must be register
the sales goods to their table.
Post-conditions They must be logout to the online trade

interaction system.
leave or stay page.
Description 8
25 | P a g e
Use case name delete
Use case number 8
Participant actor Industry Administrator, distribution place
administrator
administrator delete those goods that are
not in the store or the whole goods in the
store is soled
Pre-conditions The Industry Administrator, distribution
administrator must be login to the system.
Flow of events She /he click the update button
The online trade interaction System
displays the format of the update button.

administrator can delete the goods that
are no longer in the store.
Post-conditions The Industry Administrator, distribution

administrator should logon to the system.
Alternative flow of events If he/she clicks a button on incorrect
leave or stay page.
Description 9
Use case name Comment
Use case number 9
Participating actor customer
Use case description The customer comment the goods that
they purchase.
Pre-conditions the customer purchase the goods.
Flow of events The customer purchase the goods and
after they use the goods they can give
comment about the product the use.
Post-conditions The administrator give response for the
comment that is given by the customer
Abnormal condition If he/she fills the comment filed in
incorrectly the system responds with
26 | P a g e
warn message, it display leave or stay
message.
Description 10
Use case name Order (prescription)
Use case number 10
Participating actors distribution place administrator and
Shopping mall administrator
Use case description distribution place administrator order the
goods he/she need to the industry
administrator, the Shopping mall
administrator order the goods that he/she
need to the distribution place
administrator
Pre-condition distribution place administrator and
Shopping mall administrator login to the
system
Flow of events The distribution place administrator fills
the filled to order the goods and click the
order button, the industry administrator
response for the order
The Shopping mall administrator fills the
filled to order the goods and click order
button, the distribution place
administrator response the order.
Post-conditions distribution place administrator and

Shopping mall administrator logout to the
system
leave or stay page.
Description 11
Use case name logout
Use case number 11
administrator, Administrator, Industry
casher, distribution place casher,
Shopping mall casher.
Use case description The online trade interaction must be
closed when the Industry Administrator,
27 | P a g e
distribution place
administrator, Administrator, Industry
casher, distribution place casher,
Shopping mall casher are finished their
work.
Pre-condition They must have done different activities
from the system.
Flow of events She /he click the logout button
Online trade interaction displays the
format of the logout button.
They must close the online
tradeinteraction.
Post-conditions They must be logout the system.

leave or stay page.
Table 5: description of use case model
3.4.2. Scenario
Key user Scenario (Needs)
Administrator To view all goods detail
Control sub-administrators
To view, add and update goods
Industry Administrator To view, add and update customers

To view goods Information in detail
distribution place administrator To add, delete and update goods
To view goods detail
Shopping mall administrator To view all sold goods detail
Industry casher To register sold goods of the industry
Distribution casher To register distributed goods for shopping
malls
Shopping mall cashier To register sold goods of the shopping mall
Table 5: Scenarios
Scenario: 1
Name of use case: login
Participating instance actor: Industry Administrator, distribution place administrator, shopping
mall administrator, Administrator, Industry casher, distribution place casher, Shopping mall casher.
28 | P a g e
Entry condition:
OTIS must be installed on the computer.
OTIS must be published on the web document.
OTIS must be on the active state.
Normal flow:
He/She clicks on the service navigation button to login.
The system displays the format form with different options of button.
He/she fill the form and click create Button, to create a new Email, submit button to submit
once the appropriate information is filled in required place.
Alternate conditions (Abnormal flow):
If he/she fill the form in incorrect place the system responds with warn message.
Exit condition: The system saves the entered data into database.
Special requirement: The SDK (software development kit) must be installed on the computer
before installing OTIS.
Scenario: 2
Name of use case: Control
Participating instance actor: Administrator
Entry condition:
The administrator must login the online trade interaction system.
Flow of Events:
Administrator control what the industry administrator, distribution administrator and
shopping mall administrator add, delete and update.
Alternate Condition (Abnormal Flow):
If he/she fills the form in incorrect place the system responds with warn message, it displays
leave or stay message.
System state on completion: The system saves the type of money on the services site navigation
key.
Special requirement: the SDK (software development kit) must be installed on the computer
Scenario: 3
Name of use case: Add
Participating instance actor: Industry Administrator, distribution place administrator and
Shopping mall administrator
Entry condition:
The Industry Administrator, distribution place administrator and Shopping mall
administrator must login the online trade interaction system
Flow of Events:
administrator click the navigation button to logging in.
The system displays the format form with different option button.
29 | P a g e
He fills the form and click Submit button to submit once the appropriate information is
filled in required place.
If he/she fills the form in incorrect place the system responds with warn message, it displays
leave or stay message.
System state on completion: The system saves the type of money on the services site navigation
key.
Scenario: 4
Name of use case: Chat
Participating instance of use case:
Industry Administrator, distribution place administrator ,Shopping mall administrator,
Administrator
Entry Condition:
The Industry Administrator, distribution place administrator, Shopping mall administrator
and administrator must login the online trade interaction system.
Flow of events:
When one of the administrator opens the system then they can see which user is online and
they can chat about their products
System State on compilation: The system saves the process on the database of Services.
Scenario: 5
Name of the use case: Search
Participating instance actor:
administrator
Entry condition:
Flow of events:
She /he click the search button
The online trade interaction system displays the format of the searching item button.
administrator can search the available goods information.
If he/she clicks a button on incorrect place the system responses with options leave or stay
page.
30 | P a g e
before installing OTIS
Scenario: 6
Name of use case: Update
Participating instance of use case:
administrator.
Entry condition:
Flow of events:
She /he click the update button
The online trade System displays the format of the update button.
administrator can update the information that they see in the update form.
Exit condition: The system saves the process on the database of Services.
Scenario: 7
Name of use case: Register
Industry casher, distribution place casher and Shopping mall casher
Entry condition:
They must be Login in to the system.
Flow of events:
She /he click the Register button
The online trade interaction System displays the format of the register button.
These different cashers must be register the sales goods to their table.
Scenario: 8
Name of use case: Delete
Industry Administrator, distribution place administrator and Shopping mall administrator
Entry condition:
administrator must be login to the system.
31 | P a g e
Flow of events:
She /he click the update button
The online trade interaction System displays the format of the update button.

administrator can delete the goods that are no longer in the store.
Scenario: 9
Name of use case: Comment
customer
Entry condition: the customer purchase the goods.
Flow of events:
The customer purchases the goods and after they use the goods they can give comment
about the product the use.
Alternate conditions (Abnormal flow):
If he/she fills the comment filed in incorrectly the system responds with warn message, it
displays leave or stay message.
Scenario 10:
Name of the use case: order (prescription)
distribution place administrator and Shopping mall administrator.
Entry condition:
distribution place administrator and Shopping mall administrator login to the system
Flow of events:
The distribution place administrator fills the filled to order the goods and click the order
button, the industry administrator response for the order
The Shopping mall administrator fills the filled to order the goods and click order button,
the distribution place administrator response the order.
Alternate conditions (Abnormal flow)
page.
Scenario 11:
Name of the use case: Logout
32 | P a g e
Industry Administrator, distribution place administrator, Shopping mall administrator,
Administrator, Industry casher, distribution place casher, Shopping mall casher.
Entry condition:
They must have done different activities from the system.
Flow of events:
She /he click the logout button
Online trade interaction displays the format of the logout button.
They must close the online trade interaction.
Alternate conditions (Abnormal flow)
page.
3.4.3. Object Model
Data Dictionary
Classes Attributes Operations Description

operations
Login User Name, Password Write () Allow to access the data
Login() or information
Logout - Logout() For security from accessing by other
users
Add GName, GId, CName, Write () Allow employers to access data easily
ExDate,proDate,Engridant Add() and understandable way
Delete GName, GId, CName, Delete() Allow employers and customers from
ExDate,proDate,Engridant wasting time customers who dont exist
any more
Search GName, GId Write () Allow employers and customers
Search() retrieve data easily
Update GName, GId, Write ()
ExDate,proDate,Engridant Update()
Control Cont-Id, Cont-Name Write () Allow the casher to what product is
control() sold
comment Product-id,ProdectName Write () Allow the customers to what product
comment() is sold
Register GName, GId, CName, Write () Allow the employers to record data
ExDate,proDate,Price Register() easily and retrieve later
33 | P a g e
Order Product-id, Customer-info Write () Allow the customer what product is he
(Prescription) Order() used based on its order
chat Sname, Saddress Chat()
Class Diagram
Class diagrams are the most popular UML diagrams used by the object oriented
community. It describes the objects in a system and their relationships. Class diagram
consists of attributes and functions.
This is one of the most important of the diagrams in development.
The diagram breaks the class into three layers. One has the name, the second
describes its attributes and the third its methods. The private attributes are
represented by a padlock to left of the name.
The relationships are drawn between the classes.
Developers use the Class Diagram to develop the classes.
Analyses use it to show the details of the system.
Adminstrator
+Username String
+Password String
Distribution Place Admin +login(): String

+control(): String
+Username String +chat(): String
1
+Password String +search(): String
+logout(): String
+login(): String Customer
+add(): String 1..* 1
+search(): String 1 +Name String
+order(): String 1..* +Address String
+update(): String 1..* +comment(): String
Shopping Mole Admin
+chat(): String
+delete(): String 0..* +Username String 0..*
+logout(): String +Password String 1
+login(): String
1..*
1 +add(): String
+search(): String
+order(): String
0..*
1 1 +update(): String
1 1 +chat(): String
+delete(): String
Distribution Place Cashier Database +logout(): String
+Username String +store(): String
+Password String 1
0..* 1
+register(): String
1
+login(): String
+logout(): String
0..*
0..* Industry admin
Shopping Mole casher +Username String

+Password String
+Username String
+Password String +login(): String
+add(): Strig
+login(): String +search(): String
+register(): String +update(): String
+logout(): String +chat(): String
+delete(): String
+logout(): String
34 | P a g e
3.4.4. Dynamic Model
Sequence Diagram
The purpose is to show the functioning through a use case. In other Words, we call it mapping
processes in terms of data transfers from the actor through corresponding objects.
To represent the logical flow of data with respect to a process.
It must be remembered that the sequence diagram displays Objects and not the classes.
The sequence of login into the page
administrator loginpage system homepage
1 : enterUserNameAndPassword()
2 : checkvaluieenterd()
3 : presslogin()
4 : display()
5 : invalid()
35 | P a g e
The sequence of admin controls the sub-admin and customer
customer administrator subadmin
1 : comment()
2 : transferTheComment()
3 : responseForTheMessage
4 : correctionForProduct()
The sequence of the industry and distributers
36 | P a g e
farmer industry distributers
1 : suplieGoods()
2 : requestForRawMaterial()
3 : giveRawMaterial
Activity Diagram
It shows the control flow from one activity to another. Activity diagram is another important
diagram to describe dynamic behavior. Activity diagram consists of activities, links, relationships
etc. It models all types of flows like parallel, single, concurrent etc.
Activity diagram describes the flow control from one activity to another without any messages.
These diagrams are used to model high level view of business requirements.
The login activity
37 | P a g e
Enter username and Password
submit the username and password
verify the login operation

Invalid login
Validate
Valid login
display the home page
The activity of administrator
38 | P a g e
login
control the activity of subadmins
chat with subadmins
search into the page
logout after he finish
The activity of sub-administrator
login
add and search the items
order the goods
update and delete the items
No
Are you sure

Are you sure
Yes
update and delete the items
it logout after finish
The activity of Distribution Place Cashier, Industry Casher and Shopping Mole casher
39 | P a g e
login
register
accessing the page
logout after doing something
The activity of customer
use the product
commented about the product
40 | P a g e
3.4.5. User Interface
Online trade interaction has the following main interface:

Admin: use this system to control the whole system and to interact the system users
Sub Admin: are those admins in the industry, in the distribution place and those in the shopping
mall, those admins use the system create interaction between themselves.
Customer: use the system to give comment about the product.
Fig 3.1 home page
41 | P a g e
Chapter Four
System Design Documentation
4. System Design Documentation
4.1. Introduction
The System Design Document describes the system requirements, operating environment,
system and subsystem architecture, files and database design, input formats, output layouts,
human-machine interfaces, detailed design, processing logic, and external interfaces.
4.2. Design Goal

Developing an application of any significant scope typically begins with a perceived problem
and the desired solution that is implemented through the use of software. As a result, an
application is in simple terms a collection of software that has been consolidated to solve a
defined set of problems.
Solving such problems through the practical application of software is referred to as software
engineering. As with any other engineering project, whether it is building a bridge, an aircraft
carrier, or even something seemingly as simple and mundane as a can opener, a considerable
amount of effort is put forth before laying a single brick, riveting a single rivet, or forging the
first piece of steel.
During this phase, called the design goal, several elements will impact and shape the design of
the application. Some of these elements are typically non-negotiable or finite resources, such as
time, money, and manpower. Others, such as available technologies, knowledge, and skill, are
dynamic and will vary throughout the development life cycle.
While these elements influence the design of the application to some extent, the problem dictates
what capabilities the application must possess to develop a satisfactory solution. Although other
capabilities could be addressed here, we will focus on six, which are (in alphabetical order):
availability, manageability, performance, reliability, scalability, and securability.
Availability: All applications are available at least some of the time, but Web-based applications
and mission-critical enterprise applications must typically provide round-the-clock services. If
your enterprise application needs to work 24 hours a day, 7 days a week, you probably need to
design for high availability. Advances in hardware and software have dramatically increased the
quality of high-availability applications. However, availability is not easy to implement and
requires a considerably more complex architectural infrastructure than the previous generation of
client/server applications.
If your application requires high availability, you will want to understand how design choices
help maximize application availability and how testing can validate planned service levels.
42 | P a g e
Manageability: With distributed applications, you worry about where things are on the network,
how components are deployed and configured, and how to set the security attributes for 10,000
different users. Sometimes you even wonder if the application is working as intended. And there
is certainly no time for round-trip travel between your home office and the dozens (hundreds?) of
remote sites that require either software upgrades or repairs.
Performance: Key application metrics, such as transaction throughput and resource utilization,
define application performance. Metrics related to hardware, such as network throughput and
disk access, are common application performance bottlenecks. From a users perspective,
application response time defines performance. Of course, performance does not come without a
price. While it is possible to build a high performance application for any given problem space, a
key price point is the cost per transaction. It is sometimes necessary to sacrifice performance to
control cost.
Reliability: As distributed applications grow both in size and complexity, there is an increasing
need to improve the reliability and operating quality of software. First, the cost of application
failure is often too high. Users bypass unreliable Web sites, resulting in lost revenue and reduced
future sales, and the expense of repairing corrupted data can further increase the cost of
application failure. Second, unreliable systems are difficult to maintain or improve because the
failure points are typically hidden throughout the system. Finally, modern software technology
makes it easy to create reliable applications.
Scalability: Scalability is the capability to increase resources to yield a linear (ideally) increase
in service capacity. The key characteristic of a scalable application is that additional load only
requires additional resources rather than extensive modification of the application itself.
Securability: The ability to provide security to an application and its data is referred to here as
securability. The securability of an application is impacted by numerous design choices, such as
the selection of communication protocols and the method of user authentication.
4.3. Proposed Architecture
4.3.1. Overview
Architecture has to do with planning and designing the system to each other:
A general term to describe buildings and other physical structures of the system and the
relationship of each other.
Three tier architecture is the client tier never communicates directly with the data tier; in a three-
tier model all communication must pass through the middle tier. Conceptually the three-tier
architecture is linear.
Three-tier architecture is a software design pattern and well-established software architecture. Its
three tiers are the presentation tier, application tier and data tier.
Three tier architectures consist of three components distributed in three layers:
43 | P a g e
Client (requester of services),
Server (provider of services)
Database (data and file services).
The three components made the three-tier architecture.
User Interface (entering the requesting using different types of user interfaces such as text
field check box, button and etc..) if the user uses computer.
Web server/application server (such as connecting the user and database and the
transition of the data)
Database (storing data and file services)
Why we choose three-tier architecture?
Three-tier architecture allows any one of the three tiers to be upgraded or replaced
independently. The user interface is implemented on a desktop PC and uses a standard graphical
user interface with different modules running on the application server. The relational database
management system on the database server contains the computer data storage logic. Our system
is containing or communicate the web browser to web server sending the request and the web
server to requesting to the database retrieve the data to user.
pc server database
web server Database

web browser
Fig 4.1. Deployment diagram- three tire architecture
4.3.2. Subsystem Decomposition
Subsystem decomposition describes the decomposition into subsystems and the responsibilities
of each. This is the main product of system design.
Control subsystem: this sub system is responsible for handling the work of other administrator.
Industry subsystem: this sub System show responsible for the industry admin to control the work done
in the industry.
44 | P a g e
Customer subsystem: this sub system shows responsible for the customer to give comment about the
product that they use.
Distribute subsystem: this sub system shows the responsibility of the distributer to distribute goods for
the retailors
Shop subsystem: this subsystem shows the responsibility of the shop to sell the goods for the customer
Connector: The connection subsystem is responsible for handling connection to the database.
Privilege Subsystem: - this subsystem is responsible for handling privileges for each users of the system.
4.3.3. Hardware/software mapping

Hardware/software mapping describes how subsystems are assigned to hardware and off-the-
shelf components. It also lists the issues introduced by multiple nodes and software reuse.
Application server
register goods develop Database1

client
pc1 register goods that are in the distributer stor
mysql database
web browser2 register goods that are in the shopping mole
register goods sold by industry
register goods that are distributed by distributer
register goods sold by retailor to customer
Fig 4.2. deployment diagram hardware software mapping
45 | P a g e
4.3.4. Persistent Data Management
This describes the persistent data stored by the system and the data management infrastructure
required for it. This section typically includes the description of data schemes, the selection of a
database, and the description of the encapsulation of the database.
Online trade interaction will largely depend on a relational database to perform day-to-day
operations and storing log data. Data will be stored in a MYSQL 2014 DBMS and manipulated
through the Database Subsystem, which will ensure data integrity and consistency. Database
Subsystem will contain all necessary SQL queries that will be accessible by the rest of the
Subsystems. The database will be backed up on a daily basis to ensure data security.
The data stored in the database will include:
Developed goods information

Distributed goods information
Sold goods information
Chat information
4.3.5. Access Control and security

Access control and security describes the user model of the system in terms of an access matrix.
This section also describes security issues, such as the selection of an authentication mechanism
and the management of keys.
The system verifies whether the information entered is valid or not. If it is valid, the system will
give access to the user based on the group to which the user belongs.
4.3.6. User Interface Design
Main page
The main page contains all menus and sub menus at the left side on the page.
46 | P a g e
- The customer selects the goods
- The customer then selects the mall that he/she bought the goods
- Then the customer enters the message that he/she want to send
- Then when the send button clicked the customer sent the comment to the admin
- The admin and the casher of the system inserts their username and the password that
store in the database
- When they click the submit button the admin and casher can successfully logedin to the
system and they can chat each other.
47 | P a g e
Chapter Five
Object Design Document
5. System Design Documentation
5.1. Introduction
It describes object design trade-offs made by developers, guidelines they followed for subsystem
interfaces, the decomposition of subsystems into packages and classes, and the class interfaces.
5.2. Object Design trade-offs

Developing an emulator designed for digital preservation will be different from mainstream
emulators. This is because the focus will be less on performance and more on durability and
flexibility.
5.2.1. Development Cost Versus Functionality

Online trade interaction system has different interfaces with their corresponding functionality.
For each designing and additional functionalities cost is required. Without these functionalities
the system is unimaginable so even though it is costy we have to concentrate on the
functionalities rather than the development cost.
5.2.2. Understandability versus Efficiency

Understandability and efficiency have direct relationship. Because if the system is understandable
and easy to implement then it will hover on our scopes. This include the data types that the user
has to enter in to the text boxes, for what purpose specific input is needed and so on. So then the
user will enter the valid input that the program is waiting for. Here the program will proceed soon.
5.2.3. Security versus Availability

In online trade interaction: users must be authorized to connect to the system from web, and
unauthorized people should not be able to access the system. Each subadmin will be able to login
to the system by using the username and password that is assigned by Administrator. And
Availability is the degree to which a system or component is operational and accessible when
required for use. We know that if the system is available, discussing about security is nothing.
Though the system can be available but the system has money transactions so, we focus on the
security part a little more than on availability.
5.4. Interface Documentation Guidelines

Variables
48 | P a g e
Are values that can change, depending on conditions or on information passed to the program.
Variable names should be descriptive of the variables use. All variable names will be nouns.
Each word after the first word will be capitalized. For constants, variable names should be in all
capital letters and an underscore character should separate each word.
Examples: - integer GId;

String GName;
Classes
Class is a set of objects that describes the contents of the objects that belong to it and defines
the operations(Methods).
Classes will be named with singular nouns or noun phrases. Each word should be capitalized.
Examples: Control
Methods
A method is a procedure associated with a message and an object.

All methods are named with verb phrases, and the first letter of each word should be capitalized.
Example: control ();
Various Notes
Form- is a representation of a GUI window.

Text box- is a GUI element intended to enable user to input text information to be used by the
program.
Command button- is a GUI element that allows a user to trigger an event.
Forms, textboxes, command buttons, and so forth that are used for the interface will be assigned
names according to standard and conventional Notation.
Example: goodSearch will be the form used for the search goods.
Exception
Exception is an event, which occurs during the execution of a program, that disrupts the normal
flow of the program's instructions. When error occurs, the application will display an appropriate
49 | P a g e
error message to the user and then allow the user to terminate the application or close the error
message and proceed with the application.
Database
A database is an organized collection of data.

Database fields will be named using noun phrases.
Example: GoodId.
50 | P a g e
51 | P a g e

Object Oriented System Analysis Design Project Group1Project

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Object Oriented System Analysis Design Project Group1Project

Uploaded by

Copyright:

Available Formats

College of computing and informatics

Department of software engineering

Online Trade interaction system

1. Alif Tesfaye CIR/055/07

Submitted to Mr. Ermiyas B

Submission date December 24, 2016

1.1. Introduction ......................................................................................................................................... 6

3.2. Functional Requirements ......17

3.3. Non-Functional Requirements.18

3.4. System Models.19

3.4.1. Use case Models.19

3.4.3. Object Model..33

3.4.4. Dynamic Models35

3.4.5. User Interface41

4.2. Design Goal..42

4.3. Proposed Architecture ..........43

4.3.2. Subsystem Decomposition44

4.3.3. Hardware/Software Mapping.45

4.3.4. Persistent Data Management.46

4.3.5. Access Control and security....46

4.3.6. User Interface Design...46

5.2. Object Design Traded-offs...........48

5.2.1. Development Cost Verses Functionality..48

5.2.2. Understandability verses Functionality.48

5.2.3. Security Verses Availability..48

1.2. Problem of Statement

Quality and labor:

1.3.1. General Objective

1.3.2. Specific Objective

1.5. Significance of the project

1.6.1. Operational Feasibility

1.6.2. Technical Feasibility

1.6.3. Economic Feasibility

Fig 1. Waterfall Model

1.7.1. System Development Tool

Script languages and languages PHP, JavaScript, CSS, HTML

Table 1.1. system development tools

1.7.2. Object Oriented Requirement Model and Analysis

Question1: Thanks, the willingness of about this interview?

Manager: no matter I am happy

Question2: When did you start to distribute the product?

Manager: Four year Ago

Question3: Say something about your company?

Manager: I am happy to discuss to you

Question1: Thanks, the willingness of about this interview?

Fowad: no matter I am happy

Question2: When did you start to distribute the product?

Fowad: Two year ago

Question3: Say something about their company?

Question4: Thank you help this interview?

1.9. Team members and Their Activities

3. Leta Tesfaye CIR/298/07 Lati.lataaf@gmail.com -Data gathering

4. Kaleab Yalewdag CIR/274/07 Kaleabyalewdeg46@gm -Documentation

Hardware tool as Resource cost

Resources Amount Price (ETB)

System Tool Cost

Time year 2009 E.C

2.2. Current system

2.3. User of the Current System

3.2. Functional requirment

Functional requirements specify specific behavior or functions, for example:

Table 2: Functional Requirements

3.3. Nonfunctional requirements

III. Software Quality Attributes