By Kabessa Fiqaadu From Dambi Dollo

BAHIRDAR UNIVERSITY
INSTITUTE OF TECHNOLOGY
SCHOOL OF COMPUTING AND ELECTRICAL ENGINEERING
PROJECT ON
TITLE: - IOT STORE MANAGEMENT SYSTEM

SUBMITTED
IN PARTIAL FULLFILMENT OF THE REQUIRMENTS FOR THE

DEGREE OF BACHELOR OF SCIENCE
IN
INFORMATION TECHNOLOGY
BY
PROJECT GROUP NAME
1.
2.
3.
4.
NAME
ID No.
Alebachew Meseret----------------------------------071/02
Mebrahtu Hafte---------------------------------------507/02
Mekash Alemu----------------------------------------513/02
Mesfin Ayele------------------------------------------543/02
January 2013
BAHIR DAR, ETHIOPIA
IOT STORE MANAGEMENT SYSTEM

by
PROJECT GROUP NAME
NAME
ID No.
Alebachew Meseret----------------------------------071/02
Mebrahtu Hafte---------------------------------------507/02
Mekash Alemu----------------------------------------513/02
Mesfin Ayele------------------------------------------543/02
A project submitted to School of Computing and Electrical Engineering of
Bahirdar University in partial fulfillment of the requirements for the degree of
Bachelor of Science in
INFORMATION TECHNOLOGY PROGRAM
Advisor: Eyob G.
January 2013
Bahir Dar, Ethiopia
Declaration
The Project is our own and has not been presented for a degree in any other university and all the
sources of material used for the project/thesis have been duly acknowledged. (Name and
Signature up to the number of the project group members)
Name
Signature
Alebachew Meseret
-----------------------------
Mebrahtu Hafte
-----------------------------
Mekash Alemu
-----------------------------
Mesfin Ayele
-----------------------------
School: School of Computing and Electrical Engineering

Program: INFORMATION TECHNOLOGY
Project subject: IOT STORE MANAGEMENT SYSTEM

I certify that this project satisfies all the requirements as a project for the degree of Bachelor of
Science.
------------------------------------- --------------------------------------------Name of program coordinator Signature
This is to certify that I have read this project and that in my opinion it is fully adequate, in scope
and quality, as a thesis for the degree of Bachelor of Science.
------------------------------------- --------------------------------------------Name of Advisor Signature
Examining committee members signature Date
1. Chairman ____________ ___________
2. Examiner 1 ____________ ___________
3. Examiner 2 ____________ ____________
It is approved that this project has been written in compliance with the formatting rules laid
down by the school of the university.
Table of Contents
Chapter one.................................................................................................................................................1
1.1.
INTRODUCTION...................................................................................................................1
1.2.
Background..............................................................................................................................1
1.3.
Existing System Study.............................................................................................................2
1.4.
Proposed System......................................................................................................................2
1.5.
Objectives of the Project..........................................................................................................3
1.5.1.
General objectives....................................................................................................................3
1.5.2.
Specific objectives...................................................................................................................3
1.6.
Scope.......................................................................................................................................3
1.7.
Beneficiaries of the project......................................................................................................4
1.8.
Methodology............................................................................................................................4
1.9.
Significance of the Project.......................................................................................................4
Chapter Two:...............................................................................................................................................5
2.1.
Existing System Description....................................................................................................5
2.2.
System Features.......................................................................................................................5
2.2.1.
Hardware Requirement............................................................................................................5
2.2.2.
Software Requirement.............................................................................................................5
2.2.3.
User Requirement....................................................................................................................6
2.2.4.
System Requirement................................................................................................................6
a.
Functional Requirements.........................................................................................................6
b.
Non Functional Requirements..................................................................................................7
2.3.
Analysis Models......................................................................................................................8
2.3.1.
Use case diagram.....................................................................................................................8
a.
Use case description.................................................................................................................9
2.3.2.
Activity diagram....................................................................................................................26
2.3.3.
Sequence diagram..................................................................................................................41
Chapter Three:...........................................................................................................................................56
SYSTEM DESIGN......................................................................................................................................56
3.1.1.
Deployment Diagram.............................................................................................................56
3.1.2.
Architectural Design..............................................................................................................57
a.
Class diagram 57
3.1.3.
User Interface Design............................................................................................................59
3.1.4.
Data Structure Design............................................................................................................66
a.
ER-Diagram 66
b.
Entities and attribute with descriptions 67
3.1.5
Algorithm Design..................................................................................................................68
List of table
Table 2.1: log In
Table 2.2: log out 9

