Property Management System

Haramaya University
College of Computing and Informatics

Department of Computer Science
Haramaya University Property Management System

Requirement Analysis and System Design Document
Group MembersID Number
1. Mikias Tilahun-------------------------1731/06
2. Shemsu Kedir--------------------------1733/06
3. Abebaw Sete ---------------------------1671/06
4. Meaza Lema ----------------------------1715/06
5. Nebila Mohamed-----------------------1727/06
Advisor: Dr. Feizur R.
February, 2017
Haramaya University Property Management System 2009
Acknowledgements
First and foremost, we would like to thank the almighty God who helps us to accomplish this
project documentation. Secondly, we are highly grateful for our advisor Dr. Feizur Reshid who
assists us in each and every aspect of our project documentation by being beside us. Thirdly, we
would like to show our deepest gratitude for Haramaya University property manager
andstakeholdersfor their kindly support. And finally, we would like thank forall people who
helped us and giving us some supportive ideas concerning our project documentation.
Department of Computer Science Page i

List of Abbreviation
MySQL: My Structured Query Language
CSS: Cascading Style Sheet
OS: Operating System
HTML: Hyper Text Mark-up Language
HUPMS: Haramaya University Property Management System
ADMIN: Administrator
UML- Unified Modeling Language
CPU: Central Processing Unit
RAM: Random Access Memory
UCI: Use Case Identification
IEAM: Imperial College of Agricultural and Mechanical Arts
XAMPP: Cross-Platform Apache MariaDB PHP and Perl
PK: Primary Key
FK: Foreign Key
Department of Computer Science Page ii

Table of Contents
Chapter One .................................................................................................................................... 1
Introduction ................................................................................................................................. 1
1.1 Background of the organization ................................................................................... 2
1.2 Review of Related Work (Literature Review) .............................................................. 3
1.3. Statement of the problem ................................................................................................. 3
1.4 Objective ........................................................................................................................... 3
1.4.1 General Objective ...................................................................................................... 3
1.4.2 Specific Objective ...................................................................................................... 4
1.5 Methodology ..................................................................................................................... 4
1.5.1 Data Collection Methodology .................................................................................... 4
1.5.2 System Development Methodology........................................................................... 5
1.5.3 System Development Tool ......................................................................................... 5
1.6 Scope and Limitation ........................................................................................................ 6
1.6.1 Scope .......................................................................................................................... 6
1.6.2 Limitation ................................................................................................................... 6
1.7 Significance of the project ................................................................................................ 6
1.8 Work break down .............................................................................................................. 7
Chapter Two.................................................................................................................................... 8
System Requirement and Specification ...................................................................................... 8
2.1 Existing System ................................................................................................................ 8
2.2 Proposed System ............................................................................................................... 9
2.2.1 Overview .................................................................................................................... 9
2.2.2 Functional Requirement ............................................................................................. 9
2.2.3 Non Functional Requirement ................................................................................... 10
2.3 Feasibility Study ......................................................................................................... 11
Chapter Three................................................................................................................................ 12
System Model ........................................................................................................................... 12
3.1 Use Case Model .............................................................................................................. 12
3.2 Class diagram .................................................................................................................. 28
Department of Computer Science Page iii

3.3 Dynamic Model .............................................................................................................. 30
3.3.1 Sequence diagram .................................................................................................... 31
3.3.2 Activity diagram ...................................................................................................... 46
3.3.3 State chart diagram .................................................................................................. 61
3.4 Data dictionary ................................................................................................................ 76
3.5 User interface navigational paths and screen mock-ups ................................................. 79
Chapter 4 ....................................................................................................................................... 83
System Design .......................................................................................................................... 83
4.1 Introduction ..................................................................................................................... 83
4.1.1 Overview of system design ...................................................................................... 83
4.1.2 Design goal of the property management system .................................................... 84
4.2 System decomposition with services .............................................................................. 85
4.3 Current Software Architecture ........................................................................................ 87
4.4. Proposed Software Architecture .................................................................................... 88
4.5 Hardware/Software Mapping .......................................................................................... 89
4.6 Persistent data management .......................................................................................... 90
4.7 Access control and Security ............................................................................................ 91
4.8 Global control flow ......................................................................................................... 93
4.9 Boundary Condition ........................................................................................................ 94
Reference ...................................................................................................................................... 95
Department of Computer Science Page iv

List of Tables
Table 1: work break down .............................................................................................................. 7
Table 2: login use case description ............................................................................................... 17
Table 3: manage accounts use case description ............................................................................ 18
Table 4: Register Stock use case description ................................................................................ 19
Table 5: Update Stock use case description .................................................................................. 20
Table 6: View request use case description .................................................................................. 20
Table 7: Approve request use case description ............................................................................. 21
Table 8: View available asset use case description ...................................................................... 22
Table 9: Request asset use case description .................................................................................. 23
Table 10: View approved request use case description ................................................................ 23
Table 11: Calculate deprecation use case description................................................................... 24
Table 12: Transfer the asset use case description ......................................................................... 25
Table 13: Register return asset use case description ..................................................................... 25
Table 14: Register asset use case description. .............................................................................. 26
Table 15: Update asset use case description. ................................................................................ 26
Table 16:Modify accountusecasedescription. ............................................................................... 27
Table 17: Generate report use case description ............................................................................ 28
Table 17: data dictionary for user registration .............................................................................. 76
Table 18: data dictionary for Store man registration .................................................................... 76
Table 19: data dictionary for Stock manager registration ............................................................. 77
Table 20: data dictionary for Transfer asset ................................................................................. 77
Table 21: data dictionary for Account .......................................................................................... 77
Table 22: data dictionary for Request asset .................................................................................. 78
Table 23: data dictionary for Return asset registration ................................................................. 78
Table 24: data dictionary for item ..................................................Error! Bookmark not defined.
Table 25: data dictionary for Asset registration ............................................................................ 78
Table 26: data dictionary for Stock registration ........................................................................... 78
Table 27: Access control flow ...................................................................................................... 93
Table: 28 Global control flows ..................................................................................................... 94
Table: 29 Boundary condition for start up the system .................................................................. 95
Table: 30 Boundary condition for Shutdown the system.............................................................. 95
Department of Computer Science Page v

List of figures
Figure 3.2.1 Class diagram ........................................................................................................... 29

Figure 3.3.1.1: Login sequence diagram ....................................................................................... 31
Figure 3.3.1.3: Sequence Diagram for Register Stock.................................................................. 33
Figure 3.3.1.4: Sequence Diagram for Remove Account ............................................................ 34
Figure 3.3.1.5: Sequence Diagram for View Request .................................................................. 35
Figure 3.3.1.6: Sequence Diagram for Approve Request ............................................................. 36
Figure 3.3.1.7: Sequence Diagram for View available asset ........................................................ 37
Figure 3.3.1.8: Sequence Diagram for request asset ..................................................................... 38
Figure 3.3.1.9: Sequence Diagram for View approved request .................................................... 39
Figure 3.3.1.10: Sequence Diagram for Depreciation .................................................................. 40
Figure 3.3.1.11: Sequence Diagram for Transfer Asset................................................................ 41
Figure 3.3.1.12: Sequence Diagram for Register returned asset................................................... 42
Figure 3.3.1.13: Sequence Diagram for Register Asset ................................................................ 43
Figure 3.3.1.14: Sequence Diagram for Modify account.............................................................. 44
Figure 3.3.1.15: Sequence Diagram for Generate Report ............................................................. 45
Figure 3.3.2.1 Activity Diagram for Login ................................................................................... 46
Figure 3.3.2.2: Activity Diagram for Create account ................................................................... 47
Figure 3.3.2.3: Activity Diagram for Register Stock .................................................................... 48
Figure 3.3.2.4: Activity Diagram for Update Stock...................................................................... 49
Figure 3.3.2.5: Activity diagram for View request ....................................................................... 50
Figure 3.3.2.6: Activity Diagram for Approve Request ............................................................... 51
Figure 3.3.2.7: Activity Diagram for View available asset .......................................................... 52
Figure 3.3.2.8 Activity Diagram for Request asset ....................................................................... 53
Figure 3.3.2.9 Activity Diagram for View approved request ....................................................... 54
Figure 3.3.2.10 Activity Diagram for Calculate deprecation........................................................ 55
Figure 3.3.2.11: Activity Diagram for Transfer the asset ............................................................. 56
Figure 3.3.2.12: Activity Diagram for Register asset ................................................................... 57
Figure 3.3.2.13: Activity Diagram for Register returned asset ..................................................... 58
Figure 3.3.2.14: Activity Diagram for Modify account ................................................................ 59
Figure 3.3.2.15: Activity Diagram for Generate report ................................................................ 60
Figure 3.3.3.2 State chart Diagram for Create account................................................................. 62
Figure 3.3.3.3 State chart Diagram for Register Stock ................................................................. 63
Figure 3.3.3.4 State chart Diagram for Update Stock ................................................................... 64
Figure 3.3.3.5 State chart Diagram for View request ................................................................... 65
Figure 3.3.3.6 State chart Diagram for Approve request .............................................................. 66
Figure 3.3.3.7 State chart Diagram for View available asset in store ........................................... 67
Figure 3.3.3.8 State chart Diagram for Request asset ................................................................... 68
Figure 3.3.3.9 State Chart Diagram for View approved request .................................................. 69
Department of Computer Science Page vi

