Assosa University

College of Computing and Informatics

Department of Information Technology

WEB BASED APPLICATION FOR ATEVT STORE MANAGEMENT

SYSTEM

A Project Documentation Submitted to the Department of Information

Technology of Assosa University in Partial Fulfillment of Requirements
for the Degree of Bachelor of Science in Information Technology

Prepared by

NAME ID
1. TAKATLE ADESU ETW/119/06
2. MHARI MERTU ETW/110/06
3. DIRB ESHETU ETW/093/06

Submitted to Department of Information Technology

April, 2018
Assosa Ethiopia
 ACKNOWLEDGEMENTS

We would like to express our heart full gratitude to our advisors, Mr. Abraham T, for their
Encouragements, guiding, valuable comments and Helps
We also acknowledge Assosa University College of computing and informatics, Department of
Information Technology as well as we acknowledge to Assosa ATVT College for providing
valuable information to developing this proposal

i
Table of content
acknowledgements ............................................................................................................................
table of content ................................................................................................................................ II
list of tables ................................................................................................................................... IV
list of figure .................................................................................................................................... V
chapter one ...................................................................................................................................... 1
1. Introduction ................................................................................................................................. 1
1.1.background of the organization ................................................................................................ 1
1.2.existing system description ....................................................................................................... 1
1.3. Statement of the problem ................................................................................................. 2
1.4. Proposed system description ............................................................................................ 2
1.6. Objective of the study .............................................................................................................. 3
1.6.1. General objective .................................................................................................................. 3
1.6.2. Specific objective: ................................................................................................................. 3
1.7. Scope ............................................................................................................................ 3
1.7.1. Scope in ..................................................................................................................... 3
1.7.2. Scope out ................................................................................................................... 3
1.8. Methodology ............................................................................................................................ 4
1.8.1. Data collection ...................................................................................................................... 4
1.8.2. System development methodologies and tools ..................................................................... 4
1.9. Software tools .......................................................................................................................... 4
1.10. Hardware tools ....................................................................................................................... 5
1.11. Significance of the project ..................................................................................................... 5
1.12. Feasibility analysis ................................................................................................................. 6
1.12.1. Economical feasibility ........................................................................................................ 6
1.12.2 technical feasibility .............................................................................................................. 7
1.12.3 time feasibility ..................................................................................................................... 7
1.13. Time duration and plan of action .................................................................................. 7
Chapter two ..................................................................................................................................... 9
2. Analysis....................................................................................................................................... 9
2.1.1 description of the current system ........................................................................................... 9
2.1.2 business rules ......................................................................................................................... 9
2.2. Proposed system..................................................................................................................... 10
2.2.1 non-functional requirements and constraints ....................................................................... 10
2.2.2 functional requirements ....................................................................................................... 10

ii
2.2.3. Use case diagram ................................................................................................................ 11
2.2.4. Use case documentation ...................................................................................................... 13
2.2.5. Sequence diagram .............................................................................................................. 19
2.2.6 state chart diagram ............................................................................................................... 22
2.2.7 activity diagram ................................................................................................................... 26
2.2.8. Crc analysis ......................................................................................................................... 29
2.2.8.2: manage report ................................................................................................................. 30
2.2.8.4: manage stock and bin card .............................................................................................. 30
2.2.9. Conceptual modeling: class diagram .................................................................................. 31
2.2.10. User interface prototyping ................................................................................................ 32
chapter three .................................................................................................................................. 39
3. System design ........................................................................................................................... 39
3.1. Introduction ............................................................................................................................ 39
3.2 Purpose and goals of design ............................................................................................ 39
3.3. Proposed software architecture .............................................................................................. 40
3.3.1 Subsystem decomposition ............................................................................................... 40
3.4. Component diagram ............................................................................................................... 41
3.5 Deployment diagram ....................................................................................................... 42
3.6 Persistence modeling for object oriented database .......................................................... 43
3.7 Access control and security ............................................................................................. 45
3.8. References-----------------------------------------------------------------------------------------------47

iii
List of tables
table1.2. Cost ................................................................................................................................. 8
table 2.2.4.1: use case description for authentication .............................................................. 13
table2.2.4.2: use case description for manage account ............................................................ 14
table2.2.4.3: use case description for manage request ............................................................. 15
table2.2.4.4: use case description for manage report ............................................................... 16
table2.2.4.5: use case description for notice handling.............................................................. 16
table2.2.4.6: use case description for manage stock and bin card .......................................... 17
table2.2.4.7: use case description for check availability .......................................................... 18
table2.2.4.8: use case description for register salvage ............................................................. 18
table 2.2.8.2: manage report....................................................................................................... 30
table 2.2.8.4: manage stock and bin card .................................................................................. 30
table 2.2.8.5: manage request ..................................................................................................... 30
table 3.6 persistence modeling for object oriented database................................................... 43
table 3.8 access control and secure ............................................................................................ 45