Table 2.3: Add Item
11
Table 2.4: View Request
12
Table 2.5: Approve Request
13
Table 2.6: Update Item info.
14
Table 2.7: View user loan 15

Table 2.8: View own loan 16
Table 2.9: Request online 17
Table 2.10: View item
18
Table 2.11: Cancel Request 19

Table 2.12: Search for item 20
Table 2.13: Delete User
21
Table 2.14: Register User 22

ii
Table 2.15: Update user loan

Table 2.16: View Report
23
Table 2.17: Manage user
24
23
List of figure
Figure 2.1: Use case diagram
Figure 2.2: log in 26

Figure 2.3: Delete user
27
Figure 2.4: View item
28
Figure 2.5: add item
29
Figure 2.6: Search item
30
Figure 2.7: update user loan
31
Figure 2.8: update item info.
32
Figure 2.9: accept request 33

Figure 2.10: View loan
34
Figure 2.11: cancel request 35

Figure 2.12: Request online
36
Figure 2.13: Register user 38

Figure 2.14: Approve request
39
Figure 2.15: View request 40

Figure 2.16: manage user 41
Figure 2.17: update item info
43
Figure 2.19: Cancel request

45
46
Figure 2.22: View own loan

iii
42
44
47
Figure 2.23: View user loan

Figure 2.24: View report
49
Figure 2.25: Add item
50
48
51
Figure 2.27: Update item info
52
53
Figure 2.29: Manage user 54

Figure 2.30: Register user 55
Figure 2.31: View request..................................................................................................................... 56
Figure 3.1: Deployment Diagram.......................................................................................................... 57
Figure 3.2: Class diagram...................................................................................................................... 60
Figure 3.4 Adding Item page................................................................................................................. 61
Figure 3.5 Register user page................................................................................................................ 62
Figure 3.6 Request online page.............................................................................................................. 63
Figure 3.7 Manage user form................................................................................................................. 64
Figure 3.8 Update item information....................................................................................................... 65
Figure 3.9 Search item........................................................................................................................... 66
Figure 3.10: E-Diagram......................................................................................................................... 67
iv
Acknowledgement
We would like to express our deepest appreciation and special thanks to our advisor Eyob G.
who give us immeasurable help to done our project .without his guidance and persistent help
this project would not have been possible with this time.
We have special thanks to the workers of Bahir Dar University (IOT) store system who helped
us in providing the necessary information and material such as working manuals for preparing
this document.
Finally we would like to forward our special thanks to school of computing and electrical
engineering who gave us immeasurable help by preparing computer class and internet to done
our project.
Abstract
The IOT store in Bahir Dar University (BDU) uses manual process system. When customers
need to borrow an item and return the borrowed item they must go to the office and record what
they want manually, thats way it is making the process too late. Which requires the employee to
use paper based recording files to know the status of each customer and to perform the process in
the system. The paper includes three chapters or phases. The first phase covers the introduction,
which contains background, Existing system study, proposed system, objective of the project,
benefits of the project, scope, methodology and significant of the project. The second phase
covers the system features which contain existing system description, hardware requirement,
software requirement, user requirement, system requirement, functional requirement, non
functional requirement, Use case diagram, Use case description, activity diagram and sequence
diagram.
The third phase covers system design which include Deployment diagram, user interface design,
ER diagram and Algorism design.
vi
Chapter one
1.1.
INTRODUCTION
The IOT store in Bahir Dar University (BDU) is giving an important service for its
community which is found in that Institute.
The properties of the store are acquired from donation or supplier with appropriate
procurement these properties are distributed based on formal request forms. The current
system gives vast service however it uses manual management system which leads the
system to be inefficient. As part of the effort to bring efficient and modern store management
system in IOT, The new system should be designed and implemented that enables properties
to be controlled and managed properly.
1.2.
Background
Bahir Dar University is found in Bahir Dar city which is the capital city of the Amhara
National Regional State. The establishment of Bahir Dar University owes a lot to two former
higher institutions. The Bahir Dar polytechnic institute which formed one of the faculties of
the university was established in 1963.The other fraternal institution of higher learning called
Bahir Dar teachers college was established more than three decades ago. The college then as
academy of pedagogy was established in 1972 by the tripartite agreement of the imperial
government UNESCO and UNDP and started actual work in the following year under the
auspices of the ministry of education and fine arts.
The two fraternal institution of higher learning were integrated and formed Bahir Dar
University following the council of ministers regulation.60/1999[www.bdu.edu.et].the
university was inaugurated on May 6, 2000.The polytechnic institute and Bahir Dar teachers
college are renamed faculty of engineering and faculty of education respectively. In addition
to these the university has now four more faculties namely the collage of business and
Economics, collage agriculture and IOTex.
Existing System Study
1.3.
The existing store management system is functioning using manual system.

