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

NAME ID No.
1. Alebachew Meseret----------------------------------071/02
2. Mebrahtu Hafte---------------------------------------507/02
3. Mekash Alemu----------------------------------------513/02
4. 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.....................................................................................................................................9

Table 2.2: log out.................................................................................................................................10

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

Table 2.16: View Report......................................................................................................................24

Table 2.17: Manage user......................................................................................................................25

List of figure
Figure 2.1: Use case diagram................................................................................................................ 8

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

Figure 2.14: Approve request..............................................................................................................38

Figure 2.15: View request................................................................................................................... 39

Figure 2.16: manage user.................................................................................................................... 40

Figure 2.17: update item info...............................................................................................................41

Figure 2.18: Search item..................................................................................................................... 42

Figure 2.19: Cancel request.................................................................................................................43

Figure 2.20: View item........................................................................................................................44

Figure 2.21: Delete user...................................................................................................................... 45

Figure 2.22: View own loan................................................................................................................46

iii
 Figure 2.23: View user loan................................................................................................................ 47

Figure 2.24: View report..................................................................................................................... 48

Figure 2.25: Add item......................................................................................................................... 49

Figure 2.26: Request online................................................................................................................ 50

Figure 2.27: Update item info............................................................................................................. 51

Figure 2.28: Approve request..............................................................................................................52

Figure 2.29: Manage user....................................................................................................................53

Figure 2.30: Register user................................................................................................................... 54

Figure 2.31: View request....................................................................................................................... 55

Figure 3.1: Deployment Diagram............................................................................................................ 56

Figure 3.2: Class diagram........................................................................................................................ 58

Figure 3.4 Adding Item page................................................................................................................... 60

Figure 3.5 Register user page...................................................................................................................61

Figure 3.6 Request online page................................................................................................................62

Figure 3.7 Manage user form...................................................................................................................63

Figure 3.8 Update item information.........................................................................................................64

Figure 3.9 Search item............................................................................................................................. 65

Figure 3.10: E-Diagram........................................................................................................................... 66

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.

v
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, that’s 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.
 1.3. Existing System Study
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 couldn’t get a clearance in a fast because of the store manual record
checking systems.

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

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

2
  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.

1.5.2. Specific objectives

In Order to achieve the general objective, the following specific objectives are needed.

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

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

3
 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

4
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

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

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

5
  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.
 Macromedia Dreamweaver and notepad++: to edit the PHP code.

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

2.2.4. System Requirement

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.

6
  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.

7
2.3. Analysis Models

2.3.1. Use case diagram

Figure 2.1: Use case diagram

8
 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

9
 Table 2.2: log out
Use case name log out

Participating actor Store administrator, store keeper and user.

Entry condition The user stays in the home page of the system.

Basic course of action 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 Add Item

Participating actor Store keeper

Entry condition The store keeper activates received item form.

Pre condition The store keeper should login to the system

Basic course of action 1. The system displays received item form to the keeper.
2. The store keeper enters details of new item.
3. 4.The system checks the entered criteria
4. 5. The store keeper stores the item to database

Alternative course of action 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.

Basic course of action 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 Approve request

Participating actor Store keeper

Entry condition The Store keeper activates request approval form.

Pre condition The Store keeper should log in to the system.

Basic course of action 1. The system display request approval form

2. The user inserts their user username and password
3. The system displays the requested data that request by the user
4. The Store keeper will check the request form data
5. Store keeper approve the request

Alternative course of action 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 Update Item info.

Participating actor Store keeper

Entry condition The store keeper activates form for update

Pre condition The store keeper should login to the system

Basic course of action 1. The system displays the form

2. The store keeper inserts item name to search the updated item.
3. The system display the update information
4. The store keeper fills the updated information.
5. The store keeper click update button.
6. The item will be updated

Alternative course of action 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 View user loan

Participating actor Store keeper

Entry condition The Store keeper activates form.

Pre condition The Store keeper should log in to the system.

Basic course of action 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 View loan

Participating actor user

Basic flow of event 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

Alternative course of action 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

16
 Table 2.9: Request online
Use case name Request online

Participating actor Users

Entry condition The users find form to send request.

Basic flow of event 1. The system displays the request form.

2. The users fill the form to send request
3. The system validates request form.
4. The users send request by clicking send button.
5. 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.

Alternative course of action 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 View item

Participating actor Store keeper and user

Entry condition 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 1. The system displays the form.

2. The actors click the view button
3. The system displays the items that are stored in the system.
4. Then the actors see the list item and decide what they want.

Exit condition When the actors closes the displayed view item

Alternative course of action 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 Cancel Request

Participating actor User

Entry condition The users look request form.

Basic course of action 1. The system displays request form.