iv
List of figure
figure 1: use case diagram .......................................................................................................... 12
figure 2.2.5.2 sequence diagram for manage account .............................................................. 19
figure 2.2.5.3 sequence diagram for manage request .............................................................. 20
figure 2.2.5.4 sequence diagram for generate report ............................................................... 20
figure 2.2.5.5 sequence diagram for notice handling ............................................................... 21
figure 2.2.5.6 sequence diagram for manage stock and bin card ........................................... 21
figure 2.2.6.1 state chart diagram for login .............................................................................. 22
figure 2.2.6.2 state chart diagram for manage account ........................................................... 22
figure 2.2.6.3 state chart diagram for manage request ............................................................ 23
figure 2.2.6.4 state chart diagram for manage report ............................................................. 24
figure 2.2.6.5 state chart diagram for notice handling ............................................................ 24
figure 2.2.6.6 state chart diagram for manage stock and bin card ......................................... 25
figure 2.2.6.7 state chart diagram for checking material availability .................................... 25
figure 2.2.7.1 activity diagram for login .................................................................................... 26
figure 2.2.7.2 activity diagram for manage account ................................................................ 26
figure 2.2.7.3 activity diagram for manage request ................................................................. 27
figure 2.2.7.4 activity diagram for manage report ................................................................... 27
figure 2.2.7.5 activity diagram for notice handling .................................................................. 28
figure 2.2.7.6 activity diagram for manage stock and bin card .............................................. 28
figure 2.2.7.7 activity diagram for check availability .............................................................. 29
figure 2.2.9. Conceptual modeling: class diagram .................................................................. 32
figure 2.2.10.4 admin interface for manage report ................................................................. 33
figure 2.2.10.5. User interface for manage account. ................................................................ 33
figure 2.2.10.6 user interface for approved request ................................................................. 33
figure 2.2.10.7 user interface to send request. .......................................................................... 34
figure 2.2.10.8 user interface for update request. .................................................................... 34
figure 2.2.10.9 user interface for storekeepers to register stock ............................................. 35
figure 2.2.10.10 user interface for storekeepers to register bin .............................................. 35
figure 2.2.10.11 user interface for storekeepers to report stock ............................................. 36
figure 2.2.10.12 user interface for storekeepers to report bin. ............................................... 36
figure 2.2.10.13 user interface for storekeepers to update stock ............................................ 37
figure 2.2.10.14 user interface for storekeepers to update account ........................................ 37
figure2.2.10.15 user interface for storekeepers to approve /disapprove request .................. 38

v
figure3.3.1 subsystem decomposition ....................................................................................... 41
figure 3.4 component diagram ................................................................................................... 42
figure 3.5 deployment diagram .................................................................................................. 43

vi
 CHAPTER ONE
1. Introduction
Store is the physical place where many varieties of materials are kept for the purpose of capital
work. In ATVET there is around three stores section.
They are: stationary, building and spare part, furniture, equipment, Aided materials, salvage store
and cleaning, clothing and kitchen materials stores. The main function this stores is receive, store
and issue materials.

1.1.Background of the Organization

ATEVT is a public higher educational institution established in 1994. .The campus is located in
amba 14 Keble 647 km northwest of Addis Ababa. From the 25 college which found in our country
ATVET college is one of them. In EFDRE agricultural and rural development minster based on
rural policy farmers and improved technology and new professional support increasing the
productivity and serve for market.
Mission
In agricultural sector to deliver quality education and training program, problem solver
agricultural technology transmission, industrial extension service, research and deployment,
realizing effective agricultural technique, vocation education and training in our region as well as
in our country and by increasing agricultural product and productivity transferring from
agricultural oriented to industrial oriented.
Vision
ATEVT aspires to be the leading public premier in the country, being best technique vocational
education and training center in a country.
1.2. EXISTING SYSTEM DESCRIPTION

In ATVT starting from the establishment there is a manual Store keeping system to manage the
college resources such as stationary, furniture’s Equipments Aided materials Cleaning, clothing
and spare parts and etc. This resources are unwisely used, store keepers do not know expired date
of some equipments and cannot manage status of equipments in the store whether it is break or not
as well as the time it takes for head offices to order, and managing the equipments are very boring
for the store keepers and it also makes overload of work on administrators and head offices.
Currently, the store system of ATVT works manually. This working condition has major
drawbacks.

1
  The registration process of incoming materials are manual and paper based
 Update information of material is also paper based
 Available materials are registered manually
 The material which used is found on paper

1.3. Statement of the Problem

We have found the following problems in existing manual store system of Assosa Atvet College
 Loss of Items and materials record files: - when items and materials are enter to the store,