This manual system in which all the activities are carried out the following problems
Materials are recorded issued and returned manually through long steps.
Searching and getting available items are requested for use by staff takes long
time and it is boring.
Employees couldnt get a clearance in a fast because of the store manual record
checking systems.
1.4.
Getting necessary report about the properties is difficult and takes long time.
And we expect to find out more problems in the existing system during our study.
Proposed System
Our proposed online store management system that attempts to replace the manual system
has the following nature.
The system can record any new item issue requested items with appropriate
specification and category.
The system generates a unique ID for each new fixed asset which is added to the
database.
The system can enable to search items that are available in the store house and use.
It shortens the step by step processes in delivering or returning items.
It generates up to date report at any time for decision makers for budget allocation
and controlling.
The system has database security. Since each workers in the store house has its own
privilege to do their allowed operation on the database.
1.5.
Objectives of the Project
1.5.1.
General objectives
The main objective of our project is to explore the overall existing system of BDU (IOT)
store management and to develop web based store management system for the existing
system.
Specific objectives
1.5.2.
In Order to achieve the general objective, the following specific objectives are needed.
1.6.
Understand Manual process and its efficiency of the existing system

Review the current system to know the problem.
Identify functional and nonfunctional requirements.
Propose possible solutions for current system.
Model the new system using object oriented methodologies.
Finally implement and test the new system.
Scope
In this project we were occupied in the assessment of the existing system and identifying the
problems of IOT store management system. We proposed possible alternative solutions
which can help to choose the best feasible solution and design an efficient online system for
IOT store management system. At the survey of the existing system, we found that BDU
store management system is very broad and complex to implement within a period of
academic semester by team of regular students.
So we decided to bound our scope to develop an automated online store management system
for POLY (IOT).
1.7.
Beneficiaries of the project
Employers: - Bahir Dar University, IOT store workers

Staffs: - Administrative staffs, Instructors, Technical assistance of the schools
Student: - disable students, student union (for some clubs that are found in the Institute)
1.8.
Methodology
The project is to be carried out by a team of students. Initially there will be continuous
discussion with the entire store worker to get detail information about the store through
interviewing and physical observation. To see how the current system works, the problem
associated with the current system, skill that is needed by the store management and workers
to reduce the problem that they are facing at present. The implemented of the system will be
user friendly and built in php programming language and the database. The approach we are
going to implement will be structured query language (MY-SQL) server which will be more
appropriate to store database and queries.
1.9.
Significance of the Project
Unauthorized person will be out of service
Each tasks are performed easily
Can perform many tasks in short period of time
Every staff will be participant
Change the manual system of the organization to computerized system
Reduce unnecessary resource wastage.
Reduce employee overload work.
System gives fast service to the customer
Chapter Two:
2.1. Existing System Description

The existing store management system currently is functioning using manual system. Firstly
the user requests their needs to the purchaser and the purchaser approves the request. And
also the store manager checks the item whether it found in the system or not. If the requested
item is exist the user fill the form and take the item that he/she need. But if the requested item
is existed, store manager permitted to the purchaser to buy the requested item and the
manager announce to the user the item you need is coming.
2.2. System Features