2. The actors search the request form by their id
3. The actors see and check the previous request form.
4. 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

Alternative course of action 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 Search for item

Participating actor Store keeper and user

Entry condition The actors activate the form.

Basic course of action 1. The system display the form

2. The actors inserts the item name to the form
3. The actors click search button
4. 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.

Alternative course of action 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 Delete User

Participating actor Store manager

Entry condition The actor activates the form.

Basic course of action 1. The system displays the form

2. The Store Admin enters user ID.
3. The system Search the user information from the database
4. The system display conformation (yes or no)
5. 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.

21
 Table 2.14: Register User
Use case name Register User

Participating actor Store manager

Entry condition The actor activates the form.

Basic course of action 1. The system display the form

2. The actor fills the attributes of the beneficiary
3. The actor clicks register button
4. The beneficiary is registered to the Database

Exit condition When the actor exit from the form.

Pre condition The actor should log in to the system.

Post condition The beneficiary is registered to the Database

Alternative course of action 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 The actor activates the form.

Basic course of action 1. The system display the search form

2. The actor enters the id to search the user to update its loan
information
3. The system displays the previous loan information
4. The actor updates the necessary information
5. The actor clicks update button
6. The loan information is already updated

Exit condition When the actor exit from the form.

Pre condition The actor should log in to the system.

Post condition The loan information is already updated

Alternative course of action 1. .If the entered loan information are incorrect go to step 4
[ alternative course of action 1 ]

23
Table 2.16: View Report
Use case name View Report
Actor Store manager.
Description: The system allows Store manager to viewing report.

Pre-condition The Store manager is log on to the system

Post condition
Basic course of action 1. The system displays the form
2. The actor clicks the view button
3. The system displays the report.

24
Table 2.17: Manage user
Use case name Manage user

Participating actor Store manager

Entry condition The Store manager activates the form.

Pre condition The Store manager should log in to the system.

Basic course of action 1. The system displays manage user form.

2. The Store manager search user by entering user id .
3. The system displays the user info page.
4. 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.

25
2.3.2. Activity 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

37
Figure 2.14: Approve request

38
Figure 2.15: View request

39
Figure 2.16: manage user

40
2.3.3. Sequence diagram

Figure 2.17: update item info

41
Figure 2.18: Search item

42
Figure 2.19: Cancel request

43
Figure 2.20: View item

44
Figure 2.21: Delete user

45
Figure 2.22: View own loan

46
Figure 2.23: View user loan

47
Figure 2.24: View report

48
Figure 2.25: Add item

49
Figure 2.26: Request online

50
Figure 2.27: Update item info

51
Figure 2.28: Approve request

52
Figure 2.29: Manage user

53
Figure 2.30: Register user

54
Figure 2.31: View request

55
 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

56
 3.1.2. Architectural Design

a. Class diagram
 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.

57
Figure 3.2: Class diagram

58
 3.1.3. User Interface Design

This user interface design shows the sample of our project implementation part.

Figure 3.3 Login page

59
Figure 3.4 Adding Item page

60
Figure 3.5 Register user page

61
Figure 3.6 Request online page

62
Figure 3.7 Manage user form

63
Figure 3.8 Update item information

64
Figure 3.9 Search item

65
 3.1.4. Data Structure Design

a. ER-Diagram

66
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

67
 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
If (*variable is valid*)
(*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)
Otherwise
68
 Display “empty loan item”
End if
Otherwise
Display “the entered input is invalid”
End if
End

Pseoudocode update item info.

Steps/procedure
Method name= update item info.
Begin
Variable:
 Item name
If (*variable is valid*)
 (*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
Display “the entered input is invalid”
End if
End

Pseoudocode for login

Steps/procedure
Method name=login
Begin
Variables:

69
  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)

70
 Otherwise
Display “inputs are invalid”
End if
End

Pseoudocode search item

Steps/procedure
Method name= search item
Begin
Variables:
 item name
 item model
 search date
If (*variables are valid*)
Then
Add to table report (item name, item model and search date)
Otherwise
Display “doesn’t exist”
End if
End

Pseoudocode view request

Steps/procedure
Method name= view request
Begin
Variables:
 Name
 Empid
 Itemid
 Request no
 request date
 quantity

71
  address
 Phone no
 sex
If (*variables are valid*)
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
If (*variables are valid*)
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

72
 Begin
Variables:
 ItemId
 Empid
 ReqId
 RequestDate
 Quantity
If (*variables are valid*)
Then
Add to table Request (ItemId, Empid, ReqId, RequestDate, and Quantity)
Otherwise
Display “your request is invalid”
End if
End

73
Bibliography
Ambler, S.W. (2000a). The Object Primer 2nd Edition – The Application Developer’s 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.
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.

74
75