the storekeeper records the items and materials on paper. Due to this problem records of
items and materials are lost and expose the store for data loss. This problem not only affects
the store but also affect the work system of the organization. Therefore, we will develop a
database system that used to record items and materials to solve the problem.
 Lack of communication: - there is communication gap between the storekeeper and
Property manager. Due to this problem the Administrators loss their time as well as they
doesn’t get the service in a good way. Therefore, we will develop a network system to
share data between the storekeeper and the Administrators in order to improve the
communication.
 Store keepers may do not know expired date of some equipment.
 Store keepers didn’t manage status of equipments that means whether it is break or not.
 The time it takes for head offices such as college heads to order equipments manually is
very boring and it also makes overload of work on administrators and head offices.

1.4. Proposed System Description

 We will develop a database system that used to record items and materials to solve the
problem.
 The system provides data connection between the storekeeper and the administrator in order to
improve communication
 The system shows the expired date of the item and the storekeeper does not get difficulty

2
1.6. Objective of the Study
1.6.1. General Objective
The general objective of this project is to develop automated system in order to eradicate the
manual Store management system of ATEVT College

1.6.2. Specific objective:

The specific objectives of our project are:-.
 Register resources:-The proposed system registers all the resources that are entered to
the organization.
 Send request:-the request sent from Head of colleges to get any service from the store.
 Register Salvage resource: To register resources such as computers, furniture’s and
others. It helps to know the number of resources that are used and returned to the store.
 Update Resources Data: It updates the resource information when needed.
 Search resource Data: To search resource data within short period of time.
 Generate report: To generate monthly as well as yearly report

1.7. Scope
1.7.1. Scope in
The scopes of our project are:-
 Increasing to the work efficiency of the office.
 Saving time that takes for sending request.
 Reducing unwisely used materials.
 Checking expired date of materials. Our proposed system shows warning when the
materials expired.
 Generating report monthly and yearly.
 Registering the outgoing materials and receiving the incoming materials.
1.7.2. Scope out
The project has its own scope out. The scopes out of our project are:-

 The system cannot provide online service for the organization

3
 1.8. Methodology
1.8.1. Data Collection
For the collection of data we use: observation, Interview, Questionnaires and document
analysis.
Observation: Observation is common methods of scientific research to collect the data.
We use observation to know the existing system of ATVT store management office,
different sub offices and how office member are handling the work in the office.
Interview: Interview is particularly useful for getting the history behind the participant’s
experiences. We used interview to get information about the existing system for developing
our project. The interview will be conducted on the head of store manager office and store
keeper member.
Document Analysis: Document analysis is used to understand how the system was worked.
We used this method to know all about the staff mission, vision, function and overall of their
work in short and brief.

1.8.2. System Development Methodologies and Tools

To develop the system, different software, hardware tools and programming language are
very important. Hardware tools such as computer (laptop), flash disk, network cable and CD,
software tool such as Net beans, Microsoft office word and PowerPoint and programming
language such as HTML and JavaScript are used.
We use object oriented programming language in our implementation of our project.
Because of our title has a lots of objects which coherently Organized and built the system
and also to show their inheritance and plat form independent of the system in detail.
In addition, the GUI of the object oriented programming language is too easy to the end user
of the system as well as it is easy to program and handle exceptional thrown.
1.9. Software Tools
Microsoft office word:-It is very useful because it takes less time to write and format the
text, communicative effectively smart diagram and chart tools, quickly assemble document.
By looking its useful properties we use Microsoft office word to type our project work to get
all the above benefits of it.

4
Power Point: use to present the document in abstract forms. We use it to present our
presentation in short and brief way.
Sublime for editing server and client side programming language like PHP, CSS,
JAVASCRIPT.
XAMPP is a server used to start apache PHP code.
MySQL is used to database Management.
1.1.1. Languages

Html: - The html language was designed to an effective way of achieving this transferring
of data and was designed to be evolving as new media format was created. We use html to
develop our statically parts of our code. We use because of html is compact and effective
language.
JavaScript: - JavaScript is very interesting language used to validate data and develop
different messages. We use it to validate our data which we use in html code.
CSS: - useful for decoration like hovering, active, list.
PHP:- we use server side programming language is PHP and for database MySQL

1.10. Hardware Tools

Different hardware’s used to develop our project.
Computer: - computer is a machine capable of doing many things. We use it to type on it
and install all software and programming language. All tasks are done on computer.
Network cable: used to run the proposed system and get the internet access by connecting
internet line from internet hub to computer for further read and search information from
internet.
Flash Disk and CD Hardware: used for the movement of data from one machine to
another. We use both of them when we move our data from one machine to another.

1.11. Significance of the Project