2.2.1.
Hardware Requirement
2.2.2.
Window XP server 2003, 2008: with the following attributes:

o Minimum 512 MB Memory
o Printer: To have a hard copy for the data.
o Keyboard: To give input to the computer.
Software Requirement
The client PC running the system may use any of the following operating system:
Windows
The client PC may use one of the following browsers:

o Internet Explorer
o Commit Bird
o Mozilla Firefox
o Google chrome..etc
But the system needs to fulfill the following software:
Operating system: MS-window 2003, 2008 server will be used for the system.
Database management software (DBMS): is the mandatory one for the new system.
To implement the database easily, (MySQL) is recommended.
Application software: to develop user and administrative interface it also used for
connecting to the database, Most MS-Office applications are appropriate.
PhpMyAdmin: choose PHP scripting language which aims at providing the user with
an interface that is easy to learn and attractive.
2.2.3.
Macromedia Dreamweaver and notepad++: to edit the PHP code.
User Requirement
The user interface shall be menu driven, it shall provide dialog boxes; help screens,
drop down lists, radio buttons, check boxes and text boxes for user input.
The navigation from one screen to the other must be easy.
Necessary material for using the system will easy to the customer.
Customers must fullfil the business rule to apply registration.
The store keeper can check the items that are taken by the staffs.
System Requirement
2.2.4.
A requirement specification is an agreement between the end user and the system developer.
a. Functional Requirements
Log on: the system validates the store staff to use the system.
Receive Item: the system allows the store keeper to enter a new item which comes
from deliverer or donor at the acquisition time.

Approve Request: the system allows the store administrator to search the
availability of the items in the store before approving the requested item
availability and relevance.

Cancel Request: the system allows the store administrator to cancel the approved
request before the items are issued by the store keeper using approval number.
View Report: the system allows the store administrator and store keeper to
overview and report from the system database monthly.

Request Item: the staff request item to the system.
Search Item: the staffs search the item whether it found or not in the store.
The system generate error message that says the number of certain item become
zero
b. Non Functional Requirements
Maintenance: The store Management System is being developed in php. Php is an

object oriented programming language and shall be easy to maintain
Portability:-The store Management System shall run in any Microsoft Windows

environment that contains php Runtime and the Microsoft Access database.
Reliability: - The store Management System service should not access without
authenticate user.
Standards Compliance: - The graphical user interface of the system shall have
easily understood to the user (have consistent look and feel graphical user
interface).
Performance: -Acceptable response times for system functionality.
Security: - Access to the various subsystems will be protected by a user log in
screen that requires a user name and password.
2.3. Analysis Models

2.3.1. Use case diagram
Figure 2.1: Use case diagram
a. Use case description

A use case is a methodology used in system analysis to identify, clarify, and organize system
requirements. The use case is made up of a set of possible sequences of interactions between
systems and users in a particular environment and related to a particular goal. Use case is a
list of steps, typically defining interactions between a role (known in UML as an actor) and a
system, to achieve a goal. The actor can be a human or an external system.
Table 2.1: log In

Use case name
Log In
Participating actor
Store administrator, store keeper, and user.
Entry condition
The user opens the home page of the system.
Basic course of action
1. The user wants to log in into the system.

2.The system displays the form
3. The user inputs his/her username and password into the system.
4. The system verifies that the user is eligible to log in into the system (account
checking in the database).
5. The user login into the system.
Alternative course of action
The system updates the user period of time and the number of log in failure.
Exit condition
When the user click log off button.
Pre condition
The user has a user name and password.
Post condition
The user login into the system and do in the system the allowed operation
Table 2.2: log out

Use case name
9
log out
Participating actor
Entry condition
Store administrator, store keeper and user.

The user stays in the home page of the system.
1, The user stays in its home page.
2, The user wants to log out into the system.
3.The user clicks the log out button
4. The user logout from the system.
Exit condition
When the user click log off button.
Pre condition
The user stays in the home page of the system.
Post condition
The user logout from the system.
10
Table 2.3: Add Item