Figure 3.3.3.10 State Chart Diagram for calculate depreciation................................................... 70
Figure 3.3.3.11 State Chart Diagram for Transfer Asset .............................................................. 71
Figure 3.3.3.13 State Chart Diagram for Register returned Asset ................................................ 73
Figure 3.3.3.14 State chart diagram for Modify account .............................................................. 74
Figure 3.3.3.15 State chart diagram for Generate Report ............................................................. 75
Figure 3.5.1 user intrerface navigational path .............................................................................. 79
Figure 3.5.2 Login screen muck-up .............................................................................................. 80
Figure 3.5.3 Register asset screen muck-up.................................................................................. 81
Figure 3.5.4 Create account screen muck-up ................................................................................ 82
Figure 4.2.1: Deployment Diagram .............................................................................................. 85
Figure 4.5.1: Hardware/Software mapping ................................................................................... 89
Figure: 4.6.1 persistent data management..................................................................................... 91
Department of Computer Science Page vii

Chapter One
Introduction
Property management is a key component in an efficient, professionally administered business. It
supports the educational, research and administrative missions of the University.Online property
management basically contains most of the business method that renovate to the internet. It is the
management of property using online tools. When online property management implemented, it
make many things like managing properties and contact with clients more easy and efficient.
Here, in the higher educational institution it is observed that there are problems of protecting
their data from external agent, putting their data in a database. By considering these problems,
we see the property management system of Haramaya University and we are intended to solve
the problem with today’s technologies to make the problem solved well. Property management
system at Haramaya University is afundamental process supported by all College and
departments. Effective and efficient management of equipment and materials help to make sure
the university activities are performed in accordance with the policies and procedures.
Generally, at Haramaya University, each university employee has a general obligation to

safeguard and make appropriate use of property owned by or accountable to the university. The
various department heads are vested with the ultimate responsibility for all inventories within
their departments. Property Management, a subset of university business services, is a support
service to the department to assure that accurate records and proper control of property are
maintained. Ultimately, the haramaya university system has title and ownership of all university
property. Actual possession, use, and accountability are maintained on the department level.
Department of Computer Science Page 1

1.1 Background of the organization
Haramaya University has gone through a series of transformations since its establishment as a
higher learning institution. The agreement signed between the Imperial Ethiopian Government
and the Government of the United States of America on May 15, 1952 laid the foundations for
the establishment of Jimma Agricultural and Technical School and the Imperial College of
Agricultural and Mechanical Arts (IECAMA). The Agreement between the Government of
Ethiopia and the Technical Cooperation Administration of the Government of the United States
of America, signed on May 16, 1952, gave the mandate to Oklahoma State University to
establish and operate the College, conduct a nationwide system of Agricultural Extension and set
up an agricultural research and experimental station. Based on the Emperor’s wish, it was
decided to establish the College at its current location at Haramaya. Later on, the agreement
signed between the United States Department of States and the Imperial Government provided
the basis for the operation of Jimma Agricultural and Technical School that received its first
class of eighty students in October 1952. Out of this numbers, nineteen of them graduated on
August 6, 1953 and became the first freshman students of the Imperial Ethiopian College of
Agricultural and Mechanical Arts (IECAMA). The IECAMA opened its doors to its first batch of
students in October 1956 and the senior class moved from Addis Ababa to Alemaya for their
final semester. At the end of the 1956/57 academic year, eleven students completed their studies
and graduated with a B.Sc. degree in General Agriculture. The training programs in Agriculture
were further specialized and B.Sc. programs were introduced in Animal Sciences (1960), Plant
Sciences (1960), Agricultural Engineering (1961) and Agricultural Economics (1962).
In this University there are different management activities were performed. Among those the
property management department manages all moveable capital equipment located on each
campus of Haramaya university and numerous of campus sites.The Department identifies,
locates, and photographs each piece of equipment. This information entered into the manual
property system and the records maintained throughout the equipment’s life cycle. In this process
there is a problem associated with the manual Property Management. Due to this we were
initiated for this project to identify and analyze those problems and to develop web based system.

1.2 Review of Related Work (Literature Review)
Property management at Stanford University is an integral process supported by all departments.

Effective and efficient management of equipment and materials, throughout their life cycle, help
ensure university activities are performed in accordance with its policies, procedures and sponsor
requirements. The property management system is comprised of policies, procedures, online
systems, and people, which support the overall educational, research, and administrative
missions of the University.
1.3. Statement of the problem

Haramaya University has not used property management system before. Currently, the
University uses manually manage materials, which is necessary for the University. We have tried
to investigate this manual system and identified the following problems:
 The manual system requires a long time to distribute information for stakeholders.
 Record files of materials may lose if the hard copies document is destroying.
 The store properties are not visible and known for all stakeholders and staff workers.
 The manager takes long time and complicated to report information to higher officials.
 It’s difficult to get information from the previous document.
 The work is complicated for specifying type, cost, and quantity of properties. Because of
space consuming, man power and needs a lot of paper. If the information is failed it needs
additional time, labor, and paper for updating that previous information.
1.4 Objective
1.4.1 General Objective
The main objective of this project is to develop a web based property management system for
Haramaya University.

1.4.2 Specific Objective

In order to achieve the general objective we must use the following specific objectives.
 To develop user friendly interface.

 To study, analyze and transmit into automatic system
 To identifying the problem that exist in the current system
 To keep the overall records associated with property into permanent database
 To minimize the work load of the employees
 To solve data security problem
 To minimize unnecessary expense for recording data
 To make management flexibility
 To make the system available
 To perform task seamlessly
1.5 Methodology
1.5.1 Data Collection Methodology
We used interview, observation and previous documents to collect data that are necessary to
develop the proposed system.
Interview
We had a continuous contact with the Property Manager of Haramaya University and other staff
members under him in order to make interview with them. Accordingly, our questions were
appropriately answered.
Observation
We observed the current working system of property management of manual system and we
mark the drawbacks that our system is going to solve.
Previous documents
We were continuously glancing, understanding and reviewing the previous documents of the
property management of Haramaya University to identify the problems that the project is going
to solve.

1.5.2 System Development Methodology

We are going to use waterfall model system for development methodology to develop the new
system. While we are developing the system, we found that our project is suitable to follow a
strict path through the development process not moving on to the next phase until the previous
stage has been completed. This is the reason why we choose waterfall model system
development methodology.
1.5.3 System Development Tool

Notepad++:- this software it will be used to develop our projectimplementation (code) phase.
Microsoft Office: - office is mandatory software to organize our project documentation and
system design.
Database Mysql: -it will be used our computer as a server and store data on database.
Visio Professional: - Visio software used to design UML diagram such as class, use case,
sequence and other diagrams.
Browser: - we can view screenshots of our application as it displays different browsers, with a
great degree of customization.
Xamp Server: it will be used for running server side scripting language.
Operating System:-we use windows operating system for our project.

1.6 Scope and Limitation

1.6.1 Scope
Currently in Haramaya University property management system performs its basic tasks
manually. The scope of this project is to develop and implement a new web based property
management system which will avoid the problems associated with the manual processing.
The proposed system includes:-
 To record new stock to system

 To record asset
 To transfer asset from user to user
 To record return asset
 Calculate depreciation
 To view relevant information
 Updating asset information
1.6.2 Limitation
The proposed system has limitations which are not able to solve. Includes:
 Purchasing property is not included because the payment is not applicable.
 Generally, the other thing which is not specified in the scope is the limitation of the
project.
1.7 Significance of the project
The project gives many benefits to Haramaya University administrators as well the employer that
participates in property management. From those benefit the following are common
 Reduce the amount of resources that are wasted.

 Reliable user validation and checking.
 Keeping information safely
 Reduce the workload for the employer
 Manage the property easy

 Access information’s in fast way.
 Increase accuracy and availability.
 Increase the speed to perform activities.
1.8 Work break down
Month
Chapters Activity Until Dec Dec Dec Jan Jan Feb Feb Feb
Nov 01-13 14- 27- 21- 29- 03 03-06 07-08
30 26 Jan20 28 Feb02
Data collection
Chapter Introduction
one
Submit draft
document
Chapter System Requirement
two And Specification
Submit Draft
document
Chapter System Modeling
three
Submit Draft
document
Chapter System Design
four
Submit Draft
document
Finalizing Final Document
Review With Our
Advisor
Final Document
Submission to The
Department
Preparing Slide For
Presentation
Presentation
Table 1: work break down

Chapter Two
System Requirement and Specification
Requirement analysis is a process used by system analyst to analyze and identify the system
problems and solutions requirement provide by the users of the system. Requirement analysis is
done in order to acquire a complete and in depth knowledge of the business system. It helps for
as to split complex requirements into smaller units that can be clearly defined and reviewed.
2.1 Existing System

The current system of Haramaya university property management is manual. This manual system
needs more man power to perform its all activities i.e. for searching available materials e.tc. In
the property administration everything is done manually due to lack of computerized system.
In the existing manual property administration, materials are divided into two as Fixed Asset and
Non-Fixed Asset. Each of them is recorded separately.
1. Fixed Asset property for example: Book shelf, Computer system, etc.
2. Non-Fixed Asset for example: pen, paper, printer ink etc.
The forms that the current manual system uses include the following forms.
 Fixed Asset Users Control Card
 Stock record card
 Property transfer form
 Model 19(Receipt for articles or property received)
 Model 22(Receipt for articles of property issued)
 Fixed Assets Register Card
 Fixed Requisition Form
 None Fixed Asset Requisition Form