The significances of this project are:
 Avoiding wastage of storekeepers and head offices time in searching, registering and
calculating materials for report.

5
  Avoiding data loss because of improper data storage: in manual system case the store
keepers store their data on paper and In case of this the papers may be lose due to some
problem. The proposed system keeps the data in server even if the server is lose due to
some reason we have the backup of it.
 Avoiding improper item allocation: In manual case we waste most of our time in searching
location of objects but in automated system there is a proper location of materials for store
keepers.
 Avoid lack of communication: In manual system communication between storekeeper and
store manager and store manager and college heads is very slow since they will go from
one place to other, in this automated system since the proposed system is networked it will
speed up communication between them.
 Store keepers know expired date of some equipment: the system will give warning for
materials that are expired/out of date.
 reduce the clerical labor of the staff working in Stores both technical and as well as
Accounts departments using the latest technologies and cost effective tools there by
providing the better control to the management by avoiding manual errors etc. Generally
the significance of our project is: accurate, timeliness, reliable, secured, relevant and
valuable data are needed for store management in all dimensions
1.12. Feasibility Analysis

1.12.1. Economic Feasibility

The organization will lose money and time since the system is manual. So if our proposed system
is implemented unwise use of resource as well as time is saved. In manual System store
management if we take the materials that are expired in a year from the whole three stores they
lose around 10000 birr in a year.
From this 30% is lose because of unknown materials expire date, 50% lose by misuse of materials
and 20% lose because of materials order in their inappropriate place also when we calculate the
time it take for the manual record of received material on stock card and give materials for
requested on bin card it takes seven day for one person to complete but in our proposed system it
will take around 1 hours and minimize around 800birr paid for one person in a month that are used
for papers, pen and salary.

6
1.12.2 Technical Feasibility
The group members are expected the system to be technically feasible means that the store keepers,
store manager and head offices uses the system simply because the language we choose is familiar
with them and The requirements for our proposed system is available in The organization this
resources are Network cables with RJ-45, Computers with minimum of 2GB RAM, 200GB Hard
disk and since it is developed by the Object Oriented System Development technique it is simple
for any user of this organization. Finally the team has the ability to develop this system without
any difficulty since the team has studied the required methodologies and tools. So the system will
be technically feasible.
1.12.3 Time Feasibility
To develop the whole proposed system we need around total of eight month duration.
 Four months for Analysis and Design
 Four months for Implementation; the details of these two categories can include the
following explanations.
How long will it take to get the technical skill?
We may have the technology, but that doesn't mean we have the skills required to properly apply
that technology since we are taking the course of distributing system in parallel with the design
phase of this project to implement it in networking technology.
The real constraints on project deadlines
 Deliver a properly functioning information system within given time of period. Since
delivering an error-prone, useless information system on time is useless.
 Missed schedules are bad, but inadequate systems are worse.

1.13. Time Duration and Plan of Action

Table 1.1. Time Duration and Plan of Action

Nov Nov Dec Dec Dec Dec Jan

Requirement Gathering
Analysis
Design
Implementation

7
Testing
Presentation

1.14.COST
Table1.2. cost

Materials Price
Paper 170birr
Pen 20birr
Transport 500birr
Internet 500birr
Print 200birr
Total 1390birr

8
CHAPTER TWO
2. Analysis
2.1.1 Description of the current system
In ATVT starting from the establishment there is a manual Store keeping system to manage the
college resources such as stationary, furniture’s Equipment’s Aided materials Cleaning, clothing
and spare parts and etc. This resources are unwisely used, store keepers do not know expired date
of some equipment’s and cannot manage status of equipment’s in the store whether it is break or
not as well as the time it takes for head offices to order, and managing the equipment’s are very
boring for the store keepers and it also makes overload of work on administrators and head offices.
Currently, the store system of ATVT works manually. This working condition has major
drawbacks. These major drawbacks are
 Loss of Items and materials record files
 Lack of communication because of computers which is found in a college are not
networked
 Time consuming for searching the equipment’s.
 It is very tedious.
 All information is not placed separately.
 Lot of paper work.
 Slow data processing.
 Not user-friendly environment.
 Difficult to find records due to poor file management.
 Difficult to know the life service of the equipment’s

2.1.2 Business Rules

The three stores are ruled or governed by one manager and they have their own rule to govern this
system.
 Any material received registered on Stock card, by model number 19 formats.
 First if any college wants any material from them, head of college must call to the manager
of stores to check whether the material they want is available or not, if available the college

9
 head prepare three papers for request one paper present there in college one for store
manager and the other one for store keeper.
 After the store manager accept the request he/she sign on the papers then the store keepers
check whether the paper is signed by the store manager or not after check the store keeper
register the materials that are taken from them on bin card by model number 22 format.

2.2. Proposed System