Use case name
Participating actor
Entry condition
Pre condition
Add Item
Store keeper
The store keeper activates received item form.
The store keeper should login to the system
1.
2.
3.
4.
The system displays received item form to the keeper.

The store keeper enters details of new item.
4.The system checks the entered criteria
5. The store keeper stores the item to database
If there is any invalid entry then the system displays error message and
allows the store keeper to re-enter the correct data.
Exit condition
When the Store keeper close the form
Post condition
The item is added to the database.
11
Table 2.4: View Request

Use case name
View request
Participating actor
Store keeper
Entry condition
The Store keeper activates view request form.
Pre condition
The Store keeper should log in to the system.
1. The system displays view request form.

2. The Store keeper click the view button .
3. The system displays the requested data.
Exit condition
1. When the Store keeper closes the form.
Post condition
1. The Store keeper view the list of requested from the system.
12
Table 2.5: Approve Request

Use case name
Participating actor
Entry condition
Pre condition
Approve request
Store keeper
The Store keeper activates request approval form.
1.
2.
3.
4.
5.
The system display request approval form

The user inserts their user username and password
The system displays the requested data that request by the user
The Store keeper will check the request form data
Store keeper approve the request
If the requested item is not exist the system displays not found message
Exit condition
When the Store keeper closes the form.
Post condition
Approve and save the data to the store database.
13
Table 2.6: Update Item info.

Use case name
Participating actor
Update Item info.

Store keeper
Entry condition
The store keeper activates form for update
Pre condition
The store keeper should login to the system
1.
2.
3.
4.
5.
6.
The system displays the form

The store keeper inserts item name to search the updated item.
The system display the update information
The store keeper fills the updated information.
The store keeper click update button.
The item will be updated
If there is any invalid entry then the system displays error message and
allows the store keeper to re-enter the correct item name.
Exit condition
When the Store keeper close the form
Post condition
The item will be updated
14
Table 2.7: View user loan

Use case name
Participating actor
Entry condition
Pre condition
View user loan

Store keeper
The Store keeper activates form.
1. The system display the form
2. The Store keeper click the view button
3. The system display the loan item
Exit condition
When the Store keeper closes the form.
Post condition
The Store keeper views the list of all loan users and other related
information.
15
Table 2.8: View own loan

Use case name
Participating actor
Basic flow of event
16
View loan
user
1. The system displays view own loan form

2. The user insert loan id to view their loan item
3. The user view all the loan materials
If the user remember the loan material not need to see the view loan form
Pre condition
The user should log on the system.
Post condition
See the loan items and return
Table 2.9: Request online

Use case name
Participating actor
Entry condition
Basic flow of event
Request online
Users
The users find form to send request.
1.
2.
3.
4.
5.
The system displays the request form.

The users fill the form to send request
The system validates request form.
The users send request by clicking send button.
The request form is now registered.
Exit condition
When The users log off from the system
Pre condition
The users should log in to the system.
Post condition
The users request registered to the system.
1. If the entered password and user name is incorrect go to step 2

[alternative course of action 1]
2. If the entered information are incorrect go to step 5 [alternative
course of action 2]
17
Table 2.10: View item

Use case name
Participating actor
Entry condition
View item
Store keeper and user
The actors needs view item form.
Pre condition
The actors should log on the system.
Post condition
Retrieve stored items and view the item list.
Basic flow of event
Exit condition
1.
2.
3.
4.
The system displays the form.

The actors click the view button
The system displays the items that are stored in the system.
Then the actors see the list item and decide what they want.
When the actors closes the displayed view item

If the entered user name and password is incorrect, go to step
1[alternative course of action 1].
18
Table 2.11: Cancel Request

Use case name
Participating actor
Entry condition
Cancel Request
User
The users look request form.
1.
2.
3.
4.
The system displays request form.

The actors search the request form by their id
The actors see and check the previous request form.
When they are not available, cancel the request.
Exit condition
When the actors closes the form.
Pre condition
The actors should log in to the system.
Post condition
The actors cancel the request
1. If the entries user name and password is incorrect go to step

