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 item20

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 23

Table 2.17: Manage user 24

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 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 42

Figure 2.18: Search item 43

Figure 2.19: Cancel request 44

Figure 2.20: View item 45

Figure 2.21: Delete user 46

Figure 2.22: View own loan 47

iii
 Figure 2.23: View user loan 48

Figure 2.24: View report 49

Figure 2.25: Add item 50

Figure 2.26: Request online 51

Figure 2.27: Update item info 52

Figure 2.28: Approve request 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.

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:

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

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

7
2.3. Analysis Models

2.3.1. Use case diagram

Store Management System

Delete User Update Item Info
*
*
** * Register User
*
Add Item
store manager Manage User
*
*

«uses» log out

View user loan *
*
* «extends» **
** *
«uses» *
View Report
«uses»
Log In
** *
* Store Keeper
*

View item
*

Check return
User Search item
*

Aprove Request
* Borrow Item
*

*
Update user loan
View own loan *

*
*
Cancel Request
Request oline View request

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 ]

Table 2.16: View Report

Use case name View Report

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

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.

24
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

Login

Store user(browse website)

Enter username and password

[ Incorrect]

[ Correct]

Login

Figure 2.2: log in

26
 Delete user

Get customer id

[ no]
Search from database

conformation

[ yes]

Delete from database

Figure 2.3: Delete user

27
 View item
login to the system

Enter user name and password [ Incorrect]

[Correct]

click viewbutton

display item

view all item

Figure 2.4: View item

28
 add item

(Store keeper) login to system

Activate form to add

Fill necessary attribute of the item

[ Incorrect]

[ Correct]

store the items in the database

Figure 2.5: add item

29
 Search item
login to the system

enter user name and password [ Incorrect]

[Correct]

display search form

enter item name

click search button

display the item information

Figure 2.6: Search item

30
 update user loan

(Store keeper) login to system

Activate the form to update

Fill the attribute that need to update

Click update button

[ Incorrect]

[ Correct]

Update succesfuly

Figure 2.7: update user loan

31
 update item info. login to the system

enter user name and password [ Incorrect]

[Correct]

display update form

enter item name

fill the update item information

display the update information

click update button

update item information

Figure 2.8: update item info.

32
 accept request

(Store keeper) login to system

The store keeper see the list of requested item

The store keeper activate the form

The store keeper inserts the user digital signature number

Click accept button

[ Incorrect]

[ Correct]

Accepte succesfuly

Figure 2.9: accept request

33
 View loan

log in the system

system validate

[ if incorrect]

systeme display view loan form

The user insert loan id to view their loan item

system display the loan item list

The user view all the loan materials

Figure 2.10: View loan

34
 cancle request

login

system validate

[ if incorrect]

systeme display form

actors searchs cancle info by user id

system display previouse request info

actors see info to cancle

then cancle by pressing cancle button

Figure 2.11: cancel request

35
 Request online

user[log in the system]

system validate

[ if incorrect]

systeme display request form

user fill the form

system validate
[ If incorrect]

user send the request by clicking send button

the request is registered

Figure 2.12: Request online

36
37
 Register user

(Storemanager) login to system

The system display the register form

The store manager fills attributes of user

click register button

[ Incorrect]

[ Correct]

regstered

Figure 2.13: Register user

38
 Approve request

(Store keeper) login to system

The store keeper insert the user digital signature number

The system display the request data

The store keeper check the request data

Click approve button

[ Incorrect]

[ Correct]

approved

Figure 2.14: Approve request

39
 view request

(store keeper)login the system

{if incorrect }

{correct}

system display view request form

click view button

see the list of requested data from DB

Figure 2.15: View request

40
 manage user

(Store manager)login the system

{if incorrect }

{correct}

system display manage user form

can enable/disable

Figure 2.16: manage user

41
2.3.3. Sequence diagram

:Home page<<GUI>> Store kepeer page Database

Storekeeper
Login()

Successfully login
Update item info

Go to store kepeer page

Search item to update

get item

Update the item

Successfull

Logout

Successfully logout

Figure 2.17: update item info

42
 :Home page<<GUI>> Store kepeer page Database

Storekeeper

enter username&password
search item
Successfully login

Go to store kepeer page

display form

enter item name

search item

get item

Successfull

Logout

Successfully logout

Figure 2.18: Search item