2.2.1 Non-functional Requirements and Constraints
Nonfunctional (supplementary) requirements pertain to other information needed to produce the
correct system and are detailed separately. Constraints on the services or functions offered by the
system such as timing constraints, constraints on the development process, standards and etc.
 User interface: the system provides java user interfaces that are compatible with windows
platform.
 Hardware consideration:-the organization should have computers having typical storage
capacity and processing speed.
 Error handling: our system handles error by showing the message” invalid input” when
the user inters invalid input.
 Security: the system should have a security privilege that secures the system. And also
there must be a physical security that secures (especially) the server computer. That means
the server computer is only allowed for the server admin.
 Performance characteristics: the end user computer should have medium processor and
the server computer should have large processor. It’s measured by its speed of processor.
 Physical environment: The system needs good environment.
 Back up: The system should have back up using external hard disk. The backup is taken
weekly.
 Availability-The system should be available all the time

2.2.2 Functional Requirements

Functional Requirements are those that refer to the functionality of the system, i.e., what services
it will provide to the user. Statements of services the system should provide how the system should
react to particular inputs and how the system should behave in particular situations.

10
  The system would be able to register the received materials.
 The system would be able to register salvage resources.
 The system also send request from users.
 The system would be able to control expire date of equipments, materials and etc.
 The system would be able to search and update the material information when it is needed.
 The system would be able to notice for buying materials.
 Record items and materials when items and materials are received.
 Change Status of items and materials when items and materials are used.
 Receive request and reply for the request.

 The system should generate timely or year report about the allocation of resources.

 The system should store all the data related with all the tasks performed into a database.

2.2.3. Use Case Diagram

Use case describes the behavior of the system as seen from an actor’s point view. A use case
describes a function provided by the system as a set of events that yield a visible result for the
actors. In the analysis phase they represent the functionality of the system. Admin is the store
manager and users are head of colleges and other offices.

11
Figure 1: Use Case Diagram

12
2.2.4. Use case documentation

Table 2.2.4.1: Use Case description for Authentication

Use case no. 1

Use Case Name: Login/authentication/

Actor: Admin, Storekeepers and user
Scenario: Login into the system.
Precondition: Login page displayed
Flow Event: Actor
1.Actor Fill user name and password
2. Actor Click login button.
3 System Display login successful l
4 Actor Enter the page, he/she want.

Alternative condition If step 3 is not successful repeat step 1 until it is success

Exception Condition If the user name does not exist the system stop login.

Post condition Main form displayed.

13
Table2.2.4.2: Use Case description for manage account
Use case no. 2

Use Case Name: Manage account

Actor: Admin, Storekeepers and user
Scenario: Admin: create and delete
Admin, Store keepers and user: update account
Precondition: Use case no.[1] fulfill
Admin: new user must created
Store keepers and user: Admin must create new account
Flow Event: 1. Enter the page.
Admin: 1.1 Actor open create/delete account form from menu
1.2 system display account creation or deletion form
1.3 Actor fill registration form
1.4 System display account creation or deletion success
Admin ,Storekeepers and user:
2.1 Actor open their own update form
2.2 system display their respective update form
2.3 Actor fill their update form
2.4 System display update success
Alternative condition If step 1.4 is not success repeat step 1.3 until success
If step 2.4 is not success repeat step 2.3 until success
Exception Condition If account doesn’t exist in the system stops update or delete.
If there is there is account the same with which is to create stop
creating.
Post condition Account is created or deleted by Admin and updated by user,
storekeepers and admin.

14
Table2.2.4.3: Use Case description for manage request
Use case no. 3

Use Case Name: Manage request

Actor: Admin, Storekeepers and user
Scenario: Admin: Approve request
Admin, Store keepers and user: send request
Precondition: Use case no.[1] fulfill
Admin: new request must sent from user
user: wanted some materials
Store keepers: must given materials for user
Flow Event: 1. Enter the page.
User: 1.1 Actor open send request form from menu
1.2 system display request form
1.3 Actor fill request form
1.4 System display request sent success
Admin:
2.0 Actor open Approve or disapprove request form
2.1 system display Approve or disapprove request form
2.2 Actor Approve or disapprove request
2.3 System display Approve or disapprove success
Store keeper:
3.0 Actor open reply approve form
3.1 system display reply approve form
3.2 Actor reply approve to admin
3.3 System display reply approve success
Alternative Condition If step 1.4 is not success repeat step 1.3 until success
Exception Condition If the user name does not exist the system stop login.
Post condition Request has been sent to admin from user, admin has been
approving requests and storekeepers reply approved request to
admin.

15
Table2.2.4.4: Use Case description for Manage report
Use case no. 4

Use Case Name: Manage report

