DMU EMPLOYEE’S SAVING AND CREDIT

ASSOCIATION INFORMATION MANAGEMENT SYSTEM

PROJECT REPORT
Submitted by
Name ID
1. Awoke Kerebh…………………………………………TER/4646/07
2. Zewdineh Bawoke……………………………………..TER/4704/07
3. Jenet Sultan ……………………………………………..TER/4668/07
4. Hymanot Ewunetie……………………………………..TER/4666/07
In partial fulfillment for the award of the degree of
BACHELOR OF SCIENCE IN INFORMATION TECHNOLOGY
Under the guidance of
Teshome F
……………………
Signature

DEPARTMENT OF INFORMATION
TECHNOLOGY

COLLAGE OF TECHNOLOGY

DEPRE MARKOS UNIVERSITY

DBRE MARKOS
January, 2010 E.

2
 Abstract
The purpose of this project is to develop a Web Based employee’s saving and credit association
information management System for Debre markos University, the system reduces the time and
labor required to provide services, Reduce the error that made by the employees, change the
manual storage mechanisms into computerized system (database), provide fast, efficient,
flexible, reliable and secured services for better satisfaction of customers and improves the
motivation of the employees. The existing system of the organization is facing different
problems such as data redundancy, lack of data security and lots of paper work. To solve this
problem the project team used different data collection methods such as Interview, Document
analysis and Practical observation. In order to analyze and design the system we used Object
oriented approach for both analyzing and designing the new system.
To change the current manual system to a web based, needed different software and hardware
tools such as PHP, MYSQLI and others

i
 Acknowledgment
First of all we would like to thank GOD for making us able to perform our tasks well, without
the will of GOD everything is impossible. We have a great thanks and appreciation to our
advisor Teshome F for his excellent advice and supervision.
Next we’d like to thank our classmates and friends for their wellness to give important
information and ideas for us. And also we would like to thank association employees for their
good approach at interview time and wellness at giving important information for us.
Generally we will extend our thanks and appreciation to all individuals that give important
information to us.

ii
Table of Contents
Abstract........................................................................................................................................................i
Acknowledgment.........................................................................................................................................ii
Acronym......................................................................................................................................................v
List of tables...............................................................................................................................................vi
List of figures.............................................................................................................................................vii
CHAPTER ONE..........................................................................................................................................1
1. INTRODUCTION..................................................................................................................................1
1.1 Introduction.....................................................................................................................................1
1.2 Background of the project................................................................................................................1
1.3 Problem statement...........................................................................................................................1
1.4 Objective of the project...................................................................................................................2
1.4.1 General objective........................................................................................................................2
1.4.2Specific objective........................................................................................................................2
1.5 Scope of the project.........................................................................................................................3
1.6 Significance of the project...............................................................................................................3
1.7 System requirement.........................................................................................................................4
1.7.1 Hardware requirement................................................................................................................4
1.7.2 Software requirement..................................................................................................................4
1.7.3 Programing language..................................................................................................................4
1.8 Data collection methodology...........................................................................................................5
1.8.1 Design Methodology............................................................................................................5
1.8.2 Data gathering technique...........................................................................................................5
1.9 Feasibility study...............................................................................................................................6
1.9.1 Operational feasibility.................................................................................................................6
1.9.2 Economic feasibility...................................................................................................................6
1.9.3 Technical feasibility....................................................................................................................6
1.9.4 Legal feasibility..........................................................................................................................6
CHAPTER TWO.........................................................................................................................................7
2. SYSTEM ANALYSIS...........................................................................................................................7
2.1 Overview of the existing system........................................................................................................7
2.2 System requirement specification......................................................................................................8

iii
 2.2.1 Functional requirement...............................................................................................................8
2.2.2 Nonfunctional requirement.........................................................................................................9
2.2.3 Business rule...............................................................................................................................9
2.3 System requirement analysis...........................................................................................................10
2.3.1 Actor and use case identification..............................................................................................10
2.3.2 Use case diagram......................................................................................................................15
2.3.3 Use case description.................................................................................................................17
2.3.4 Sequence diagram.........................................................................................................................23
2.3.5 Activity diagram...........................................................................................................................29
2.3.6 Analysis class diagram..............................................................................................................33
CHAPTER THREE...................................................................................................................................35
3. SYSTEM DESIGN................................................................................................................................35
3.1 Design class diagram.......................................................................................................................35
3.2. Class diagram description...............................................................................................................37
3.3 Database design...............................................................................................................................39
3.3.1Physical data model...................................................................................................................40
3.4 User interface design.......................................................................................................................42
3.5 System architecture (deployment design)........................................................................................47
CHAPTER FOUR.....................................................................................................................................48
4 IMPLEMENTATION...........................................................................................................................48
4.1. Over view of the programming language used...............................................................................48
4.2 Algorithm used................................................................................................................................48
4.3 sample code.....................................................................................................................................49
CHAPTER FIVE.......................................................................................................................................55
5 CONCLUSION AND RECOMMENDATION...................................................................................55
5.1 Conclusion.......................................................................................................................................55
5.2 Recommendation and future enhancement......................................................................................55
Reference...................................................................................................................................................57

iv
 Acronym
CPU central processing unit
CSS cascade style sheet
DMU Debre Marko’s University
GB giga byte
GHZ giga hertiz
GUI graphical user interface
HRM human resource management
HTML hypertext markup language
PHP Hyper Text Pre processor
RAM random access memory
UC Use Case
UML unified model language

v
 List of tables
Table 1 use case identification...................................................................................................................12
Table 2 use case description for login........................................................................................................17
Table 3 use case description for register customer....................................................................................18
Table 4 use case description for create user account..................................................................................19
Table 5 use case description for send loan request....................................................................................20
Table 6 use case description for approve loan request...............................................................................21
Table 10 description of customer class.....................................................................................................37
Table 11 description of admin class...........................................................................................................38
Table 12 description of manager class.......................................................................................................38
Table 13 description of loan table.............................................................................................................39
Table 14 description of request table.........................................................................................................39
Table 15 employee table............................................................................................................................40
Table 16 customer table.............................................................................................................................41
Table 17 response table.............................................................................................................................41
Table 18 meeting table..............................................................................................................................42
Table 19 feedback table.............................................................................................................................42

vi
 List of figures
Figure 1 use case diagram.........................................................................................................................16
Figure 2 sequence diagram for login.........................................................................................................24
Figure 3 sequence diagram for register customer......................................................................................25
Figure 4 sequence diagram for create account...........................................................................................26
Figure 5 sequence diagram for send loan request......................................................................................27
Figure 6 sequence diagram for view balance.............................................................................................28
Figure 7 Activity diagram for login...........................................................................................................29
Figure 8 Activity diagram for create account............................................................................................30
Figure 9 Activity diagram for send loan request........................................................................................31
Figure 10 Activity diagram for view balance............................................................................................32
Figure 11 Analysis class diagram..............................................................................................................34
Figure 12 design class diagram..................................................................................................................36
Figure 13 login page..................................................................................................................................43
Figure 14 admin page create account.........................................................................................................44
Figure 15 register customer.......................................................................................................................45
Figure 16 send request...............................................................................................................................46
Figure 17 deployment design.....................................................................................................................47

vii
CHAPTER ONE
1. INTRODUCTION

1.1 Introduction

As we know today, the world is in technological area so the world is being coming to one
village. As a result, we should to develop an automated system for Debre Marko’s university
credit association management system.
Debremarkos university employee’s saving and credit association is an organization under the
control of Debremarkos university employees that provides saving and credit services for
employees in the university that wants to use the services. The association manages different
employees like accountants, cashers, and other members
This system provided service to employees of Debre Marko’s university for saving and loan
money. In once credit association the using of money must be performed properly.

1.2 Background of the project

Debre Marko’s university employee’s saving and credit association was initially established in
JUNE 1999 E.C. at the time of establishment there were 77members. The current number of
members in the association is 1023.Among those members 319 are females and 704 are males.
At the beginning of the association there were no regular accountants, among the members of the
association candidates accountants were working. Currently there are 2 regular accountants.
The project is helpful to keep detail information about members, keep record of all modification
and it provides security using login form and using encryption mechanism that are not done in
the existing system. The system what we are going to develop solves the problems of the existing
systems work

1.3 Problem statement

There are many problems in Debre markos university employees ‘saving and credit association
of the existing system since every processes are paper based and users information are copied

1
more than one paper. Generally processing user information in the existing system takes excess
time, costs and effort.

Some of the problems are:

 The customer can’t easily view his/her balance:- since the system is paper based it
is difficult to view balance easily

 Difficult to shares information easily in the association:- information sharing

among parents is time consuming

 Post meeting date is difficult and time consuming:- because the meeting date must
be uploaded on different areas of the campus in order to late the members it

 Transaction report is presented two times within a year :- since it is paper based it is
difficult to present report monthly

 Calculating loan and deposit interest is difficult and not free from errors:-because
all the calculation processes are performed by the accountant so errors may be
occurred

 Giving response for loan request takes long time:-since there are many processes to
response for loan request it is time consuming by the current system

 The customer must be registered on three papers:-used to protect data from lost

1.4 Objective of the project

1.4.1 General objective

The general objective of the proposed system is to develop web based employee’s saving and
credit association information management system for Debre Marko’s university.

1.4.2Specific objective
The specific objectives of the proposed system is list of objectives that are useful to achieve the
general objectives

 To develop a system that registers and modifies member information easily.

2
  To develop a system that calculate loan and deposit interest easily
 To develop a system that can generate monthly report
 To develop a system that shares information easily in the association
 To develop a system that provides fast services.
 To develop a system that makes members able to view their balance easily.
 To develop a system that makes members to send requests easily.
 To develop a system that makes members to view response easily.

1.5 Scope of the project

The scope of the project covers the development of web based employee’s saving and credit
association information management system in Debre Markos University.

The proposed system supports only employees that are working in Debre Marko’s University to
be a member and get service like request loan and deposit money.

The proposed system performs different tasks some of are:

 Register new member

 Send loan request
 View response
 view balance
 Provide information to the users/generate report
Limitation

 The system do not have a link with bank

1.6 Significance of the project

The significance of a project can be categorized into different areas depending up on to whom
the benefit goes.

3
For Customer

 Reduce the time and labor required to get services from the association.
 To give/accept necessary information easily.
 It enhances accuracy, speed, and security of services.
 For their better satisfaction with fast services provided by the employees
 Enables the user to interact with the system easily because the system is user friendly

For employees

 The system takes the calculate loan and deposit interest tasks that are performed by the
employees in the existing system
 reducing the broad manual work

For association

 Reduce the cost because of reduced number of employee.

 The system makes the association database accurate and secured.

1.7 System requirement

System requirements are the hardware and software components of a computer system that are
required to do the proposed system and simply identify tools and methodology

1.7.1 Hardware requirement

Hardware requirements are the physical part that can be touchable and visible components that
are necessary to develop a system. The hardware required to develop the proposed system are:

Personal computer (PC): almost all tasks of our project are performed on computer.

4
RAM 4GB: To store the file temporarily

CPU Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz: used to process instruction

Hard disk: store large file permanently

1.7.2 Software requirement

The software requirements are the instructional components used to develop a system. Software
requirement to develop system are as follows:

Windows 7: will be used for the system since it is readily available more compatible in
laboratories.
MYSQLI server:-for designing the database
Microsoft office Word:-for documenting the corresponding deliverables associated with the
project
Microsoft office Visio: -to design Unified Modeling Language (UML) diagrams.
GUI software: - to draw user interface of the system.
WAMP Server: -to test the system by running.

1.7.3 Programing language

Programming language is important to complete the system in the best way and to make it good,
easy and interactive with the customer.

The programming languages required to develop a system are:-

PHP: because it is

 Easier to fix problems-PHP indicates easily where the problem occurred

5
  Increased efficiency & usability - PHP provides incomparable efficiency and usability
when it is used for the development of websites.

 Compatible- PHP is compatible on all operating systems including Windows and UNIX-
among other systems.

 Data processing - A website that has been developed using the PHP functions has fast
features of data processing.
 Easy to understand - When compared with other scripting languages, PHP can be
understood easily because it has simple techniques and features.

Html:-to display the web page.

CSS:-for the formatting of the system.
Java Script: for data validation

1.8 Data collection methodology

Data collection methodology is the systematic approach to gathering and measuring information from a
variety of sources to get a complete and accurate picture of an area of interest

1.8.1 Design Methodology

To design the system, the project team has chosen Object Oriented Modeling techniques and
unified modeling language tools. Reason for choosing:

It enables us to comprehensively model a system before we develop it.

Modification of the object implementation is easy because objects are loosely coupled.

Understanding of the structure is easy because object oriented modeling and tools used to
represent real world entities.

1.8.2 Data gathering technique

1.8.2.1 Interview

6
We made an interview questions with the employees of debre markos university employee’s
saving and credit association to get information that are useful for developing our system.
1.8.2.2 Observation
We observed the working mechanism of the existing system
1.8.2.3 Document analysis
We read the document which is prepared by the association that explains about the association
feature.

1.9 Feasibility study

It is an analysis of the ability to complete a project successfully, taking into account legal,
economical, technological, operational and other factors.

1.9.1 Operational feasibility

It is the measure of how well the solutions for problems will work in the association.
The project will be beneficial because it satisfies the objectives when developed and used. And
as well the new system brings an easy and user friendly working environment that helps the
employees get services from anywhere as well as the association workers to handle tasks easily.

1.9.2 Economic feasibility

Economic feasibility is the analysis of a project's cost benefit analysis in an effort to determine
whether or not it is logical and possible to complete. Our proposed project is economically
feasible because it has less expensive when compared to the existing system, so the project helps
in reducing the cost.

1.9.3 Technical feasibility

It’s a measure of whether the proposed system is user friendly and enables users to maintain
when problems occur or not.

7
Our system is technically feasible due to the following reason:-

 Member can adapt the system easily.

 No need of much more skill
 Developed with in the latest technology.
 Users can maintain problems easily.

1.9.4 Legal feasibility

We need to make sure that the proposed project will meet all legal and ethical requirements of
the project are applied. The system we are going to developed is not conflict with any
government directives or cannot interfere with any political issue and with any cultural aspects.
So our project is legally feasible

CHAPTER TWO
2. SYSTEM ANALYSIS

2.1 Overview of the existing system

How the existing system works?

In the existing system generating the overall report of the organization is done manually and also
the association accepts feedback from customer only on the meeting date because of manual
working.

The accountant in the association registers customer and their information such as customer
name, phone number, occupation, address. The customer saves money monthly according to
his/her income by agreement with the association. There are forms available for customer to be
filled by their information such as their name, address, and account number and so on, when they
want to save or take loan money.

8
To request for loan the customer must go to the HRM enters applicant, and then go to the
association and asks for loan, the accountant in the association register the request and forwards
it to the loan committee, according to the customer capacity to loan the loan committee approve
or deny the request and forwards the response to the main committee, the main committee
forwards it to the manager and the manager forward to accountant, the accountant gives loan
money for the customer if the request is approved. The accountant calculates the saving and loan
interest rate for the customer of the association.

To request for withdraw the customer must go to the association, the accountant in the
association register the request and forwards it to the manager and send back to accountant.

In general, the existing system of DMU employee’s saving and credit association is difficult to
access and manage customer’s account because all the activities are done manually.

Users of the existing system

 Manager: a person who manages and coordinates the system activities.

 Loan committee: to approve or deny loan request
 Accountant: a person who calculate saving and loan interest rate, generate report, register
customer
 Customer: The people who get service like loan money, deposit money and withdrawal
money from the association.
 HRM officer: To check the customer is the member of university and free from loan at
the time of loan request
 Finance officer: Snip from salary for deposit and loan.

2.2 System requirement specification

A System Requirements Specification (SRS) is a document or set of documentation that
describes the features and behavior of a system or software application. It includes a variety of
elements that attempts to define the intended functionality required by the customer to satisfy
their different users. In addition to specifying how the system should behave, the specification

9
also defines at a high-level the main business processes that will be supported.[ CITATION 2 \l 1033
]

2.2.1 Functional requirement

Functional requirement is described as what the system is done by identifying the necessary task,
action or activity that must be accomplished. User requirement that are all about the functionality
of the system. These kinds of requirement are directly related to the system, to user, and
stockholders. [ CITATION 3 \l 1033 ]

The proposed system has the following functional requirements:-

 Accountant register new customer

 Accountant registers loan money.
 Accountant updates customer information up on it required.
 System calculate interest rate for loan and deposit money
 Customer view their balance
 Manager announces meeting date.
 Accountant view report such as amount of deposit money, amount of loan money,
amount of customer.
 Manager view report such as amount of deposit money, amount of loan money, amount
of customer.
 Customer send feedback
 System administrator block user
 System administrator register employee
 Customer send loan request
 Manager view withdraw request
 Manager view approve loan request
 Accountant view approve loan request checked by manager
 Loan committee view loan request

10
 2.2.2 Nonfunctional requirement

Non-Functional requirement explains and describes requirements that support the system but
they are not part of the system functionalities. Generally nonfunctional requirements describe the
quality of the system.

Technical requirement

Technical requirements are the technical issues that must be considered to successfully complete
a project.

Availability: - the customer to access the system at any time 24/7 hour.
Performance: Since the system is web based the deliver response time of the system should be
very fast. It perform its activity that are relating to the vote is accurately.

Speed: -The system has quick response time.

Security- this system has user name and password to login to the system for perform the tasks
and also the data base uses the encryption methods in order to protect the data.

Effectiveness- can user’s complete task, achieve goals with the product

Error handling: - This system allows minimize error by displaying the message box or the system warns
the users who make errors.

2.2.3 Business rule

A business rule is an operating principle or policies that must be fulfilled in order to the system
function properly and effectively. It often pertain to access control issues, business calculations,
or operating polices and principles of the organization.

11
  BR1: when customers want to get service they must be registered first to the association
 RB1: the customer before send loan request applicant in human resource management
 BR3: the minimum amount of money to loan is 50 birr
 BR4: In order to get loan the loan request must be approved by the loan committee
 BR5: the customer must be an employee of this university
 BR6: the customer can’t take loan more than ones until it repays 1/3 of the loan
 BR7: the maximum amount of loan money the member can take is 5times of the
deposited money.

2.3 System requirement analysis

2.3.1 Actor and use case identification

Actor identification

An actor represents anything or anyone that interacts with your system. This may include people,
external systems, and other organizations.

List of actor:

 System Administrator: controls the overall system

 Manager
 Loan committee
 HRM officer
 Finance officer
 Accountant
 Customer

12
 Use case identification

A use case describes a sequence of actions that provide something of measurable value to an
actor

Use case name Use case ID Include

Login UC1
Register employee UC2 Login
View feedback UC3 Login
Manage account UC4 Login
View employee UC5 Login
View new customer UC6 Login
View meeting date UC7 Login
Change password UC8 Login
Back up DB UC9 Login
Restore DB UC10 Login

13
View log file UC11 Login
Post meeting date UC12 Login
View withdraw request UC13 Login
View loan close request UC14 Login
View approve loan UC15 Login
Revise meeting date UC16 Login
View monthly report UC17 Login
Register customer UC18 Login
Register repay money UC19 Login
Register issue money UC20 Login
Send report for deposit UC21 Login
Update customer info UC22 Login
View customer UC23 Login
View notification UC24 Login
View receipt UC25 Login
UC26 Login
View reported response
UC27 Login
View loan request
UC28 Login
Approve loan request
Reject loan request UC29 Login

Register debtor UC30 Login

Register representative UC31 Login

View debtor UC32 Login

View representative UC33 Login

Transfer money UC34 Login

View deposit report UC35 Login

View loan report UC36 Login

Send request UC37 Login

14
cancel request UC38 Login

View response UC39 Login

View balance UC40 Login

Approve withdraw request UC41 Login

Reject withdraw request UC42 Login

Logout UC43 Login

Table 1 use case identification

Actor: system Administrator:

 Register employee
 View employee
 Manage account
 View new customer

15
  Back up DB
 Restore DB
 View log file
 view feedback
 view meeting date
 Change password

Actor: manager:

 post meeting date

 View withdraw request
 View loan close request
 View approve loan
 Approve withdraw request
 Reject withdraw request
 Revise meeting date
 View monthly report
 View feedback
 View employee
 Change password

Actor: accountant:

 register customer
 register repay money
 register issue money
 send report for deposit
 view monthly report

16
  update customer information
 view customer
 view approved request
 view notification
 view receipt
 view reported response
 view meeting date
 view feedback
 change password

Actor: customer

 send request
 cancel request
 view response
 view balance
 send feedback
 view meeting date
 change password

Actor: loan committee

 view loan request

 approve loan request
 reject loan request
 view meeting date
 change password

Actor: HRM officer

17
  register debtor
 register representative
 view debtor
 view representative
 change representative
 change password

Actor: finance officer

 view deposit report

 view loan report
 transfer money
 view feedback
 change password

2.3.2 Use case diagram

A use case diagram is a graphic depiction of the interactions among the elements of a system. 

Use case diagrams consist of actors, use cases and their relationships. The diagram is used to
model the system/subsystem of an application.[ CITATION 4 \l 1033 ]
 Boundary: - indicates the scope of your system.
 Actors: - An actor is a person, organization, or external system that plays a role in one or
more interactions with your system.
 Use cases, which the specific roles are played by the actors within and around the system.
18
 relationships:- relationships between actors and the use cases

19
Figure 1 use case diagram

20
 2.3.3 Use case description
Table 2 use case description for login

Use case name Login

ID UC1
Actor System admin, manager, accountant, customer, finance officer,
HRM officer, loan committee
Description The user enters authorized username and password in order to
access the system.
Precondition The user should have username and password.
Post condition The user successfully login to the system
Basic course action User action System response
1. Open home page.
2. Display the login page with
3. Enter the authorized login form.
username, password in the
login form.

4. Click on login button 5. Check the authorized

username, password.

6. If the username, password and

role is correct login in the system.

Alternative course of action A: if step 3 is invalid

A1: check the user have user name and password
A2: restart from step 3

Table 3 use case description for register customer

Use case name Register customer

21
 ID UC18
Actor Accountant
Description The accountant register new customer to the system
Precondition The accountant must login to the system
Post condition Display message that indicates the success
of the operation
Basic course action User action System response
1. Login in the system. 2 Display accountant page.

3. Open customer
registration page. 4. Display customer registration
page.
5. Enter the appropriate
information on the form.

6. Click on register button. 7. Check the filled information.

8. If the filled information is

correct the system registers the
new customer in the system
database and display successful
message.

Alternative course of action A: If the filled information is incorrect

A1: the system display error message
A2: restart from step 5

Table 4 use case description for create user account

Use case name Create user account

ID UC4
Actor System administrator
Description The admin creates user name and password for users
Precondition Admin first login to the system

22
 Post condition Successfully create account
Basic course action User action System response
1. login in the system 2 Display admin page
3. Open the create account 4.Display create new account
page. form

5. Fill use name and

password.

6. Click on create button. 7. Check the filled information on

the form.

8. If the filled information is

correct the system saves on the
system database.

Alternative course of action A: system display ‘’account is not created message’’.

A1: repeat from step4.

Table 5 use case description for send loan request

Use case name Send loan request

ID UC37
Actor customer
Description Send request for loan by specifying the amount of money it
requires
Precondition The customer must login to the system
Post condition Successfully send request
Basic course action User action System response

23
 1. first the customer login
2 Display customer page
to his page

3. Open a page for Loan 4. Display Loan Request form.

Request. .

5. Fill the appropriate

information on the form. 6 Check the filled information on
the form
7. Click on request button.

8. If the filled information is valid

the system displays successful
message.
Alternative course of action A: If the customer did not fulfill the requirement

A1: system display error message

A2: restart from step 4.

Table 6 use case description for approve loan request

Use case name Approve loan request

ID UC28
Actor Loan committee
Description Receive customer requests , the system check the conditions
and accept or reject the request
Precondition The loan committee must login to the system
Post condition Successfully see the request
Basic course action User action System response
1. Login in to the system. 2 Display the loan committee
page.
3. Open view loan request

24
 page. 4. Display the loans request table.

5. loan committee click

status button
6. If the request
information is fulfilling the
criteria the system accept
the request.

Alternative course of action A: If the request information is not fulfilling the criteria
A1: the system reject the request

Table 7 use case description for view report

Use case name view report

Id Uc17
Actor Accountant, manager
Description View monthly activity in the association
Pre-condition Accountant, manager login to the system
Post condition Display monthly report
Basic course action User action System response
1. login to the system
2.display accountant,
3. click view report manager page
button
4. display report button
5. Click report button

25
 6. display monthly report

Table 8 use case description for view balance

User case name View balance

Id Uc40
Actor customer
Description customer wants to view their balance
Precondition customer first login to the system
Post condition View necessary balance
Basic course of action User action System response
1.login to the system
2.display customer page
3.click view balance button
4. display balance

26
 2.3.4 Sequence diagram
Sequence diagrams are used to formalize the behavior of this system and to visualize the
communication among objects. The diagrams show the flow of messages from one object to
another, and as such correspond to the methods and events supported by a class/object. These
typically show a user or actor, and the objects and components they interact with in the execution
of a use case. A sequence diagram is a Unified Modeling Language (UML) diagram that
illustrates the sequence of messages between objects in an interaction. A sequence diagram
consists of a group of objects that are represented by lifelines, and the messages that they
exchange over time during the interaction.[ CITATION 5 \l 1033 ]

27
user login form login controller user page database

1: open home page

2 enter um and pw
3 validate
4 invalid
5 refill form

6 valid

7 validate
8 invalid
9 refill form

10 valid
11 display

28
Figure 2 sequence diagram for login

29
 login form Register form
accountant login controller accountant page register link register form
controller
database

1. open home page

2: enter un and pw
3 ckeck validate

5 refill form 4 invalid

6 ckeck

7 invalid
8 refill form

11 display page 10 valid

12 click register link

13 fill form 14 validate

16 refill form 15 invalid

check
17 click register button
19 refill form 18 invalid

20 display seccefull message

Figure 3 sequence diagram for register customer

30
 Create account Create account Create account
Admin login form login controller admin page database
link form Form controller

1. open home page

2: enter un and pw
3 ckeck validate

5 refill form 4 invalid

valid 6 ckeck
7 invalid
8 refill form

11 display page 10 valid

12 click create account link

13 fill form 14 validate

16 refill form 15 invalid

17 check

18 invalid
19 refill form

20 display seccessful message

Figure 4 sequence diagram for create account

31
 Send loan Send loan Send loan
customer login form login controller customer page database
link form Form controller

1. open home page

2: enter un and pw
3 ckeck validate

5 refill form 4 invalid

valid 6 ckeck
7 invalid
8 refill form

11 display page 10 valid

12 click send loan link

13 fill form
14 validate

16 refill form 15 invalid

17 store in DB

18 display seccessful message

Figure 5 sequence diagram for send loan request

32
 View balance
customer login form login controller Customer page database
link

1. open home page

2: enter un and pw 3 ckeck validate

4 invalid
5 refill form

valid 6 ckeck

7 invalid
8 refill form

10 valid
11 display page

12 click view balance link

13 display balance

Figure 6 sequence diagram for view balance

33
 2.3.5 Activity diagram

Activity diagram is UML behavior diagram which shows flow of control or object flow with
emphasis on the sequence and conditions of the flow. An activity diagram visually presents a
series of actions or flow of control in a system similar to a flowchart or a data flow diagram.
[ CITATION 5 \l 1033 ]

Activity diagrams are often used in business process modeling

Some of the activity diagrams of the project known as DMU employee’s saving and credit
association information management system are:

34
 Actor open home page

enter uesr name and password

Actor click login button

valid invalid
display actor page
CreatedCreated
by TrialCreated
by
Version
Trialby
Version
Trial Version

check display error message

Figure 7 Activity diagram for login

35
 admin open home page

enter user name and password

admin Click login button

CreatedCreated
by TrialCreated
by
Version
Trialby
Version
Trial Version
invalid
check system display error message

valid

system display admin page

Admin click create account link

system display create account form admin fill form and click create account

Created Created
by TrialCreated
Version
by Trialby
Version
Trial Version
invalid fill
system display error message
check

valid

system display successful message

Figure 8 Activity diagram for create account

36
 Customer open home page

enter username and password

click login button

invalid
Created Created
by TrialCreated
Version
by Trial by
Version
Trial Version

check the system display error message

valid

System display customer page

Customer click send loan link

Customer fill form and click send

System display send loan form

Created Created
by TrialCreated
Version
by Trial by
Version
Trial Version

invalid
check the system display invalid message

valid

system display successful message

Figure 9 Activity diagram for send loan request

37
 Customeropen home page

enter username and password

click login button

Created Created
by TrialCreated
Version
by Trialby
Version
Trial Version

invalid
check the system display error message
valid

System display customer page

Customer click view balance link

system display customer balance

Figure 10 Activity diagram for view balance

38
 2.3.6 Analysis class diagram

The class diagram in the unified modeling language is a type of static structure diagram that
describes the structure of a system by showing the system's class, their attributes, operations (or
methods), and the relationships among objects.

The class diagram is the main building block of object oriented modeling. Classes in a class
diagram represent both the main elements, interactions in the application, and the classes to be
programmed[ CITATION 5 \l 1033 ]

39
Figure 11 Analysis class diagram

40
 CHAPTER THREE
3. SYSTEM DESIGN
System design is the first part to get into the solution domain in a software development.
The purpose of designing is to 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 that 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.

3.1 Design class diagram

The class diagram represents the static view of an application. Class diagram is not only used for
visualizing, describing and documenting different aspects of a system but also for constructing
executable code of the software application. The class diagram describes the attributes and
operations of a class and also the constraints imposed on the system. The classes diagrams are
widely used in the modeling of object oriented systems because they are only UML diagrams
which can be mapped directly with object oriented languages. The class diagram shows a
collection of classes, interfaces, associations, collaborations and constraints. It is also known as a
structural diagram for this the team developed the following class diagram.

41
Figure 12 design class diagram

42
3.2. Class diagram description
Table 7 description of customer class

Customer class attribute

Attribute purpose Type

Account no To uniquely identify the customer varchar
Fname To represent the first name of the customer varchar
mname To represent the father name of the customer varchar
lanme To represent the grandfather name of the customer varchar
Sex To identify the customer’s gender varchar
Age To represent how old the customer is int
photo To represent the photo graff of the customer longtext
customerid To represent university id varchar
Deposit amount To represent monthly deposit amount float
Share amount To represent amount of share to buy at the member float
date To represent customer registration date date

Customer class method

Method Description
Send Used to send request and send feedback
view Used to view response and balance

Table 8 description of admin class

Admin attribute

Attribute Purpose Type

aid Uniquely identify the admin varchar
fname To identify first name of admin varchar

43
mname To identify father name of admin varchar
role To identify the role of admin varchar
photo To represent photo graf of admin longtext
Mobile phone To identify mobile phone number of admin varchar
Admin method

Method Description
Add Used to vote and register user
Block Used to block users from access
View Used to view employee
Create Used to create account to users

Table 9 description of manager class

Manager attribute

Attribute Purpose Type

aid Uniquely identify the manager varchar
fname To identify first name of manager varchar
mname To identify father name of manager varchar
role To identify the role of manager varchar
photo To represent photo graf of manager longtext
Mobile phone To identify mobile phone number of manager varchar

Manager method

Method Description
Post Used to post meeting date to users of association
View Used to view customer request and others

Table 10 description of loan table

Attribute Purpose Type

loanid Uniquely identify the loan int
accountno To identify account number of customer varchar
amount To identify amount of loan float
date To identify date of register loan date

44
Table 11 description of request table

Attribute Purpose Type

Requestid Uniquely identify the request int
accountno To identify account number of the customer varchar
Request type To identify type of request varchar
amount To identify amount of money float
Repayment year To represent year to repay the loan to shinishing int
reason To identify reason in what purpose to send varchar
request

3.3 Database design

Physical database design translates the logical data model into a set of SQL statements that
define the database. For relational database systems, it is relatively easy to translate from a
logical data model into a physical database. Rules for translation:

 Entities become tables in the physical database.

 Attributes become columns in the physical database. Choose appropriate data type for
each of the columns.
 Unique identifiers are not allowed to have NULL values. These referred to as primary
keys in the physical database. Consider creating a unique index on the identifiers to
enforce uniqueness.
 Relationships are module as foreign keys

3.3.1Physical data model

A physical database model shows all table structures, including column name, column data type,
column constraints, primary key, foreign key, and relationships between tables. Features of a
physical data model include: Specification all tables and columns. Foreign keys are used to
identify relationships between tables.

Table 12 employee table

45
Table 13 customer table

46
Table 14 response table

Table 15 meeting table

47
Table 16 feedback table

3.4 User interface design

User Interface (UI) Design focuses on anticipating what users might need to do and ensuring that
the interface has elements that are easy to access, understand, and use to facilitate those actions.

UI brings together concepts from interaction design, visual design, and information architecture.

48
Figure 13 login page

49
Figure 14 admin page create account

50
Figure 15 register customer

51
Figure 16 send request

52
3.5 System architecture (deployment design)

A UML deployment diagram depicts a static view of the run time configuration of hardware
nodes and the software components that run on those nodes. UML deployment diagrams show
the hardware for your system, the software that is installed on that hardware, and the middleware
used to connect the disparate machines to one another[ CITATION 5 \l 1033 ]

Figure 17 deployment design

53
 CHAPTER FOUR

4 IMPLEMENTATION
4.1. Over view of the programming language used

This project used php server side programming technology integrated mysqli database with a
programming language. Because:

The code and its syntax is simple to understand

There is a wealth of online information regarding PHP

It's quick to develop in PHP

PHP is flexible.

It's available for free

It runs on many different operating system easy to access other web based tools through PHP
(i.e. Google)

In general PHP is a widely used open source general purpose scripting language that is especially
suited for web development and can be embedded into HTML.

4.2 Algorithm used

 Register customer

54
Click on register customer link

Registration form is displayed

Fill user profile data

Click on register button

If (valid)

Display successful message.

Else display invalid input message

 create account

Click on create account link

Form is displayed

Fill information for the user

Click on create button

If (valid)

Display successful message.

Else display invalid input message

55
4.3 sample code
Sample code for login

<html>
<head>
<script>
function show_password() {
var x = document.getElementById("password");
if (x.type === "password") {
x.type = "text";
}
else {
x.type = "password";
}
}
</script>
</head>
<body>

<?php
session_start();
include("connection.php");
?>
<?php
if(isset($_POST["login"]))
{
if($con)

56
 {
$un=$_POST["username"];
$password=$_POST["Password"];
$pw=md5($_POST["Password"]);
$sql="select * from account where username='$un' and
password='$pw' and status='Active'";
$matchfound=mysqli_query($con,$sql);
if($row=mysqli_fetch_assoc($matchfound))
{
$id=$row['userid'];
$username=$row['username'];
$password=$row['password'];
$role=$row["role"];

$sql1="select * from customer where accountno='$id' ";

$matchfound1=mysqli_query($con,$sql1);
$row1=mysqli_fetch_assoc($matchfound1);
{
$acc=$row1['accountno'];
$fnn=$row1['fname'];
$photoo=$row1['photo'];

$sql1="select * from employee where userid='$id' ";

$matchfound1=mysqli_query($con,$sql1);
$row11=mysqli_fetch_assoc($matchfound1);
{
$user=$row11['userid'];
$fn=$row11['fname'];

57
 $coll=$row11['collage'];
$photo=$row11['photo'];
$sql=mysqli_query($con,"delete
from attempt");
$_SESSION['$acc']=$acc;
$_SESSION['$user']=$user;
$_SESSION['$id']=$id;
$_SESSION['$fn']=$fn;
$_SESSION['$fnn']=$fnn;
$_SESSION['$coll']=$coll;
$_SESSION['$photo']=$photo;
$_SESSION['$photoo']=$photoo;

$_SESSION['Username']=$username;
$_SESSION['Password']=$password;
$_SESSION['Role']=$role;
$start_time = date("d M Y @ h:i:s");
$_SESSION['$start_time']=$start_time;

if($role=="administor")
header("location:adminpage.php");

else if($role=="accountant")
header("location:accountantpage.php");
else if($role=="loancommittee")
header("location:loancommitteepage.php");
else if($role=="manager")
header("location:managerpage.php");
else if($role=="finance")

58
 header("location:financepage.php");
else if($role=="hrm")
header("location:hrmpage.php");
else if($role=="customer")
header("location:customerpage.php");

}
}
}
else
{
$count="insert";
$sql=mysqli_query($con,"select*from attempt");
$total=mysqli_num_rows($sql);
$total++;
if($total>3)
{
header("location:index1.php");
}
else
{
echo "<FONT color='red'>Please enter correct username and password</FONT>";
echo "<br>you are tries $total times,but allowed 4 times<h1>";
$insert=mysqli_query($con,"insert into attempt values('$count')");
}
}
}

59
 else
echo "Connection Failed";
}
?>
<table width="100%">
<tr>
<td>
<table border="" width="100%">
<tr><td bgcolor="#808080" style="font-size: 20px">
<h2 align="center">User Login</h2></td></tr><tr
style="width:100%"><td bgcolor="#1f618d">
<form action="" method="POST" enctype="multipart/form-data">
<h3 style="background:#1f618d;height:30px "align="center">User Name:</h3> <input
type="text" name="username" placeholder="Enter User Name" required="user name is
required" style="height: 35px;width: 100%"><br>
<h3 style="background:#1f618d;height:30px "align="center">Password:</h3> <input
type="password" name="Password"id="password" placeholder="Enter Password"
required="password is required" style="height: 35px;width: 100%"><br><br>
<label >
<input type="checkbox" name="checkbox"
id="chekbox" onClick="show_password();">Show Password
</label>

<input type="submit" name="login"value="Login"style="font-size: 20px;background:

#808080;color: white">
<input type="reset" value="Clear"style="font-size: 20px;background: #808080;color:
white"><br><br>
<a href="forgotpass.php" ><span >Forgot password?</a></h3></span>
</form>
</td></tr>
</table>
60
<?php
//}
?>

</td>
</tr>
</table>
</body>
</html>

CHAPTER FIVE

5 CONCLUSION AND RECOMMENDATION

5.1 Conclusion

61
This project is developed for DMU employee’s saving and credit association to web based
system in order to give efficient, reliable, timely, secure system, easily accessed, availability
of service throughout Debre markos university .The main propose of this system is not only for
the user but also for the association.

By challenges money problems we develop this new system, this system is very important for
developing Debremarkos university saving and credit association. In this project we tried to
solving complex and manual system to web based mechanism by using this new system such as:
substitute manual to web based system.

The proposed system made computerized to reduce human errors and to increase the efficiency.

The main aim of our project is:

 Reduce the number of employee

 Minimize the time required to perform task
 Minimize the work load of employees
 Remove redundancy of data
 Update the record easily
 Easy retrieval of data
 Provide sufficient security
 Increase employee satisfaction etc.

5.2 Recommendation and future enhancement

Any user who wants to interact with DMU employee saving and credit association should
have some knowledge. In order to clarify who required what knowledge the team
Recommended:-
Related with customer
 User must have a basic firsthand experience with systems or other related
experiences.
 User must have a basic knowledge of computer.
 Training user should be considering for best performance and efficiency of IT
technology.
Related with association
Organization should have adequate computer facilities to the activities of student
information system.
Budget should be allocated to take specific measure: -
 To change the manual system into new system.
 To maintain the system in a timely and speedy manner.
Future enhancement
 Online payment
 Profit distribution for share

62
  Procurement

Reference
[ CITATION 1 \l 1033 ] (Unpublished) Debre markos university employee's saving and credit
association rule and regulation, 2007

[ CITATION 2 \l 1033 ] definition of system requirement spacification

https://www.inflectra.com/ideas/topic/requirements-definition.aspx , accessed december 3 2010
1:30:23 AM

63
[ CITATION 3 \l 1033 ] Functional requirement vs nonfunctional requirement www.google.com/ ,
accessed December 5 2010 2:23:12 AM

[ CITATION 4 \l 1033 ] UML use case diagram https://www.smartdraw.com/use-case-diagram/

accessed december 10 2010 3:04:45AM

[ CITATION 5 \l 1033 ] UML diagram,

https://www.tutorialspoint.com/uml/uml_class_diagram.htm accessed December 15 2010
1:21:03AM

64