All the forms share almost the same attributes. These attributes include item name, item code,
quantity, measurement, assumption price, actual price, total price, and item description,
requested item quantity, and permitted item quantity.

2.2 Proposed System
2.2.1 Overview
The proposed system is to design and implement web based property management system for
Haramaya University. The proposed system will be distributed web based application in which
the property record is stored in the central database then all stakeholders of the Haramaya
University will have access to this central database to record, update, and retrieve required data
and information depending on their privilege. English language is going to be used to make the
Graphical user interface in order to accesses the system easily and user friendly. As a result, the
proposed system will become well-built in providing services to the staff workers and
stakeholders. This makes modern web based management system for the Haramaya University
property management.
2.2.2 Functional Requirement

Functional requirement is the requirement what the system should do.
Functional Requirement id1:
 The system should able to allow the users to login from any place.
 The system should able to register, search and update every detail of equipment's before
they are stocked in and stock out.
 The system should able to allow the users torequest the item.
 The systemshould able to allow the administrator to view the available asset in store.

 The systemshould able to allow the administrator to view the request and approve or cancel it.
 The system should able to register, search and update assets of the university.
 The system should able to allow the administrator to manage accounts.
 The system should able to allow the administrator to transfer asset from user to user.
 The system should able to calculate depreciation of the booked assets.
 The system should able to register returned asset from user.
 The system should able to generate report for every module on the system.
2.2.3 Non Functional Requirement

It is a requirement how the system should that related to software quality.A Non-Functional
Requirement is usually some form of constraint or restriction that must be considered when
designing the solution. Such as:
 User interface: the system should have to provide interactive and easily manageable
user interface for users.

 Accuracy: mean that we can get right information at right time.
 Security: the system has to be well protected from unauthorized access.
 Availability: The system should have to be functional at any given time.
 Performance: the system should have to perform in a proper way without any problem.
 Maintainability: The system should have to be developed for easy maintenance and
future expansions. The system has to be easily understandable for the users and have to
be easy for maintenance.
2.3 Feasibility Study

In feasibility study, it is crucial to make decision on how beneficial or practical the developing
system is. Before we are going to develop the system, first we should have to clearly notify the
feasibility of the system thatis going to implement.
Economic feasibility
In economic feasibility, should notify that Haramaya University will be profitable by the
proposed system. Small amount of budget is going to be used to build the proposed system.
Economically, the system will profit the organization by providing a better means of recording
and managing property of Haramaya University. So, Haramaya University as an organization
gives better service to Haramaya University community by using the proposed system.
Technical feasibility
When we evaluate the hardware’s and software’s requirement and how they meet the need of the
proposed system, the projected system is technically feasible because we are using currently
available and affordable technologies to develop the proposed system.
Operational feasibility
The proposed system is going to solve the problems, take advantage of the opportunities
identified during scope definition and to satisfy the requirements specified in the requirement
specification. So, the proposed system is operationally feasible

Chapter Three
System Model
This chapter deals about the modeling techniques of proposed system by using use case
diagrams, use case description, class diagram, object model and dynamic model (sequence
diagrams, activity diagrams, collaboration diagram, state chart diagramandcomponent diagram).
After identifying the actors and the use case of our new system, the use cases are developed and
textual descriptions are depicted based on the use case. Next to this the sequence diagram will be
depicted based on the use cases which are developed for the newly proposed system. Activities
will be represented by activity diagram.
3.1 Use Case Model

Use case diagrams are created to visualize interaction of our system with external world. Also a
use case model is the representation of the system intended functions and its environment. To
draw use case diagram for the system it is important to identify the actors or players of the
system and use case names used in the system.
So according to our projects the actors in the proposed system are:
 Administrator: the administrator is the one who is able to allow transferring asset from
user to user, viewing request, viewing available asset in store, approving request,
canceling request and managing accounts.
 Stock Manager:the stock manager is the one who is able to record, search and update
stock before stock in and stock out.
 Store Man: the store keeper is the one who is allowed to do operations like view
approved asset and register asset.
 User: users mainly employees, is the one who able request item.

Use case identification
Each Use Case describes the functionality to be built in the proposed system, which can
include another Use Case's functionality or extend another Use Case with its own behavior. The
most important and basic use cases of this system are the following:-
 Login
 Create account
 Remove account
 Modify account
 Request asset
 View request
 Approve request
 Cancel request
 View approved request
 Record stock
 Search stock
 Update stock
 View stock
 View available asset in store
 Register asset
 Search asset
 Update asset
 Transfer asset
 Register return asset
 Calculate depreciation
 Generate Report

Login
Manage account use
use Manage stock
Manage request use
use View stock

StockManager
Transfer asset use
Admin
Generate report use '
View approved
request
use use
View available
asset in store
use Manage asset
use
Modify account
Register return
use
asset
StoreMan
User
Request asset use
Use
Calculate
depreciation
Figure 3.1.1: Use Case diagram

Manage account use case detail
This use case describes the components of manage account which enables the administrator to
create account and removeaccount for the user as well as stakeholders.
Create Account
Manage account
Remove Account
Administrator
Manage request use case detail
This use case describes the components of manage request which enables the administrator to
view request and approve or cancel request.
View request
Approve request
Manage request
Cancel request
Administrator

Manage stock use case detail
This use case describes the components of manage stock which enables the stock manager to
register, search and update stock.
Register stock
Search stock
Manage stock
Update stock
StockManager
Manage asset use case detail
This use case describes the components of manage asset which enables the store man to register,
search and update stock.
Register asset
Search asset
Manage asset
Update asset
StoreMan
Use case Description
Use case description explains in detail the general flow of use case diagrams. Each table contains
the use case name, use case ID, the actor that initiates and interacts with the use case, and flow of
event that show the interaction between the actor and the use case which enable the user to easily
understand the functions of the proposed system.

Login use case description
Use case name Login

Use case identifier UC01
Actor(s) Administrator, Stock manager, Store man, User
Description Authorized users only access the system
Pre-condition The user not already logged in to the system. and the
user must have a valid user name and password
Post-condition The user(s)access the system.
Basic course of action
1. The user sends the request to the server using web browser.
2. The System displays the login page.
3. The user enters username and password and press login button.
4. The system validates the account.
5. The system displays the appropriate home page.
6. The user access the system.

7. Use case end.
Alternative course of action
4a. If in line 4, the user is not found in the system, then the system displays an error message
(e.g. Incorrect User Name and Password) go to step 3:
4b. Use case ends.
Table 2: login use case description
Manage accountsuse case description

Use case name Manage accounts
Use case identifier UC02
Actor(s) Administrator
Description Property administrator can add or remove accounts
of users and stakeholders.
Pre-condition Property administrator has privileges to manage
accounts of users and stakeholders.
Post-condition The propertyadministrator successfully manages
stakeholders and users account
Basic course of action
1. Property administrator wants to manage accounts.

2. The property administrator chooses manage account link
3. The system display manage account page
4. The property administrator clicks “Create account” or “Remove account” button.
5. The system display Create account or Remove account page.
6. Property administrator enters required information via create or Remove page.
7. The system cheeks that all the entered information are valid.
8. System display different message accordingly.
9. Use case ends.
If the property administrator enters incorrect information
10. The system determines the entered information is invalid.
The system displays message “the entered information is invalid” go to step 4
11. Use case ends.
Table 3: manage accounts use case description
Register Stock use case description

Use Case Name Record stock
Use case Id UC03

Actors Stock manager
Description The Stock manager can record every detail ofequipment’s
before they are stocked in and stock out.
Precondition Property must be available.
Basic course of action Actor Action:
Step1:The stock manager log to his/her page.
Step2:The stock manager click on Register stock.
Step4:The stock manager fills the form and save it.
System Response:
Step3:The system displays the registration stock form.
Step5:The system displays saved the property file.
Step6: Use case ends.
Alternative course of action  The system display error message if the form is not
filled correctly. The system redirects to go to step 3 to
refill.
Use case ends.
Post condition The property registered successfully.
Table 4: Register Stock use case description

Update Stock use case description
Use Case Name Update stock
Use case Id UC04
Actors Stock manager
Description The Stock manager can update every detail ofequipment’s
when they are stocked in or stock out.
Precondition Property must be available.
Step1:The stock manager log to his/her page.
Step2:The stock manager click on Update stock.
Step4:The stock manager fills the updated property.
System Response:
Step3:The system displays the update stock form.
Step5:The property file updated.

Alternative course of action  The system display error message the form is not
filled correctly.The system redirects to go to step 4 to
refill the information.
Use case ends.
Post condition The stock updated successfully.
Table 5: Update Stock use case description

View request use case description
Use case name View request

Use case Id UC05
Description Property administrator can able to View the request
acquisition ofasset’s when the users send request.
Precondition Before approve the request the user must be
registered and have its own account.
Basic course of action Actor action
Step 1: The Administrator logs in to his/her account.
Step 2: The administrator click request notification
Step 4:The administrator view the request.
System response
Step 3: The system display the available request.
Step5:use case ends
 If the administrator Invalid user accounts the
process failed and use case ends.
 If the approved notification is not found there is
no request then use case ends
Post condition View available request successfully
Table 6: View request use case description

Approve request use case description
Use case name Approve request
Use case Id UC06

Description Property administrator can able to approve the
request acquisition ofasset’s when the users
fulfill the criteria
Precondition Before approve the request the user must
be eligible
Step 1: The Administrator logs in to his/her
account.
Step 2: The administrator click request
notification
Step4. The Administrator click the approve or
cancel request
System response
Step 3: The system display the approve or cancel
requestform.
5. use case ends
 If the administrator Invalid user accounts
the process failed and use case ends.
 If the approved notification is not found
there is no request then use case ends
Post condition Approved successfully
Table 7: Approve request use case description

View available asset in store use case description
Use case name View available asset in store

Use case Id UC07
Actor(s) Administrator,user
Description The actors able to view the available asset that registered in
the database
Precondition To view the available asset the asset must be registered first
as well as the actors must have privilege to view the

available asset
Step1:The actors login to his/her account.
Step2: The actor click view asset list button
System response
Step3:The system display available asset in the store
step 4: use case ends
Alternative course of action  If the actor does not have valid user account, then the
system display an error message and use case ends
 If the asset is not found the system displays empty
message!
Post condition View available asset in store successfully
Table 8: View available asset use case description

Use case name Request asset
Use case Id UC08
Actor(s) User(s)
Description The user can make request to obtain the asset for different purposes
Precondition The user needs to be registered by the system to involve any usage of
the university
Step1:The user login using his/her account
Step2: Theuser clicks the button request.
Step4:The user fill request form
Step5:User send request using send button
System response
Step3: The system displays request form
Step 6: use case ends.
Alternative course of action  If the user have no valid account the system display error message
then use case ends
 If the user enters invalid information in to the request form the
system display error message then go to step 4.

Post condition Make request successfully
Table 9: Request asset use case description

Use case name View approved request
Use case Id UC09
Actor(s) Store man, stock manager
Description The stock manager and the store man view the approved
request from the property administrator.
Precondition The request must be approved by administrator
Step1:The actors login with his/her account
Step2:The actors click request approved notification
Step4: The actors view approved request.
System response
Step3: The system display approved request.
Step5: The system success message and display then use
case ends.
Alternative course of action  If the actors have no valid account the system display
error message then use case ends
Post condition Check the request approved successfully
Table 10: View approved request use case description

Calculate deprecation use case description
Use case name Calculate deprecation
Use case Id UC10
Actor(s) Store man
Description Deprecation means decrease in an asset's value, may be
caused by a number of other factors as well such as
unfavorable market conditions, etc. Machinery, equipment,
currency are some examples of assets that are likely to
depreciate over a specific period of time.
Precondition To calculate deprecation the asset starting to give service.
Step1:The store man log to his/her page.

Step2:The store man click on deprecation button.
Step4:The store man fills the form and save it.
System Response:
Step3:The system displays the deprecation form .
Alternative course of action  If the store man have no valid account the system
display error message then use case ends.
Post condition Calculate the deprecation successfully
Table 11: Calculate deprecation use case description

Transfer the asset use case description
Use case name Transfer asset
Use case Id UC11
Description The administrator , after checking the transfer
request correctness, can transfer the asset from one
user to another
Precondition The user should request transfer
Step1:The administrator log to his/her page.
Step2:The administrator click on transfer asset
link.
Step4:The administrator fills the asset transfer
form.
System Response:
Step3:The system displays the asset transfer form.
Step5:The system displays asset transfer performed
successfully.
Step4: Use case end
Alternative course of action  The system display error message if
the form is not filled correctly then go
to step 4
 Use case ends.

Post condition The system able to transfer successfully from one
user to the other
Table 12:Transfer the asset use case description
Register returned asset use case description

Use case name Registered return asset
Use case Id UC12
Actor(s) Store man
Description Users may return the assets registered by their names for
different reasons.
Precondition To registered the item as retuned first must be checked the
asset status
Step2:The store man click on return asset link.
Step4:The store man fills the asset return form.
System Response:
Step3:The system displays the return asset form.
Step5:The system displays registered success message
Step4: Use case ends
Alternative course of action  The system display error message if the form is
not filled correctly then go to step 4
 Use case ends.
Post condition The returned item must be registered successfully.
Table 13:Register return asset use case description

Register asset use case description
Use case name Register asset
Use case Id UC13
Actor(s) Store man
Description The store man registers the asset which is in the stock as
well as stock out.
Precondition The asset in stock must be available and the user must
take the asset.

Step2:The store man click on register asset link.
Step4:The store man fill the asset registered form.
System Response:
Step3:The system displays the register asset form.
Step5:The system displays registered success message
Alternative course of action  The system display error message if the
form is not filled correctly then go to step 4
 Use case ends.
Post condition The returned item must be registered successfully.
Table 14: Register asset use case description.

Update asset use case description
Use case name Update asset
Use case Id UC14
Actor(s) Store man
Description The store man registers the asset which is in the stock as
well as stock out.
Precondition The asset in stock must be available and the user must take
the asset.
Step2:The store man click on update asset link.
Step4:The store man fill the asset update form.
System Response:
Step3:The system displays the update asset form.
Step5:The system displays asset updated successfully
Post condition The item must be updated successfully.
Table 15:Update asset use case description.
Modify account use case description

Use case name Modify account
Use case Id UC15
Actor(s) Administrator,Stock manager, Store man, user
Description The Actors can modify their account for security
purpose unless the accounts are hacked by others.
Precondition The Actors must have a privilege to modify their
account.
Step1:The Actors log to his/her page.
Step2:The Actors click on Modify account link.
Step4:The Actors fill the Modify account form.
System Response:
Step3:The system displays the Modify account
form.
Step5:The system displays account modified
successfully
Alternative course of action  The system display error message if
the form is not filled correctly then go
to step 4
 Use case ends.
Post condition The item must be updated successfully.
Table 16:Modify accountusecasedescription.

Generate report use case description
Use case name Generate report
Use case Id UC16
Description The administrator generates report according
from data base.
Precondition The administrator must have privilege to
generate report.
Step 1: The administrator login using his/her
account.
Step2: The administrator clickreport link.
Step4: The administrator chooses the particular

report link.
System action
Step3: The system display report
Options.
Step 5:The system display generated report
Alternative course of action  If the Administrator has no valid account
the system display error message then use
case ends.
Post condition The report generate correctly
Table 17:Generate report use case description
3.2 Class diagramand object diagram

The Class diagram for the proposed HU Property management system shows an object oriented
analysis and design in brief. A class diagram shows the classes of the system, their
interrelationships and the operations and attributes of the classes. Class diagrams are used for
wide variety of purposes, including both conceptual/domain modeling and detailed design
modeling.

Administrator
-userName:string
StockManager
-password:string Account
+login() -firstName:string
#manageAccount() Manage -userName:string -lastname:string
-password:string -idNumber:string
#manageRequest()
-sex:string
+viewAvailableAsset() 1 +getUserName() -department:string
#transferAsset() +getPassword() -campus:string
+modifyAccount() use +login() -phone:string
+logout() +logout() -address:string
+login()
1 #registerStock()
use use
+searchStock()
use
#updateStock()
Item +viewApprovedRequest()
+ogout()
#name:string
StoreMan
1
#modelName:string
#code:string
-firstName:string
#type:string
manage
manage
-lastname:string
#quantity:float
-idNumber:string
#cost:float
-sex:string
-department:string
-campus:string
User
-phone:string
-firstName:string
-address:string
0..*
-lastname:string
+login() -idNumber:string
+viewApprovedRequest() -sex:string
+manageAsset() Asset Stock
-department:string
#registerReturnAsset() -campus:string
-status:string -safeGard:string
#calculateDepreciation() -phone:string
-expiresAt:string -createdAt:string
+modifyAccunt() -address:string
#insertAsset() -updatedAt:string
+ogout()
+searchAsset() -insertStock() +login()
1 Manage 0..* #updateAsset() +searchStock() +viewAvailableAsset()
-updateStock() +requestAsset()
0..* +modifyAccount()
1..* +ogout()
View
1
TransferAsset take
-id:string
-observer:string
-asset:string
-assetCode:string
-quantity:int
-issueDate:string ReturnAsset
-toOwnerFname:string
-OwnerLname:string -empId:string
-fromOwnerFname:string -assetStatus:string
-fromOwnerLname:string -ownerName
-reason:string -sfGard:string
Manage -issueItem:string
-returnDate:string
-description:string
Request +getIssueItem:string
+getOwnerName:string
manage -empId:string send
-reqId:string
-assetName:string
-quantity:int
-model:string
Figure 3.2.1 Class diagram

Object Diagram
Object diagram is a diagram that shows a complete or partial view of the structure of a modeled
system at a specific time. Here we have put the partial view of the structure of a modeled
Haramaya University Property management system using object diagram.
storeman1:storMan
firstName="Mikias"
lastname="Tilahun" accont1:Account admin:Administrator
idNumber="1671_06"
sex="male" User_name="Store Keeper" User_name="Admin"
department="Cs" Pass_word="******" Pass_word="******"
campus="main"
phone="+2519973867"
address="harar"
stockM1:stockManger
firstName="Shemsu"
lastname="Kedir"
idNumber="1731_07"
a1:Asset
sex="male"
department="IS"
name="Computer"
campus="main"
modelName="model_19"
phone="+2519973867"
code="hu_comp_193" user1:User
address="harar"
type="pemanent"
quantity=12 firstName="Shemsu"
cost=8845.45 lastname="Kedir"
status="good" idNumber="1731_07"
expiresAt='12/03/2025' sex="male"
department="IS" stock1:stock
campus="main"
phone="+2519973867" name="Computer"
address="harar" modelName="model_19"
code="hu_comp_193"
type="pemanent"
quantity=12
cost=8845.45
safeGard="Shemsu"
createdAt='12/03/2017'
updatedAt='23/04/2017''

3.3 Dynamic Model

A dynamic model is used to express and model the behavior of the system over time. It includes
support for activity diagrams, state diagrams, sequence diagrams and stat chart diagram.
3.3.1 Sequence diagram

Sequence diagrams are used to depict graphically how objects interact with each other via
messages in the execution of a use case or operation. They illustrate how the operations are
performed between objects and in what sequence. Property Management System sequence
diagram is an interaction diagram that shows how processes operate with one another and in
what order. It is a construct of a Message Sequence Chart. This sequence diagram shows object
interactions arranged in time sequence. It depicts the objects and classes involved in the scenario
and the sequence of messages exchanged between the objects needed to carry out the
functionality of the system.
Login sequence diagram
Login sequence diagram shows a sequence of activities that happen when user login in to the
system.
Figure 3.3.1.1: Login sequence diagram

Create Account Sequence Diagram
This sequence diagram shows the sequential activities to create account for users.
CreateAccount
:Adminstrator AdminstratorPage: CreateAccount CreateAccount CreateAccount
Form: PDB
<<UI>> link:<<ui>> Form:<<ui>> Form:Model
Controller
Login to Admin Page()
Select the link()
Display the Account Form()
Fill the required field and

Press the create Account
Button()
Validate()
CreateAccount
Request()
RequestCreate
AccountRequest()
Check()
alt
[created]
Succesfully Create()
CreateAccount has been created
Succesfully Create()
succesfully()
[notCreated]
UnsuccesfulCreate() UnsuccesfullCreate()
CreateAccount has been Failed()
Figure 3.3.1.2: Sequence Diagram for Create Account

Register Stock Sequence Diagram
This sequence diagram shows the sequential activities to record stock before Stock In and Stock
Out.
Stock Record Record:

Modulelink: StockForm: RecordController:C
:Stock Manager Model PDB
<<UI>> <<ui>> ontroller
SelectStockModulelink()
Display RecordForm()
Fill the Record field and Press Validate

Add button() Request
RecordStock() RecordStock()
Store()
Check
alt
[Valid]
Registersuccess
RegisterSuccess
RegisterSuccess
[Invalid]
Unsuccessfully
Error
Unsuccessfully
Message()
Figure 3.3.1.3: Sequence Diagram for Register Stock

Remove Account Sequence Diagram
This diagram shows the sequential flow of activities to remove the existing user’s account from
the system.
RemoveAccount RemoveAccount RemoveAccount

Admin Form: <GUI> l Form: Controller Form: Model :DB
Validate()
Search for the account
To be removed by using
SEARCH Button Searchaccount()
SearchRequest() Check()
alt
Search Found()
[Search found]
Search Found()
Search Found()
RemoveAccount
by clicking removebutton
RemoveAccount RemoveAccount
RemoveAccount)
Successfully Removed()
Successfully Removed()
Account has been

sucessfully Removed
[Search Not Founf] Search Not Found()
DispayError()
Search Not Found Error Message
Figure 3.3.1.4: Sequence Diagram for Remove Account

View Request Sequence Diagram
Request View:
View ViewController:Con
:Admin Modulelink: Model PDB
Request :<<ui>> troller
<<UI>>
SelectRequestModulelink()
ViewRequest
RetrieveRequest
Checkrequest
ViewResult
Display()
Display()
DisplayRequest)
Figure 3.3.1.5: Sequence Diagram for View Request

Approve Request Sequence Diagram
Request Requestfromuser Approve:

ApproveController:
:Admin Modulelink: AndApproveForm: Model PDB
Controller
<<UI>> <<ui>>
Display
RequestandApproveForm()
Approverequest or Cancel() Approve or Cancel()

Request
Approve or Cancel()
Approve or
Cancel()
Approve
alt or Cancel
[Valid]
Approvesuccess
ApproveSuccess
ApproveSuccess
[Invalid]
Unsuccessfully
Error
Unsuccessfully
Message()
Figure 3.3.1.6: Sequence Diagram for Approve Request

View Available Asset Sequence Diagram
This diagram shows the sequential flow of activities to view available asset from the system.
Asset ViewAsset View:

ViewController:Con
:Users Modulelink: page: Model PDB
troller
<<UI>> <<ui>>
SelectAssetkModulelink()
Display ViewAssetpage()
SearchAsset() SearchAsset()
Request
SearchAsset()
Check()
Check
alt
[Valid]
Searchsuccess
SearchSuccess
View AvailableAsset() Searcshccess
[Invalid]
Unsuccessfully
Error
Unsuccessfully
Message()
Figure 3.3.1.7: Sequence Diagram for View available asset

Request assetSequence Diagram
This diagram shows the sequential flow of activities to request asset.
Request Request Requestr:

RequestController:
:User Modulelink: AssetForm: Model PDB
Controller
<<UI>> <<ui>>
Display RequestForm()
Fill the Request field and

Press Send button() Request
Validate Request Asset()
Request Asset() sendRequest()
Check
alt
[Valid]
Requestsuccess
RequestSuccess
Successfullysendrequest RequestSuccess
[Invalid]
Unsuccessfully
Error
Unsuccessfully
Message()
Figure 3.3.1.8: Sequence Diagram for request asset

ViewApproved Request Sequence Diagram
This diagram shows the sequential flow of activities to check request approve.
RequestApp View:
rovedlink: ViewRequest ViewController:Con Model
:StoreMan PDB
<<UI>> Page:<<Ui>> troller
SelectRequetApprovedlink()
Activatecontroler
check
check
Check
alt
[Valid]
Viewsuccess
ViewSuccess
Viewsuccessfully ViewSuccess
[Invalid]
Unsuccessfully
Error
Unsuccessfully
Message()
Figure 3.3.1.9: Sequence Diagram for View approved request

Depreciation Sequence Diagram
This diagram shows the sequential flow of activities for depreciation.
Depreciation Depreciation Depreciation:

DepreciationContro
:StoreMan Modulelink: AssetForm: Model PDB
ller:Controller
<<UI>> <<ui>>
SelectDepreciation
Modulelink()
Display
DepreciationForm()
Fill the Depreciation field and

Press Add button() Validate Request
Depreciationrecord()
Depreciation
record() Check()
Check
alt
[Valid]
Registersuccess
RegisterSuccess
RegisterSuccess
[Invalid]
Unsuccessfully
Error
Unsuccessfully
Message()
Figure 3.3.1.10: Sequence Diagram for Depreciation

Transfer Asset Sequence Diagram
This diagram shows the sequential flow of activities to transfer the asset from user to user.
Transfer Transfer:
Transfer TransferController:
:Admin Modulelink: Model PDB
AssetForm:<<ui>> Controller
<<UI>>
SelectTransferModulelink()
Display TransferForm()
Fill the Transfer field and Validate

Press Save button() Request
TransferAsset()
Transfer()
TransferAsset
Check
alt
[Valid]
Transferrsuccess
TransferrSuccess
TransferrSuccess
[Invalid]
Unsuccessfully
Error
Unsuccessfully
Message()
Figure 3.3.1.11: Sequence Diagram for Transfer Asset

Register Returned Asset
This diagram shows the sequential flow of activities to register the return asset to the system.
ReturnAsset RegisterReturn Registerreturn:

RegisterReturnCont
:Store Man Modulelink: AssetForm: Model PDB
roller:Controller
<<UI>> <<ui>>
SelectReturnAsset
Modulelink()
Display RegisterForm()
Validate
Fill the Register field and
Press save button() Request
RegisterAsset() RegisterAsset()
Check()
Check
alt
[Valid]
Registersuccess
RegisterSuccess
RegisterSuccess
[Invalid]
Unsuccessfully
Error
Unsuccessfully
Message()
Figure 3.3.1.12: Sequence Diagram for Register returned asset

Register Asset Sequence Diagram
This diagram shows the sequential flow of activities to register the asset to the system.
Asset Register Register:

RegisterController:
:Store Man Modulelink: AssetForm: Model PDB
Controller
<<UI>> <<ui>>
SelectAssetModulelink()
Display RegisterForm()
Validate
Fill the Register field and RegisterAsset()

Press save button() Request
RegisterAsset()
Check()
Check
alt
[Valid]
Registersuccess
RegisterSuccess
RegisterSuccess
[Invalid]
Unsuccessfully
Error
Unsuccessfully
Message()
Figure 3.3.1.13: Sequence Diagram for Register Asset

Modify account Sequence Diagram
Modify Modify
Modify Account: Account: :DB
User Account: <GUI> Controller Model
Validate()
Enter Current Password
And New Password
ModifyAccount Check Current Check()
(current,new) ModifyAccount password()
(current,new)
alt
Valid Current Password
[Valid Current Password]
Modify(current,new)
Successfully Modified()
Successfully Modified()
Account Modified
sucessfully
[Invalid Current Password]

Invaild Current Password
Invaild Current Password
Error Msaage Dispay
Figure 3.3.1.14: Sequence Diagram for Modify account

Generate Report Sequence Diagram
This diagram shows the sequential flow of activities to generate report the from the system.
Report GenerateReport Generate:

Modulelink: Form: GenerateController Model
:Admin PDB
<<UI>> <<ui>> :Controller
SelectRepoModulelink()
Display ReportForm()
GenerateReport() GenerateReport()
Request
Generate()
Check()
Check
alt
[Valid]
Generatersuccess
GeneraterSuccess
GeneraterSuccess
[Invalid]
Unsuccessfully
Error
Unsuccessfully
Message()
Figure 3.3.1.15: Sequence Diagram for Generate Report

3.3.2 Activity diagram

An Activity diagram focuses on the flow of activities involved in a single process. The Activity
diagram shows how these single-process activities depend on one another.
Login Activity diagram
Enter User Name and Password
Display Error INVALID VALID

Display the target
Message page
Check User Name and

Password Validation
Figure 3.3.2.1 Activity Diagram for Login

Create acount activity diagram
LOG IN
Display Error
Message
Invaild Valid Add user account
Add valid Add invalid

SAVE account account
Display Error
Message
Create account
successfully Edit Highlighted
Highlight Error
Error
Figure 3.3.2.2: Activity Diagram for Create account

Registor stock activity diagram
Log In
Display Error Message
Invalid Valid
Register stock
Valid Invalid
Save Display Error

Message
Record asset
succssfully
Highlight Error
Edit Highlighted Error
Figure 3.3.2.3: Activity Diagram for Register Stock

Update Stock activity diaram
LOG IN
Display Error
Message
search the stock to
Invaild Valid
be updated
Update Display Error

Search Found
Stock Message
Search
Not Found
Display Error Invalid

Message
Valid
SAVE
Selected stock
Updated
Successfully
Figure 3.3.2.4: Activity Diagram for Update Stock

View request activity diagram
LOG IN
Display Error
Message
Invaild Valid View request
display available request
Figure 3.3.2.5: Activity diagram for View request

Approve request activity diagram
LOG IN
Display Error
Message
Invaild Valid Approve request
succefully approved
Figure 3.3.2.6: Activity Diagram for Approve Request

View available asset Activity Diagram
LOG IN
Display Error
Message
Search for the asset

Invaild Valid
you want
successfully Search Found

Display Error
searched Message
Search
Not Found
Figure 3.3.2.7: Activity Diagram for View available asset

Requestasset activity diagram
LOG IN
Display Error
Message
Invaild Valid Make request
Valid
SAVE request
invalid
Display Error
Message
make request
successfully Edit Highlighted
Highlight Error
Error
Figure 3.3.2.8Activity Diagram for Request asset

View approvedrequest activity diagram
LOG IN
Display Error
Message
Checked requested
Invaild Valid
approve
successfully
checked
Figure 3.3.2.9 Activity Diagram for Viewapproved request

Calculate depreciation activity diagram
LOG IN
Display Error
Message
Invaild Valid
calculate
deprication
Valid
SAVE calculation
invalid
Display Error
Message
successfully
Calculate Edit Highlighted
Highlight Error
Error
Figure 3.3.2.10 Activity Diagram for Calculate deprecation

Transfer the asset from user to user
LOG IN
Display Error
Message
Invaild Valid
transfer asset from
user to user
Valid Invalid
SAVE transfer transfer
Display Error
Message
successfully
transfered Edit Highlighted
Highlight Error
Error
Figure 3.3.2.11: Activity Diagram for Transfer the asset

Register asset activity diagram
LOG IN
Display Error
Message
Invaild Valid register asset
InValid
SAVE Valid recored
Record
Display Error
Message
Asset register
Successfully Edit Highlighted
Highlight Error
Error
Figure 3.3.2.12: Activity Diagram for Register asset

Register returned asset activity diagram
LOG IN
Display Error
Message
Invaild Valid
register
retured asset
InValid
SAVE Valid recored
Record
Display Error
Message
Successfully
Registered Edit Highlighted
Highlight Error
Error
Figure 3.3.2.13: Activity Diagram for Register returned asset

Modify account activity diagram
LOG IN
Display Error
Message
Invaild Valid Modify account
SAVE Valid Invalid
Display Error
Message
account modified
succefully Edit Highlighted
Highlight Error
Error
Figure 3.3.2.14:Activity Diagram for Modify account

Generate report activity diagram
LOG IN
Display Error
Message
Select the the link
Invaild Valid you want to
generete report
report successfully
generated
Figure 3.3.2.15: Activity Diagram for Generate report

3.3.3 State chart diagram

A statechart diagram is a view of a state machine that models the changing behavior of a state.
Statechart diagrams show the various states that an object goes through, as well as the events that
cause a transition from one state to another.
The common model elements that statechart diagrams contain are:
 States
 Start and end states
 Transitions
Login State chart diagram
Initial State
Activate
Home Page
Select
Login Liink
Fill
Login Form
Invalid
Valid
Verify Confirm Login
Dispaly
Appropriate Page
Final State
Figure 3.3.3.1 State chart Diagram for Login

Create account State chart diagram
Initial State
Activate
Home Page
Select
Login Liink
Fill
Login Form
Invalid Valid Create account

Verify
link
Fill
account form
Invalid
Verify
Valid
Account created
succesfully
Final State
Figure 3.3.3.2 State chart Diagram for Create account

Register Stock State chart diagram
Initial State
Activate
Home Page
Select
Login Liink
Fill
Login Form
Invalid Valid
Verify Register stock link
Fill
Register stock form

Invalid
Verify
Valid
Stock registered
sucesfilly
Final State
Figure 3.3.3.3 State chart Diagram for Register Stock

Update Stock State Chart Diagram
Initial State
Activate
Home Page
Select
Login Liink
Fill
Login Form
Invalid Valid
Verify Update stock link
Fill
Update stock form

Invalid
Verify
Valid
Stock Updated
sucessfully
Final State
Figure 3.3.3.4 State chart Diagram for Update Stock

View request state chart diagram
Initial State
Activate
Home Page
Select
Login Liink
Fill
Login Form
Invalid Valid Request

Verify
notification
display
Available request
Final State
Figure 3.3.3.5 State chart Diagram for View request

Approve request state chart diagram
Initial State
Activate
Home Page
Select
Login Liink
Fill
Login Form
Invalid Valid Request

Verify
notification
Fill
Approve or ignore
form.
click
approve or ignore
request
Final State
Figure 3.3.3.6 State chart Diagram for Approve request

View available asset in Store State Chart Diagram
Initial State
Activate
Home Page
Select
Login Liink
Fill
Login Form
Invalid Valid
Verify View asset link
Display
Available asset
Final State
Figure 3.3.3.7 State chart Diagram for View available asset in store

Request asset State Chart Diagram
Initial State
Activate
Home Page
Select
Login Liink
Fill
Login Form
Invalid Valid
Verify Request link
Fill
Request form
Invalid Valid
Send Requist
Final State
Figure 3.3.3.8 State chart Diagram for Request asset

View approvedrequest State chart Diagram
Initial State
Activate
Home Page
Select
Login Liink
Fill
Login Form
Invalid Valid request approved

Verify
notification
Display
approved request
Check
approved request
Final State
Figure 3.3.3.9 State Chart Diagram for View approved request

Calculate depreciation State chart Diagram
Initial State
Activate
Home Page
Select
Login Link
Fill
Login Form
Invalid Valid
Verify Depreciation link
Fill
Form
Invalid Valid
Depreciation make
successfully
Final State
Figure 3.3.3.10 State Chart Diagram for calculate depreciation

Transfer Asset State Chart Diagram
Initial State
Activate
Home Page
Select
Login Liink
Fill
Login Form
Invalid Valid
Verify Transfer asset link
Fill
Asset transfer Form

Invalid Valid
Asset transfer
performed
succefully
Final State
Figure 3.3.3.11 State Chart Diagram for Transfer Asset

Register Asset State Chart Diagram
Initial State
Activate
Home Page
Select
Login Liink
Fill
Login Form
Invalid Valid
Verify Register asset link
Fill
Register asset form

Invalid Valid
Asset registered
successfully
Final State
Figure 3.3.3.12 State Chart Diagram for Register Asset

Registered returned Asset State Chart Diagram
Initial State
Activate
Home Page
Select
Login Link
Fill
Login Form
Invalid Valid
Verify Return asset link
Fill
Return asset form

Invalid
Valid
Return registered
successfully
Final State
Figure 3.3.3.13 State Chart Diagram for Register returned Asset

Modify account State chart Diagram
Initial State
Activate
Home Page
Select
Login Link
Fill
Login Form
Invalid Valid
Verify Modify account link
fill
Modify account
form
display
Account modified
succefully
Final State
Figure 3.3.3.14 State chart diagram for Modify account

Generate report State chart Diagram
Initial State
Activate
Ho me Page
Select
Login Lin k
Fill
Login Form
Invalid Valid
Verify Report Link
Display
Report Option
Choose
Particular Report
option
Display
Generated Report
Final state
Figure 3.3.3.15 State chart diagram for Generate Report

3.4 Data dictionary
Data Dictionary is repositories to store information about all data items. A data dictionary
contains a list of all files in the database, the number of records in each file, and the names and
types of each field. Most database management systems keep the data dictionary hidden from
users to prevent them from accidentally destroying its contents.
Data dictionary for user registration
USER DATATYPE CONSTRAINT
FirstName String NOTNULL
LastName String NOTNULL
UserName String NOTNULL
Idnumber String PRIMARYKEY
Sex String NOTNULL
Department String NOTNULL
Campus String NOTNULL
Phone String NOTNULL
Address String NOTNULL
Table 17:data dictionary for user registration
Data dictionary for store man registration

STOREMAN DATATYPE CONSTRAINT
Sex String NOTNULL
Table 18: data dictionary for Store man registration
Data dictionary for Stock manager registration

STOCKMANAGER DATATYPE CONSTRAINT
Sex String NOTNULL
Table 19:data dictionary for Stock manager registration
Data dictionary for Transfer asset

TRANSFER DATATYPE CONSTRAINT
Id String PRIMARYKEY
Observer String NOTNULL
Asset String NOTNULL
IssueDate String NOTNULL
ToOwnerLname String NOTNULL
OwnerLname String NOTNULL
FromOwnerFname String NOTNULL
FromOwnerLname String NOTNULL
Reason String NOTNULL
Table 20:data dictionary for Transfer asset

Data dictionary for Account
ACCOUNT DATATYPE CONSTRAINT

Username String NOTNULL
Password String NOTNULL
Table 21:data dictionary for Account

Data dictionary for Request
REQUEST DATATYPE CONSTRAINT

Empid String NOTNULL
Reqid String PRIMARYKEY
AssetName String NOTNULL
Quantity String NOTNULL
Model String NOTNULL

Table 22:data dictionary for Request asset
Data dictionary for Return asset registration
RETURNASSET DATATYPE CONSTRAINT

Empid String PRIMARYKEY
assetStatus String NOTNULL
ownerName String NOTNULL
sfGard String NOTNULL
Issueitem String NOTNULL
returnDate String NOTNULL
Description String NOTNULL
Table 23:data dictionary for Return asset registration

Data dictionary for Asset registration
ASSET DATATYPE CONSTRAINT

Name String NOTNULL
modelName String NOTNULL
Code String PRIMARYKEY
Type String NOTNULL
Cost String NOTNULL
Status String NOTNULL
expireAt String NOTNULL
Table 24:data dictionary for Asset registration

Data dictionary for Stock registration
STOCK DATATYPE CONSTRAINT

Name String NOTNULL
modelName String NOTNULL
Code String PRIMARYKEY
Type String NOTNULL
Cost String NOTNULL
Safegard String NOTNULL
createdAt String NOTNULL
updatedAt String NOTNULL
Table 25: data dictionary for Stock registration

3.5 User interface navigational paths and screen mock-ups

User interface navigational paths
Hu property
managment system
Home page
Login page
Stock manager Administrator View available User

page page Asset in store page
Store Request
Manage Asset
keeper
Stock Manage
page
account
Calculate
View Add
Deprication
stock account
Register
Remove
Asset
Account
View approved
Manage
request
request
Generate
report
Register
return asset
Transfer asset
Modify
account
Figure 3.5.1 user intrerface navigational path

Screen mock-ups

Figure 3.5.2 Login screen muck-up

Figure 3.5.3 Register asset screen muck-up

Figure 3.5.4 Create account screen muck-up

Chapter 4
System Design
Systems design is simply the design of systems. It implies a systematic and rigorous approach to
design, an approach demanded by the scale and complexity of many systems problems. System
design is the process of defining the components,modules, interfaces, anddatafor asystemto
satisfy specifiedrequirements. System development is the process of creating or altering systems,
along with the processes, practices, models, and methodologiesused to develop them.
4.1 Introduction
System designing is the transformation of the analysis model into a system design model. Until
this system designing step the system were in the problem domain. Here System design is the
first part to get into the solution domain in a software development. This chapter focuses on
transforming the analysis model into the design model that takes into account the nonfunctional
requirements and constraints described in the problem statement and requirement analysis
sections discussed earlier in the previous parts.
The objective of designing a system is to clearly show the direction how the system is built and
to obtain clear and enough information needed to drive the actual implementation of the system.
It is based on understanding of the model the software built on. The objectives of design are to
model the system with high quality. Implementing of high quality system depend on the nature
of design created by the designer. If one want to changes to the system after it has been put in to
operation depends on the quality of the system design. So if the system is design effetely, it will
be easy to make changes to it.
4.1.1 Overview of system design
System design is a process through which the requirements are translated into software. The goal
of design process is to provide a blue print for implementation, testing and maintenance
activities. As we tried to put the overall the objective of the property management system on the
requirement analysis part, improve an access by using personal computer over the internet and to
improve the quality and effectiveness of management by using a computer to support a property
management process is the main goal of the system.

4.1.2 Design goal of the property management system
The design goal illustrates the desired qualities of the system and provides a consistent set of
criteria that must be considered when making the design decisions in system designing. Basically
it is based on the non-functional requirements. This means that non-functional requirement is the
description of the feature characteristics and attribute of the system as well as any constraints
that may limit the boundary of the proposed solution. Here we are listing some of the major
design goals that have to be fulfilled for efficient functionality of the system.
a. Robustness: the proposed property management system has to be robust enough to
manage any valid input from the users.
b. Reliability: the proposed system has to be reliable. The system has to perform
operations without any errors.
c. Security: unauthorized access to the system has to be maintained effectively. The

proposed system has to be secured from any unauthorized access to the data in the
system.
d. Modifiability: the proposed system has to be able to modify and enhance for
further advanced modification in the future.
e. Performance: the proposed system has to perform very fast in respond to high
throughput. It has to give activity in a fast and efficient way. The system is going to
handle multiple user requests and process them efficiently. This helps the system to be
accessed from different locations.
f. Availability: the proposed system has to be available for multiple accesses. The
system must run on multiple operating systems and support windows operating
system.
g. End User: The system have simple and interactive graphical user Interface. All the
interfaces, forms and buttons are designed in a simple language or common language
so that the user can access it without any difficult. So user should access the system

without any complexity. The web pages are deigned to be more user friendly such as
forms and buttons which have descriptive names.
h. Response time:the proposed system should respond the user requests within a
specified period of time and up to the standard response time after the request has been
issued.
4.2 System decomposition with services
System decomposition is breaking down a system into its component subsystems, analyzing each
separately, and aggregating them back into the complete system.During system decomposition of
property management system, we break down the system into different subsystems or modules.
The subsystems are with strong coherence in order to perform specific task and loosely coupled
in order to solve and modify the modules separately. Our system decomposition shows the
existence of the following subsystems.
Account management module
The account management subsystem is aimed for managing the system user accounts. System
administrator is only responsible for managing, controlling and interacting with this sub system.
The major functions provided by this sub system are:
 Login ()
 Create account ()
 Remove account ()
 Change password ().
 Set user privilege()
 Logout()
Asset management module
The Asset management subsystem is for managing property of the university which is already in
the service or in user hand. The sub system uses the storage subsystem for storing variety of
information.

 Login()
 Register asset()
 Search asset()
 Update asset()
 Register return asset()
 Logout()
Stockmanagement module
This subsystem is responsible for managing before stockin and stockout. The sub system uses the
storage subsystem for storing variety of information.
 Register stock()
 Search stock()
 Update stock()
Requestmanagement module
This subsystem is responsible for managing request of the user. The sub system uses the storage
subsystem for storing variety of information.
 Request asset()
 View request()
 Approve request()
 Cancel request()
Storage (data base) module
The storage subsystem enclose in the database providing a common interface to other three high
level subsystems. It is responsible for getting system-related data from different subsystems and
issuing DBMS-specific calls for information storage and retrieval. The database subsystem will

be implemented by relational database management system which is used to store the persistent
data.
Graphical User Interface subsystem
GUI subsystem is responsible for the interaction between user and the system. It provides simple
way of interaction of the user to the system because of its simplicity.
Admin
Stock StoreMan
Manager
User
Manage
Asset
Manage
Stock
Database
Manage
request
Figure 1.2.1: Deployment Diagram
4.3 Current Software Architecture

Currently, Haramaya University doesn’t have any kind of automated property management
system. The current system is manual. The proposed system will be the first of its kind for
Haramaya University.

4.4. Proposed Software Architecture

Haramaya university property management system will be web based system, which is used to
automate the current manual system. Because of this, the system will have its own software
architecture. In order to propose the proposed system software architecture, we will use 3-tier
architecture. The reason why we choose this type of architecture is; because of latest web
applications are deployed in this type of architecture.
 Tier 1: Presentation layer (tier on the top)
In this tier, Haramaya university property management system users browse in order
to display user data using graphical interface.
 Tier 2: Business layer (tier in the middle)
The proposed system business layer uses Haramaya university web server to handle
the data validation.
 Tier 3: Data access layer (tier at the bottom)
The proposed system data access layer uses the MYSQL database server to
communicate with the database by constructing different SQL queries.
The proposed software architecture of Haramaya university property management system

ispresented below.
Database
Management
Client Web server
system
(DBMS)
User running running
Database
web
web browser
applications
Figure 4.4.1: proposed software architecture

4.5 Hardware/Software Mapping

The proposed HU property management system is going to be a web based system for all the
users. The system operates within any operating system like windows. As we have tried to
mentioned on the System development tool part, the programming language that we are going to
use for developing the system are: PHP, Scripting language such as Hyper Text Markup
Language (HTML), Cascading Style Sheet (CSS) ,Java Script(JS). For the database management
system we will use MYSQL and web server will run on XampServer. The system consists of
three independent components: Web browser, online System Server and database server.
Internet
Client machine and users
Data base server

(MYSQL)
Web Server
Figure 4.5.1: Hardware/Software mapping

4.6 Persistent data management

Persistent data management deals with how the persistent data such as file, database, etc. are
stored and managed and to outlive a single execution of the system. This Persistent data
management describes the persistent data stored by the system and the data management
infrastructure required for it. The proposed system will use MySQL database for storing data.
This will allow the database to be easily integrated and accessible by the rest of the system.
Information related to asset information detail, stock information detail, user information detail,
and some other related information are persistent data and hence stored on a database
management system to make the proposed system operate consistently. Data management issue
raises the questions, which data need to be persistent, where should persistent data be stored, and
how are they accessed. Persistent data represents a bottleneck in the system on many different
fronts. Most functionality in system is concerned with creating or manipulating persistent data.
For this reason, access to the data should be fast and reliable.

USER ASSET
ACCOUNT USER
FK User ID
1 FK Asset Code
1 PK User ID
PK Account ID
1 1 Frist tName
User Name
Last Name
Password
Sex
Department
Campus
Phone
Address ADDMINSTRATOR
STORE MAN User Name

1 Pass word
PK Store man ID
First Name
Last Lame
Sex
Department
campus
Phone
Address
Transfer
ASSET RECORD
PK Asset Code
PK Asset Code 1
FK User Id
Observer
Name
Asset
Mode lName
Asset code
Type
Quantity
Quantity
MANAGE ASSET Issue Date
Cost
To Owner Fname
Status
Owner Lname
FK Store man ID Expires at
From Owner Fname
FK Asset Code FromOwnerLname
1 Reason
STOCK MANAGER STOCK RECORED
PK Stock Manager ID PK Asset Code
First Name Name

Last Lame Mode lName
Sex Type
Department Quantity
Campus Cost
Phone SafeGard
Address Created At
Updated At
Figure: 4.6.1 persistent data management

4.7 Access control and Security
In HU property managementsystems there are different actors interact with the system. Each
actorshould have different level of authentication to different functionality and data in a system.
For this reason our needs an authentication mechanism to control the data access by different
stake holders as well as users, as it’s information has to be protected from using by unauthorized
users. The security is has to be given attention for data safety. There for the system will ask
every actor or user to Login before performing any operation depending on their level of
authentication given by the Administrator.

To make the system secured we have used the security mechanism to be strong the password like
the number of character must be long and the password must be include special characters, letters
(i.e. capital and small),numbers etc.
Actor/database Administrator Store man Stock manager User

Account Add() Update() Modify() Modify()
Remove()
User record Add()
Remove()
Update()
Delete()
Search()
Asset record View() Add() View()
Update()
Transfer()
Search()
Request record View() View() View() Add()

Approve()
Cancel()
Transfer asset Add() View() View() View()
record Remove()
Update()
Return asset record View() Add() View() View()
View()
Update()
Search()
Stock record View() Add()

Update()
Search()
Store man record Add() View() View()
Remove()
Update()
Stock manager Add() View()

Activity Procedural driven control flow Event driven control flow
record Remove()
Update()
Table 27: Access control flow
4.8 Global control flow
There are two global control policies used in Haramaya university property management system;
these are procedural driven control flow and event driven control flow.
 Procedural driven control flow: The procedural driven control flow supports users of the
proposed system should have to follow on the system procedures and wait for the system to
give response before using anything.
 Event driven control flow: shows what is gone happen when we do external events. Event
driven control flow waits for an external event and when the event occurs, it will be
dispatched to the appropriate object based on information associated.

Login  A user of the system enters username and  To be logged in, the login
password and then it will be authenticated, then button should be pressed.
appropriate page will be displayed.
Register asset  Store man fills the registration form, then the  To register asset, the
asset will get successfully registered. register button is pressed.
Request asset  To send a request for asset, user fills appropriate  To send a request, the
request criteria. request button should be
pressed.
Approve request  Administrator fills approve request criteria, then  To approve a request, the
he/she approve the request. approve request button
should be pressed.
Create account  Administrator fills the creating account criteria,  Press create account button
then he/she will create accounts. to create accounts
Modify account  Authorized user fills the account modification  Press modify account
criteria, then accounts will be modified button to modify accounts
Register Stock  Stock manager fills Record stock criteria, then  press register stock button
he/she record the stock. to register stock.
View Stock  Stock manager fills view stock criteria, then  press view stock button to
he/she view the stock in the store. view the stock.
Transfer asset  Administrator fill the criteria to transfer asset,  press transfer asset button
then he/she transfer the asset. to transfer the asset.
Calculate depreciation  Store man fill criteria to calculate depreciation,  press calculate depreciation
then he/she calculate depreciation. button to make
depreciation.
Table: 28 Global control flows
4.9 Boundary Condition

The Property Administrator manages the web server using the appropriate administrator account
that enables him/her to Create, modify and remove account. After registration user can login to
the system. Each user who has an account can log into the system to perform their task like
Request asset, to view available asset and modify account. The system is not expected to be
started and shutdown at all times rather the system should be available all the time to different
services. But when some conditions like maintenance, security purpose and some failure occurs
the system will be shutdown and will start up again.
The following tables show different boundary conditions of Haramaya university property
management system.
Boundary condition for start up the system

Name Start Haramaya university property management system
Actor Property administrator
Entry condition Haramaya universityXamp server launch
Flow of events 1. The Property administrator launches the Xamp server
2. The Property administrator start up the Haramaya university property
management system.
3. The system launches the MySQL server
Exit condition Exit when both the MySQL and Xamp servers have been launched and are
running.
If either server fails to launch, a diagnostic message is displayed and the

Exceptions appropriate error log is updated.
Special The property administrator must have appropriate access level to control
requirement Haramaya university property management system.
Table: 29Boundary condition for start up the system

Boundary condition for Shutdown the system
Name Shutdown Haramaya property management system

Actor Property administrator
Entry condition Haramaya university property management system on running
condition.
Flow of events 1. The system intimate the MySQL server
2. The system then also initiate the Apache server
3. The propertyadministrator clicks on shutdown the system
4. Confirmation for shut down displayed
5. Click on shutdown the system.
Exit condition The system shut down when all the connections are cancelled.
Special The administratormust have the appropriate access level to shut down
requirement the system.
Table: 30Boundary condition for Shutdown the system
Reference

[1] Brueghel, Bernd (2000).Object oriented Software Engineering Conquering Complex and
Changing System. Upper Saddle River: Prentic Hall.
[2] R.Wirfs-Brock, B.Wilkerson,& Lauren Wiener. (1990).Designing Object-Oriented Software.

Englewood Cliffs: Prentice Hall.
[3] Ethiopian government property administration. (n.d).retrieved November 10, 2016, from
http://www.haramaya.edu.et/wp-content/downloads/Finance/Property.pdf
[4] Class Diagram Tutorial. (n.d).retrieved December 29, 2016, from

https://www.lucidchart.com/pages/uml/class-diagram/.html
[5] Class Diagram for Online Shopping System (UML). (n.d).retrieved January 5, 2017,
from https://www.lucidchart.com/pages/class-diagram-for-online-shopping-system-
UML.html
[6] The Ethiopian Federal Government Procurement and Property Administration

Proclamation. (n.d).retrieved November 7, 2016, from
https://www.lucidchart.com/pages/class-diagram-for-online-shopping-system-UML.html

Property Management System

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Property Management System

Uploaded by

Copyright:

Available Formats

Haramaya University

College of Computing and Informatics

Haramaya University Property Management System

Group MembersID Number

3. Abebaw Sete ---------------------------1671/06

4. Meaza Lema ----------------------------1715/06

Advisor: Dr. Feizur R.

Department of Computer Science Page i

MySQL: My Structured Query Language

CSS: Cascading Style Sheet

OS: Operating System

HTML: Hyper Text Mark-up Language

HUPMS: Haramaya University Property Management System

UML- Unified Modeling Language

CPU: Central Processing Unit

RAM: Random Access Memory

UCI: Use Case Identification

IEAM: Imperial College of Agricultural and Mechanical Arts

XAMPP: Cross-Platform Apache MariaDB PHP and Perl

PK: Primary Key

FK: Foreign Key

Department of Computer Science Page ii

Department of Computer Science Page iii

Department of Computer Science Page iv

Department of Computer Science Page v

Figure 3.2.1 Class diagram ........................................................................................................... 29

Department of Computer Science Page vi

Department of Computer Science Page vii

Generally, at Haramaya University, each university employee has a general obligation to

Department of Computer Science Page 1

1.1 Background of the organization

Department of Computer Science Page 2

1.2 Review of Related Work (Literature Review)

Property management at Stanford University is an integral process supported by all departments.

1.3. Statement of the problem

 It’s difficult to get information from the previous document.

Department of Computer Science Page 3

1.4.2 Specific Objective

 To develop user friendly interface.

Department of Computer Science Page 4

1.5.2 System Development Methodology

1.5.3 System Development Tool

Operating System:-we use windows operating system for our project.

Department of Computer Science Page 5

1.6 Scope and Limitation

The proposed system includes:-

 To record new stock to system

 Reduce the amount of resources that are wasted.

Department of Computer Science Page 6

1.8 Work break down

Table 1: work break down

Department of Computer Science Page 7

2.1 Existing System

Department of Computer Science Page 8

2.2 Proposed System

2.2.2 Functional Requirement

Functional Requirement id1:

Functional Requirement id2:

Functional Requirement id3:

Functional Requirement id4:

Department of Computer Science Page 9

Functional Requirement id6:

Functional Requirement id7:

 The system should able to allow the administrator to manage accounts.