43
 cancle request form<<
cancle request check<<info>> press <<cancle>>button Database
UI>>
user login()
display the form
user see request cancle (request)

cancled()

sucessfully cancled

Figure 2.19: Cancel request

44
 :Home page<<GUI>> Database
Storekeeper

storekeeper page
view item Enter username&password
display view form

Successfully login

click view button

display item

view the item

Success

Logout

Successfully logout

Figure 2.20: View item

45
 Delete User
Delete(GUI) System Database

Store Admin

Select(User id)

Delete(user Id)

Deleted(User id)

Deleted()
Succesfuly deleted

closePage()

Figure 2.21: Delete user

46
View own loan view loan form<<UI>> press<<view>>button
insert<< id>> Database
User
login to the system
display the form

insert Id to generate info

click the view button

the system display the information for user from DB

user see the info

Figure 2.22: View own loan

47
 view user loan form<<
UI>>
insert<< id>> press<<view>>button

Store Keeper
login to the system Database
View user loan display the form
insert Id to generate info

click the view button

the system display the item list for stoke keeper from DB

Stoke keeper see the ietm list

Figure 2.23: View user loan

48
View report
Homepage<<GUI>> System
Store Admin
View<<GUI>> Database
Enter User name and Password
Succesfull()

Select Keeper or Purcheser

View(Report) display(Report)

displayed()
Report display

Succesfuly viewed

Figure 2.24: View report

49
 :Home page<<GUI>> Store Database

Store keeper page

Store keeper
Add item
Open page()

Login()

Open the form to add

Fill the item attribute

Store the item to DB

successfull
Logout()

clos page()

Figure 2.25: Add item

50
 :Home page<<GUI>> User page DB

User

Request online Browse page()

Login()

Fill the form to be request

Send the request

Succesfuly sent
Logout

Clos page()

Figure 2.26: Request online

51
 :Home page<<GUI>> User page Store DB

User

Update item info. Open Page()

Login()

Activate the form to update

fill the attribute to update

click update button

Update()
Successfully Updated

Updated()
Logout()
Clos page()

Figure 2.27: Update item info

52
 Approve request Approve request form<
storekeeper page press<<approve >>button Database
<UI>>
storekeeper
login()
display the form

Storekeeper check the request

approve request

approved()
Sucessfully approved

Figure 2.28: Approve request

53
 manage <<button>>
manage user form<<UI>> Database
store manager page

Store manajor
login()
Manage user display the form
Enter user id

click manage button()

manage user

Figure 2.29: Manage user

54
 register user form<<GUI> form content<<GUI>> register <<button>> DB
>
register user
Store manajor
login()
system display form

fill the form()

click register button()

the user successfully register to the database

Figure 2.30: Register user

55
 view request view request form<<GUI> view<<button>> Database
>

Store keeper
login()
system display view request form

click view button()

The Store keeper view the list of requested data from the database

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

:Web Server Store DB

:Application Server
{MYSQL}
<<RMI>>1
<<PHP>> 1 1
Client Server <<MYSQL>>
*
Cable

Printer

Figure 3.1: Deployment Diagram

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

58
 Employee
+Firstname : string
+Lastname : string
+Middlename : string
-EmpId : char
+BirthDate : Date
+Gender : string
+Address : char
-PhoneNo : int
-Userman : char
-Password : char
+Login()
Store keeper
User
+searchItem()
Store Admin +updateItemInfo.()
+searchItem()
+requestOnline() +addItem()
+manageUser() +viewOwnLoan() +updateUserLoan()
+deleteUser() +cancelRequest() +viewUserLoan()
+registerUser() +viewItem() +viewItem()
+viewReport() +approveRequest()
1 +viewRequest()
1 1
uses send
* 1
* view view
* *
Request
Item -EmpId : char
Loan
+ItemName : string -ItemId : char
-ReqId : char -EmpId : char
-ItemId : char
+Request Date : Date -ItemId : char
+ExpirDate : Date
+Quantity : int +Borrowed Date : Date
+Price : float
+Itemname : string
+Quantity : int +getEmpId()
+Quantity : int
+Model : char +getItemId()
+model : char
+getItemName() +getReqId()
+getEmpId()
+getItemId()
+getItemId()

Non renewable
+ReternDate : Date
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
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
69
 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:

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

71
 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

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

73
 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

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

75
76