Actor: Admin and Storekeepers
Scenario: generate report
Precondition: Use case no.[1] fulfill
Store keepers: must register materials and user receive materials
Flow Event: 1. Enter the page.
Admin and Storekeepers:
1.1 Actor open generate report form from menu
1.2 system display generate report form
1.3 Actor click generate report form
1.4 System display generate report success
Exception Condition If registered materials and user receive materials does not exist the
system stops generating report.
Post condition Report is generated

Table2.2.4.5: Use Case description for Notice handling

Use case no. 5

Use Case Name: Notice handling

Actor: Admin
Scenario: Post notice
Precondition: Use case no.[1] fulfill
Materials are wanted to bought

16
Flow Event: 1. Enter the page.
Admin:
1.1 Actor open Notice handling form from menu
1.2 system display Notice handling form
1.3 Actor select one of Notice handling form
1.4 System display Post, delete or update notice success
Alternative Condition If condition 1.4 is not success repeat step 3.1 until success
Exception Condition If there is no materials to bought.
If there is no update or delete form to change or delete.

Post condition Notice is posted

Table2.2.4.6: Use Case description for Manage stock and bin card
Use case no. 6

Use Case Name: Manage stock and bin card

Actor: Storekeepers
Scenario: Register received materials on stock and distributed materials on
bin card
Precondition: Use case no.[1] fulfill
There must received materials
Flow Event: 1. Enter the page.
Store keepers:
1.1 Actor open stock card/bin card form from menu
1.2 system display stock card/ bin card form
1.3 Actor fill stock card/bin card form
1.4 System display stock card/bin card success

Alternative condition If step 4.1 is not success repeat step 1.3 until success
Exception Condition If received or distributed materials does not exist the system pause
stock card/bin card form.
Post condition Stock card/bin card is successfully registered.

17
Table2.2.4.7: Use Case description for Check availability
Use case no. 7

Use Case Name: Check availability

Actor: user
Scenario: Check availability of materials
Precondition: There must received materials or managed request
Flow Event:
Admin. storekeepers and User :
1.1 Actor login store management site and open materials
availability form.
1.2 system display received materials
1.3 Actor fill Check availability form
1.4 System display Check availability
Alternative condition If condition 4.1 is not success repeat step 1.3 until success
Exception Condition If received materials does not exist the system pause Check
availability form.
Post condition Check availability is done.

Table2.2.4.8: Use Case description for Register Salvage

Use case no. 8

Use Case Name: Register Salvage

Actor: Storekeepers
Scenario: Register Salvage materials
Precondition: Use case no.[1] fulfill
user return materials after they use

18
 Flow Event: 1. Enter the page.
1.1 Actor open Register Salvage form from menu
1.2 system display Register Salvage form
1.3 Actor fill Register Salvage form
1.4 System display Register Salvage success

Exception Condition If returned materials does not exist the system pause Register
Salvage form
Post condition Salvage materials Registered

2.2.5. Sequence Diagram

Sequence diagram: an "interaction diagram" that models a single scenario executing in the
system.
Key parts of a sequence diagram
 Participant
 Message

The axes in a sequence diagram.

Figure 2.2.5.2 Sequence diagram for manage account

19
Figure 2.2.5.3 Sequence diagram for manage request

Figure 2.2.5.4 Sequence diagram for Generate report

20
 Figure 2.2.5.5 Sequence diagram for notice handling

Figure 2.2.5.6 Sequence diagram for manage stock and bin card

21
 Figure2.2.5.7 Sequence diagram for check material availability

2.2.6 State Chart Diagram

A state chart diagram is a UML diagram that provides a graphical view of a State Machine, the
public behavior of a classifier (component or class), in the form of the changes over time of the
state of the classifier and of the events that permit the transition from one state to another.

Figure 2.2.6.1 State chart diagram for login

22
Figure 2.2.6.2 State chart diagram for manage account

Figure 2.2.6.3 State chart diagram for manage request

23
Figure 2.2.6.4 State chart diagram for manage report

Figure 2.2.6.5 State chart diagram for notice handling

24
Figure 2.2.6.6 State chart diagram for manage stock and bin card

Figure 2.2.6.7 State chart diagram for checking material availability

25
2.2.7 Activity Diagram
The activities represent the execution of a set of operations.

Figure 2.2.7.2 Activity diagram for Manage account

Figure 2.2.7.1 Activity diagram for login

26
Figure 2.2.7.3 Activity diagram for Manage request

Figure 2.2.7.4 Activity diagram for Manage report

27
Figure 2.2.7.5 Activity diagram for Notice handling

Figure 2.2.7.6 Activity diagram for Manage stock and bin card

28
Figure 2.2.7.7 Activity diagram for check availability

2.2.8. CRC Analysis

A Class Responsibility Collaborator (CRC) model is a collection of standard index cards that
have been divided into three sections. A class represents a collection of similar objects, a
responsibility is something that a class knows or does, and a collaborator is another class that a
class interacts with to fulfill its responsibilities. Collaboration diagrams represent interactions
between objects as a series of sequenced messages. Collaboration diagrams describe both the
static structure and the dynamic behavior of a system.
• responsibility: knowledge class maintains or service class provides

• collaborator: a class whose knowledge or services are needed to fulfill a responsibility

29
Table 2.2.8.1: Authentication Table 2.2.8.2: Manage report

Manage report
responsibility Collaboration
Store id Manage request
Material type Notice handling
Material
quantity

Authentication
Responsibility Collaboration
User name Manage account
Password Manage request
Manage report
Notice handling
Manage stock and Bin
card

Table 2.2.8.3: Manage account Table 2.2.8.4: Manage stock and bin card
Manage account
Responsibility Collaboration
User name Manage request
Password Manage report
Notice handling
Manage stock and Bin
card

Table 2.2.8.5: Manage request

30
 Manage stock and bin card
responsibility Collaboration
Material name Manage request
Material type Manage report
Manage request Material Notice handling
Responsibility Collaboration quantity
Request type Manage report
User name Notice handling

2.2.9. Conceptual Modeling: Class

Diagram
A class diagram describes the types of objects in the system and the various kinds of static
relationships that exist among them.
Essential Elements of a UML Class Diagram are Class, Attributes and Operation

1…*
Create, update and delete acct
1…*
Authentication
PostNotice -UserName : string
-NoticeId : string -password : string
-Date : string 1 +getUserName()
-Title : string 1 +getPassword()
Admin 1
-Notice : string Create,update, delete acc
+PostNotice() 1
+PostNotice()
1 1
+UpdateNotice()
+DeleteNotice() +ApproveRequest()
1 +MangeAccount() uses

Approve, disapprove request

uses uses

Update account
1…*
1
StoreKeepers Register salvages 1
Request Uses, Send request
1
-MaterialName : string Salvage
1…* 1
-MaterialModel : string +UpdateAccount()
-MaterialQty : string +SendRequest() -MaterialName : string
-Users : string +RegisterSalvage()
1 -MaterialModel : string
+RegisterBin() -materialQty : string
+SendRequest() 1 +RegisterStock() -ProductId : string
+ApproveRequest()
-ReturnFrom : string
+RegisterSalvage()
1…*

Register StockCard Register Bin card uses

Update account
Send, update request
1

StockCard 1 User 1 1
+MaterialName : string
+MaterialModel : string uses +UpdateAccount() BinCard
-MaterialQuantity : string +SendRequest() +MaterialName : string
-ProductlId : string +MaterialType : string
-PDate : string -MaterialQuantity : string
-ExpiredDate : string -ProductlId : string
-SupplierName : string Send and update -IssuedDate : string
-DeliveryDate : string -UserName : string
request
-IssuedDate : string +RegisterStock()
-UserName : string +RegisterBin()
-UnitPrice : string
+RegisterStock()

31
Figure 2.2.9. Conceptual modeling: Class diagram

2.2.10. User Interface Prototyping

User interface prototyping is an excellent means of generating ideas about how the GUI can be
designed and it helps to evaluate quality of solution at early stage. Although our system has may
interfaces, we have tried to show some of the interfaces based on the user logged-in to the system.

Figure 2.2.10.1 User Interface for Login Figure 2.2.10.2 Admin Interface for manage report.

32
Figure 2.2.10.3 User Interface for Post notice. Figure 2.2.10.4 Admin Interface for manage report

Figure 2.2.10.5. User Interface for Manage account.

Figure 2.2.10.6 User Interface for Approved request

33
Figure 2.2.10.7 User Interface to send request.

Figure 2.2.10.8 User Interface for Update Request.

34
Figure 2.2.10.9 User Interface for Storekeepers to Register Stock

Figure 2.2.10.10 User Interface for Storekeepers to Register Bin

35
Figure 2.2.10.11 User Interface for Storekeepers to Report Stock

Figure 2.2.10.12 User Interface for Storekeepers to Report Bin.

36
Figure 2.2.10.13 User Interface for Storekeepers to Update Stock

Figure 2.2.10.14 User Interface for Storekeepers to update Account

37
Figure2.2.10.15 User Interface for Storekeepers to Approve /Disapprove Request

38
CHAPTER THREE
3. SYSTEM DESIGN

3.1. Introduction
Design is process of describing, organizing, and structuring system components at architectural
design level and detailed design level. Design converts functional models from analysis into
models that represent the solution. Design may use structured or Object oriented approaches.

3.2 Purpose and Goals of Design

The design part is very important so as to make the implementation very easy. The different types
of the system modeling techniques that are used for the implementation of the system such as
deployment and component modeling are show in detail. Not only the system modeling techniques
but also some system design techniques such as system decomposition design are cover in detail
in this phase. The non-functional requirement is the description of the feature characters and
attributes of the system.

Some of the design goals are:-

 Security- The system is secured that unauthorized user cannot access the data that does
not concern with them as well as ability to withstand malicious attacks.
 Reliability- The system has the ability to perform its required functions under stated
conditions.
 Fault Tolerance-The system should be able to give response (Error Message) when
the user enter incorrect input. This recommends the user to enter correct input.
Throughput: Since ATVT has desktop application. It is able to perform many tasks in
fixed period of time. Different service center do different tasks in their working time
without worrying the other service center are using the same system.
 Robustness: The system has the ability to survive wrong user’s inputs it didn’t accept it
instead it show error message and continue to enter correct input.
 Modifiability: If there is any change to the system or fault it can be modified easily.

39
  Usability: ATVT store management provide easy user friendly interface for users of the
systems. It also provides help menu which gives brief description how to use the system so
that user can be able to use it easily.
 Memory: ATVT store management requires the following space to run the system.
Desktop or laptop computers and web server computers having more than 1GB of RAM
and high storage capacity and processing speed.

3.3. Proposed Software Architecture

After identifying the problems of the current system of the current resident file handling system
and decentralization administrative system, the aim of proposed is to develop an automated
which will resolve the problems of the current system. The new system has connection
stability. The system has centralized database.

3.3.1 Subsystem Decomposition

A subsystem is characterized by the services it provides to other subsystems. A service is a set of

related operations that share a common purpose. A sub system provides a notification service.
Interface subsystem:-The direction where to where the user wants to go is decided by the
interface. In our system the user interface has many going directions through the interface that the
system have.
Store management Admin- In this subsystem manages all information, give the service, control
materials and fulfill infrastructure when needed.
Store keepers: Manage stock and bin card.

40
Users:-send requests if they want material from them.

UserInterface

Storekeepe Users
rs Admin

ManageOverAl Requesting
ManageStockAnd
BinCard lActivity

Figure3.3.1 Subsystem decomposition

3.4. Component Diagram

Component diagrams show the structure of the software system, which describes the software
components, their interfaces, and their dependencies. We use component diagrams to model
software systems of our project at a high level or to show components at a lower, package level.

Component diagram supports component-based development in which a software system is

divided into components and interfaces that are reusable and replaceable.

Component diagrams are useful for the following reasons:

 Defining the executable and reusable aspects of a software system.
 Revealing software configuration issues through dependency relationships.
 Showing an accurate depiction of a software application before you make changes or
enhancements.

41
 Web browser

<<GUI>>

Business Logic
JSS ATVET

Derby rar Persistence

JDBC

SQL <<Database>>

Figure 3.4 component diagram

3.5 Deployment Diagram

It shows how the system is deployed on computers. In other words, it shows which component of
the software is installed on which machine and how they communicate with each other if they are
on different machines.

42
Client Browser Application Data Base Server

TCP/IP
ODBC

Admin Manage request

Generate report
Data Base

Storekeepers

Notice handling

Users

Manage stock and Bin card

Figure 3.5 Deployment Diagram

3.6 Persistence Modeling for Object Oriented Database

If you use object oriented databases for your system instead of relational databases, instead of
designing E-R diagram, design persistence models. Show the mappings and the relations of the
E-R diagram given below.

Table 3.6 Persistence Modeling for object oriented database

43
44
3.7 Access Control and Security
The access control and security specifies what the user can access or what the user can do. This
access control is verified by user name and password. The following table shows the access
control of our system.
Table 3.8 Access control and secure
Functionalities
Manage Mange Manage Notice Manage Check
account request report handling Stock availability
Actors And bin card

Admin Have permission to Approve Generate Post Check

Create, update and requests and update or availability of
delete account update delete material to
report posts approve
request
Storekeepers Update their Send Generate Register Check
account request to report received availability of
admin materials and material to
issued issue
materials materials
Users Update their Send or Check
account update availability of
request material to
send request

45
3.8 Reference
1. Scott W.Ambler, The object primer Agile Model-Driven Development with UML, Cambridge
University, ronin international, inc, 3rd edition, 2004
2. http://www.dba-oracle.com/t_object_database_model.htm (Oracle Tips by Burleson
Consulting) Assessed on 12/11/2017 G.c
3. http://www.au.edu.et. Assessed on 20/11/2017 G.c
4. http://www.agilemodeling.com/artifacts/deploymentDiagram.htm Assessed on 20/11/2017 G.c
5. http://www.agilemodeling.com/artifacts/classDiagram.htm Assessed on 18/12/2017 G.c

46