1[alternative course of action 1]
2. If the id is incorrect go to step 3 [ alternative course of action 2
19
Table 2.12: Search for item

Use case name
Participating actor
Entry condition
Search for item

Store keeper and user
The actors activate the form.
1.
2.
3.
4.
The system display the form

The actors inserts the item name to the form
The actors click search button
The system displays the information of search item
Exit condition
When the Store keeper and users close the form.
Pre condition
The Store keeper and users should log in to the system.
Post condition
The Store keeper and users search the item by click search button.
1.If the entered password and user name are incorrect go to step 2
[ alternative course of action 1 ]
2.If the name is incorrect go to step 5 [ alternative course of action 2
20
Table 2.13: Delete User

Use case name
Participating actor
Entry condition
21
Delete User
Store manager
The actor activates the form.
1.
2.
3.
4.
5.
The system displays the form

The Store Admin enters user ID.
The system Search the user information from the database
The system display conformation (yes or no)
The Store Admin Delete the user successfully.
Exit condition
When the actor exit from the form.
Pre condition
The actor should log in to the system.
Post condition
The user is out of the service.
Table 2.14: Register User

Use case name
Register User
Participating actor
Store manager
Entry condition

1.
2.
3.
4.
The system display the form

The actor fills the attributes of the beneficiary
The actor clicks register button
The beneficiary is registered to the Database
Exit condition
Pre condition
Post condition
The beneficiary is registered to the Database
If the entered attribute(s) is(are) incorrect go to step 2 [ alternative course

of action 1]
22
Table 2.15: Update user loan

Use case name
Update user loan
Participating actor
Store keeper
Entry condition
1. The system display the search form

2. The actor enters the id to search the user to update its loan
3.
4.
5.
6.
information
The system displays the previous loan information
The actor updates the necessary information
The actor clicks update button
The loan information is already updated
Exit condition
Pre condition
Post condition
The loan information is already updated
1. .If the entered loan information are incorrect go to step 4

[ alternative course of action 1 ]
Table 2.16: View Report

Use case name
23
View Report
Actor
Description:
Store manager.
The system allows Store manager to viewing report.
Pre-condition
Post condition
The Store manager is log on to the system

1. The system displays the form
2. The actor clicks the view button
3. The system displays the report.
Table 2.17: Manage user

Use case name
Participating actor
Entry condition
Pre condition
24
Manage user
Store manager
The Store manager activates the form.
The Store manager should log in to the system.
25
1.
2.
3.
4.
The system displays manage user form.

The Store manager search user by entering user id .
The system displays the user info page.
Store manager can enable/disable the user
Exit condition
2. When the Store manager closes the form.
Post condition
2. The Store manager can enable/disable user in the system.
2.3.2. Activity diagram
Figure 2.2: log in
26
27
28
Figure 2.5: add item
29
30
Figure 2.7: update user loan
31
Figure 2.8: update item info.
32
Figure 2.9: accept request

33
Figure 2.10: View loan
34
Figure 2.11: cancel request
35
36
37
Figure 2.13: Register user
38
39
Figure 2.15: View request
40
Figure 2.16: manage user
41
2.3.3. Sequence diagram
Figure 2.17: update item info
42
43
Figure 2.19: Cancel request
44

45
46
Figure 2.22: View own loan
47
Figure 2.23: View user loan
48
Figure 2.24: View report
49
Figure 2.25: Add item
50
51
Figure 2.27: Update item info
52
53
Figure 2.29: Manage user
54
Figure 2.30: Register user
55
Figure 2.31: View request
56
Chapter Three:
SYSTEM DESIGN
Our project system design includes deployment diagram, class diagram, graphical user interface, E-R
diagram and algorithm design.
3.1.1. Deployment Diagram
Figure 3.1: Deployment Diagram
57
3.1.2. Architectural Design

a. Class diagram
58
Staff: a person who get any service from the store.

Store Keeper: a person who receives new items and receives returned items.
Store Administrator: a person who creates username, password for the users.
Item: an item is any goods which are used by the staffs. And it is divided as renewable
and non renewable items

Request: request that is sent by the staffs and managed by the store keeper.
Loan: it is used to see the staffs their own loan and to see the store keeper the loan of
their user
Account: account is created by the store admin and used by the staffs and store workers.
59
Figure 3.2: Class diagram
3.1.3. User Interface Design

This user interface design shows the sample of our project implementation part.
Figure 3.3 Login page
60
Figure 3.4 Adding Item page
61
Figure 3.5 Register user page
62
Figure 3.6 Request online page
63
Figure 3.7 Manage user form
64
Figure 3.8 Update item information
65
Figure 3.9 Search item
66
3.1.4. Data Structure Design

a. ER-Diagram
67
Figure 3.10: E-Diagram
b. Entities and attribute with descriptions

The IOT store management has at least three staff office including main store
Item:-Have an attributes (name, price, quantity, model, expired date) with primary key
item_id and it used by the user.
User:-Have an attributes (name, address, phone No, gender, birth date) with
primary key user_id and it uses their account.
Account: - Have an attributes (username, status, gender, birth date) with primary key
password and it created by store administrator
and also used by the user.
Store administrator:-Have an attributes (name, address, phone No, gender, birth date,
salary, status) with primary key Admin_id and have privilege to create user account
Store keeper:-Have an attributes (name, address, phone No, gender, birth date, salary,
status) with primary key keeper_id and have privilege to view request
68
3.1.5
Algorithm Design
In this part we describe the algorithm of the operations or methods which found in class
diagram using Pseoudocode. Pseoudocode is one type of algorithm representation method by
using English language.
Pseoudocode view own loan
Steps/procedure
Method name= view own loan
Begin
Variable:
Empid
If (*variable is valid*)
Then
Items that loan by the user are display
Otherwise
Display the entered input is invalid
End if
End
Pseoudocode update user loan
Steps/procedure
Method name= update user loan
Begin
Variable:
Empid
(*select the loan item from database *)
If loan item=not null
Then
The loan information display and the store keeper enters the update information
Add to table loan (updated information)
69
Otherwise
Display empty loan item
End if
Otherwise
End if
End
Pseoudocode update item info.
Steps/procedure
Method name= update item info.
Begin
Variable:
Item name
(*select the Item name from database and compare with entered*)
If Item name= entered username
(*go to update item info *)
The item information display and the store keeper enters the update information
Add to table item (updated information)
Otherwise
Display error!
End if
Otherwise
End if
End
Pseoudocode for login
Steps/procedure
Method name=login
Begin
70
Variables:
Username
Password
If (*inputs are valid*)

(*select the previous username and password from database and compare with entered*)
If username = entered username and
Password = entered password
(*go to login page*)
Otherwise
Display login error!
End if
Otherwise
Display inputs are invalid try again!
End if
End
Pseoudocode register user
Steps/procedure
Method name=register user
Begin
Variables:
first name
last name
Middle name
Empid
Birth date
address
Phone no
sex
If (*variables are valid*)

Then
Add to table register user (first name, last name, middle name, Empid, birth date, address,
phone no and sex)
Otherwise
71
Display inputs are invalid

End if
End
Pseoudocode search item
Steps/procedure
Method name= search item
Begin
Variables:
item name
item model
search date
Then
Add to table report (item name, item model and search date)
Otherwise
Display doesnt exist
End if
End
Pseoudocode view request
Steps/procedure
Method name= view request
Begin
Variables:
Name
Empid
Itemid
Request no
request date
quantity
address
Phone no
sex

72
Then
Add to table request (name, empid, Itemid, request date, request no address, phone no
and sex)
Otherwise
Display inputs are invalid request
End if
End
Pseoudocode view report
Steps/procedure
Method name= view report
Begin
Variables:
Name
Empid
Report type
report date

Then
Add to table report (name, empid, Report date, Report type)
Otherwise
Display inputs are invalid report
End if
End
Pseoudocode Request online
Steps/procedure
Method name= Request online
Begin
Variables:
73
ItemId
Empid
ReqId
RequestDate
Quantity
Then
Add to table Request (ItemId, Empid, ReqId, RequestDate, and Quantity)
Otherwise
Display your request is invalid
End if
End
Bibliography
Ambler, S.W. (2000a). The Object Primer 2nd Edition The Application Developers Guide to
Object-Orientation. New York: Cambridge University Press.
Ambler, S.W. (1998a). Building Object Applications That Work Your Step-by-Step Handbook
for Developing Robust Systems With Object Technology. New York: Cambridge University Press.
74
System analysis and design text book i.e.
HOFFER
Ambler, S.W. (2000b). The Unified Process Inception Phase. Gilroy, CA: R&D Books.
Ambler, S.W. (2000c). The Unified Process Elaboration Phase. Gilroy, CA: R&D Books.
Ambler, S.W. (2000d). The Unified Process Construction Phase. Gilroy, CA: R&D Books.
Booch, G. (1994). Object-Oriented Analysis and Design with Applications, 2nd Edition.
Redwood City, California: The Benjamin/Cummings Publishing Company.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W. (1991). Object-Oriented
Modeling and Design.
Gane, C., Sarson, T. (1978). Structured Systems Analysis: Tools and Techniques.
Visit WWW.Ambysoft.com for more White Papers on Object-Oriented Development
Glossary
Activity diagram A UML diagram which can be used to model a high-level business process
or the transitions between states of a class (in this respect activity diagrams are effectively
specializations of state chart diagrams).
Actor Any person, organization, or system that interacts with an application but is external to
it.
Architectural modeling High-level modeling, either of the problem or technical domain,
whose goal is to provide a common, overall vision of the problem domain. Architectural models
provide a base from which detailed modeling can begin.
Class diagram -- Class diagrams show the classes of a system and their intrarelationships. Class
diagrams are often mistakenly referred to as object models.
Sequence diagram A diagram that shows the types of objects involved in a use-case scenario,
including the messages they send to one another and the values that they return.
75
76

By Kabessa Fiqaadu From Dambi Dollo

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

By Kabessa Fiqaadu From Dambi Dollo

Transféré par

Droits d'auteur :

Formats disponibles

BAHIRDAR UNIVERSITY

TITLE: - IOT STORE MANAGEMENT SYSTEM

IN PARTIAL FULLFILMENT OF THE REQUIRMENTS FOR THE

IOT STORE MANAGEMENT SYSTEM

School: School of Computing and Electrical Engineering

Project subject: IOT STORE MANAGEMENT SYSTEM

Existing System Study.............................................................................................................2

Objectives of the Project..........................................................................................................3

Beneficiaries of the project......................................................................................................4

Significance of the Project.......................................................................................................4

Existing System Description....................................................................................................5

Non Functional Requirements..................................................................................................7

Use case diagram.....................................................................................................................8

Use case description.................................................................................................................9

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

Data Structure Design............................................................................................................66

Entities and attribute with descriptions 67

Table 2.2: log out 9

Table 2.4: View Request

Table 2.5: Approve Request

Table 2.6: Update Item info.

Table 2.7: View user loan 15

Table 2.11: Cancel Request 19

Table 2.14: Register User 22

Table 2.15: Update user loan

Table 2.17: Manage user

Figure 2.2: log in 26

Figure 2.4: View item

Figure 2.5: add item

Figure 2.6: Search item

Figure 2.7: update user loan

Figure 2.8: update item info.

Figure 2.9: accept request 33

Figure 2.11: cancel request 35

Figure 2.13: Register user 38

Figure 2.15: View request 40

Figure 2.19: Cancel request

Figure 2.21: Delete user

Figure 2.22: View own loan

Figure 2.23: View user loan

Figure 2.25: Add item

Figure 2.26: Request online

Figure 2.27: Update item info

Figure 2.28: Approve request

Figure 2.29: Manage user 54

Existing System Study

The existing store management system is functioning using manual system.

It shortens the step by step processes in delivering or returning items.

Objectives of the Project

Understand Manual process and its efficiency of the existing system

Beneficiaries of the project

Employers: - Bahir Dar University, IOT store workers

Significance of the Project

Unauthorized person will be out of service

Each tasks are performed easily

Can perform many tasks in short period of time

Every staff will be participant

Change the manual system of the organization to computerized system

Reduce unnecessary resource wastage.

Reduce employee overload work.

System gives fast service to the customer

2.1. Existing System Description

2.2. System Features

Window XP server 2003, 2008: with the following attributes: