1. WACHEMO UNIVERSITY
FACULTY OF ENGINEERING AND TECHNOLOGY
DEPARTMENT OF INFORMATION TECHNOLOGY
TITLE:-DESKTOP APPLICATION FOR HOSSANA WATER
SUPPLY MANEGMENT SYSTEM
MEMBER……………………………………………………….ID NUMBER
1. Behredin sultan………………………………………….R/E-1248/05
2. Kedru sultan………………………….…………………R/E-1287/05
ADVISOR Ms.Hiwot
Jan 6/ 2008
Hosanna, Ethiopia
2. Contents
List of Table....................................................................................................................................................I
List of figure ..................................................................................................................................................II
Chapter two ..................................................................................................................................................1
2. System analysis .........................................................................................................................................1
2.1 INTRODUCTON................................................................................................................................1
2.2. Description of the existing system.....................................................................................................1
2.3. Description of the new system...........................................................................................................1
2.4. Requirement analysis.........................................................................................................................2
2.4. Functional Requirements ...................................................................................................................2
2.4.1. Functional requirements..............................................................................................................2
2.4.2. Non Functional Requirements ....................................................................................................2
2.5. Use case diagram ...............................................................................................................................3
2.5.1 Use case modeling .......................................................................................................................3
2.5.2. Activity diagram .......................................................................................................................11
2.5.3. Sequence diagram .....................................................................................................................19
CHAPTER 3 ..................................................................................................................................................29
3. SYSTEM DESIGN ......................................................................................................................................29
3.1 Over view..........................................................................................................................................29
3.2. Design Goals....................................................................................................................................29
3.3 user interface.....................................................................................................................................29
3.4. Proposed System architecture..........................................................................................................31
3.5. System decomposition .....................................................................................................................32
Figure 23 Decomposition diagram..............................................................................................................33
3.6. Package ............................................................................................................................................33
3.7. Deployment diagram........................................................................................................................33
3.8. Database design ...............................................................................................................................34
3.8.1 ER Diagram ................................................................................................................................37
3. 3.9. System Security ...............................................................................................................................39
4. I
List of Table
Table 1 Login table.......................................................................................................................................5
Table 2 table for audit and analysis ..............................................................................................................6
Table 3 table Bill collector............................................................................................................................7
Table 4 Table for update customer information............................................................................................8
Table 5 table for delete customer information..............................................................................................9
Table 6 Table generate report .....................................................................................................................10
Table 7 View report table ...........................................................................................................................11
Table 8 Employee table ..............................................................................................................................35
Table 9 customer table................................................................................................................................36
Table 10 User account table........................................................................................................................36
Table 11 Bill collector table........................................................................................................................37
Table 12 Report table..................................................................................................................................37
Table 13 Report type table..........................................................................................................................37
5. II
List of figure
Figure 1 use case diagram.............................................................................................................................4
Figure 2 activity diagram login...................................................................................................................12
Figure 3 activity diagram audit and analysis ..............................................................................................13
Figure 4 activity diagram apply register .....................................................................................................14
Figure 5 activity diagram bill collector.......................................................................................................15
Figure 6 activity diagram update customer information.............................................................................16
Figure 7 activity diagram delete customer information.............................................................................17
Figure 8 activity diagram generate report...................................................................................................18
Figure 9 activity diagram view report........................................................................................................19
Figure 10 Sequence diagram for employee register....................................................................................20
Figure 11 Sequence diagram for update employee information .................................................................21
Figure 12 Sequence diagram for update customer information..................................................................22
Figure 13 Sequence diagram for delete customer information ...................................................................23
Figure 14 Sequence diagram for delete employee information ..................................................................24
Figure 15 Sequence diagram for generate report........................................................................................25
Figure 16 Bill payment form........................................................................................................................26
Figure 17 Sequence diagram for customer register.....................................................................................27
Figure 18 Class diagram .............................................................................................................................28
Figure 19 login interface.............................................................................................................................30
Figure 20 interface for customer registration form.....................................................................................30
Figure 21 Employee registration form........................................................................................................31
Figure 22 system proposed architecture....................................................................................................32
Figure 23 Decomposition diagram..............................................................................................................33
Figure 24 Entity relationship diagram.........................................................................................................38
6. 1
Chapter two
2. System analysis
2.1 INTRODUCTON
System analysis is the way of studying a system with an eye on solving its problem using computers. It is
the most essential part of the development of a project of a system analysis. System analysis consists of
system element, process and technology. It is the detailed study of the various operations performed
by a system and their relationships within and outside of the system. A key question is: What must
be done to solve the problem? One aspect of analysis is defining the boundaries of the system and
determining whether or not candidate system should consider other related systems.
2.2. Description of the existing system
The existing system most works made by manual. The information of the previous and new coming
customers is recording on the paper and placed on the shelf. . The existing system or this manual
system has many drawbacks like; it takes time to search customer, it needs high cost, the paper
based recording cannot be claimed as secure. Therefore developing an desktop application for
HWSSO is found to be important to address those problems.
2.3. Description of the new system
The system that we are going to develop can solve different problems that we have mentioned in
the existing system. In general this application will reduce the cost, time, and effort of the user
and also it will provide such an easy way to use it for the user.
To reduce human errors by providing user-friendly input and output capabilities and record
keeping.
To store data into his/her computer so, it can be easily accessed and used at any time.
To provide security to data.
The advantages of the new system are:
Performance: The performance of the proposed system provides fast response time because it is
easy to access data from the stored data. .
Processing data with high speed and short hand form.
Data redundancy problem will be avoided with the proposed system.
7. 2
2.4. Requirement analysis
The following are Functional and Nonfunctional requirements of the proposed new system that a
project team have identified from requirement use cases associated with each actor and use case
interactions
2.4. Functional Requirements
2.4.1. Functional requirements
Functional requirements these are statements of services the system should provide, how the
system should react to particular inputs, and how the system should behave in particular situations.
It specifies the software functionality that the developers must build into the product to enable
users to accomplish their tasks.
The system must have a dynamic that provides successfully registration of customers which are
under the business rule of the office and generate report to interact with various users.
The system should allow staff to login to the system using their username and password.
The system should provide to modify record that is deleting, editing and inserting as well as
retrieving the required information.
The system should display message when employees of the HWSS and customers do their task
successfully or not when they insert invalid username and password.
The system should display full information for the employee from the database to the interface.
The system should have well organized information storage and accessing mechanism.
The system should allow generating report for the organization.
The system must easy to enter meter read value to the database.
The system must presents information of the customer and their monthly costs, and requests
service maintenance in secured manner.
It is expected to solve the difficulty of managing overloaded customer registration, bill calculating
and other task successfully.
2.4.2. Non Functional Requirements
Non-functional requirements, as the name suggests, are requirements that are not directly
concerned with the specific services delivered by the system to its users. They may relate to
emergent system properties such as reliability, response time, and store occupancy
Since everything in the office is financial, the system of DBMS should be highly secured and every
users of the system should have their own privilege which in turn maximize the system security.
8. 3
The system calculates the customer’s bill rent, so it should give accurate result; so should be
reliable.
The system should have an easily understandable design in order for users (employee) to use it;
this means the system should be user friendly.
The system provides quick and easy information analysis which in turn maximizes the overall
work efficiency.
The system should be able to manage all the information incoming from the database and the
catalogue; Capacity Requirements.
2.5. Use case diagram
The Use case diagram is used to define the core elements and processes that make up a system.
The key elements are termed as "actors" and the processes are called "use cases." The Use case
diagram shows which actors interact with each use case. Actors and their general work description
are listed below:-
2.5.1 Use case modeling
Actor Definition
Actors are portrayed in a use case diagram as a stick figure and represent external factors that will
provide interaction with the system.
Administrator: an employee, who works on customer service office, which have the following
responsibilities.
Approve new customer application.
She/he makes a decision when a customer is deleted or updated.
Accountant: A professional person who performs accounting functions such as audits or financial
statement analysis, which responsible to takes the final value from the customer and she/he asks
the customer to pay their fee depend on the calculated value. After the payment the Accountant
must be transfer the overall deposit of the customer to the Bill collector.
Bill collector: The Bill collector takes the deposit from the Accountant and check if exception was
happened, if not he/she approve the customers. This employee also has a privilege to read the
generated report that is done by the Bill officer.
And it is an employee in the Billing system, who is responsible to check the monthly or ant time
when the organization want to check reading data,
9. 4
2.5.1.1. Use case Detail description
System
accountanat
Bill colector
Administrator
Update customer
inforation
view report
Audit and analysis
Delete customer
information
login
«uses»
«uses»
«uses»
«uses»
«uses»
register customer
register employee
«uses»
«uses»
put penality
create account
«uses»
«uses»
bill collect
«uses»
Figure 1 use case diagram
10. 5
Use case name: Login
Identifier: UC2
Actor: Administrator, Accountant, Bill collector.
Description: A member login to HWSSO uses their appropriate user name and
pasword.
Precondition: Must have valid username and password.
Basic course of
action:
The
employee:
Open home page
Click sign in from the right top of the screen
Enter Username and password.
System validates the address.
User login to the system.
If not try again
End use case.
Post condition: The employees enter to the System
Table 1 Login table
11. 6
Use case name: Audit and analysis
Identifier: UC3
Actor: Accountant
Description: The Accountant would receive the total cost from the customer that has
been b being used.
Precondition:
The bill officer transfer the final calculated value to the Accountant
Basic course of
action: The accountant:
Open the homepage.
login in
Enter username and password.
System validates the address.
Click the customer payment page link.
He/she receive payment from the customer’s
according to the data; if the customers had debit, add
the penalty value (10 birr per month).
After the payment process was finished, transfer the
general data to the bill collector.
End use case.
Post condition: The accountant take the payment from customers according to the calculated
bill value, audit and transfer to the bill collector.
Table 2 table for audit and analysis
12. 7
Use case name: Bill collect
Identifier: UC4
Actor: Bill collector
Description: The Bill collector accumulates the overall financial value from the
accountant and takes the data of the customers from the bill officer to
approve it.
Precondition: The Accountant must be finished the payment value and the bill officer
must also be transfer the original data of the customers to this employee.
Basic course of
action: The Bill
collector:
Open the homepage.
login in
Enter username and password.
System validates the address.
Click the customer payment page link.
Check The payment and the calculated data.
I Identifies the customers who have debit value.
After the approving process was finished, transfer the data to
the accountant and bill officer.
End use case.
Post condition: The accountant takes the payment from customers according to the
calculated bill value, audit and transfer to the bill collector.
Table 3 table Bill collector
13. 8
Use case name: Update customer information
Identifier: UC5
Actor: Administrator.
Description: Allow to update previously recorded customer data.
Precondition: UC1, UC2.
Basic course of
action:
The
Administrator:
Open the home page.
login in
Enter login address on the homepage.
The system check is the correct address or not.
Bill Officer enter customer ID of the intended customer.
The system validates the customer ID.
The system searches and display customer detail.
Bill Officer enters new modification.
System updates the information and displays it.
End use case.
Post condition: Updated customer data.
Table 4 Table for update customer information
14. 9
Use case name: : Delete customer.
Identifier: UC6
Actor: Administrator.
Description: Used to block customer from HWSSO system service.
Precondition: UC2.
Basic course of
action:
The Bill collector: Login to customer page.
login in
Enter user name and password
System validates the address.
Search the customer information in their database by
entering their appropriate ID.
Block the customer.
End use case.
Post condition: The customer will be blocked(Delete).
Table 5 table for delete customer information
15. 10
Use case name: Generate report
Identifier: UC7
Actor: Bill collector
Description: Generate report that was done monthly in the form of printable data.
Precondition: UC1, UC3.
Basic course of
action:
The Bill
collector:
Open the homepage
login in
Enter user name and password
System validates the address.
Click report link
Select report type that wants to generate then click
preview.
Click print button, logout, End use case.
Post condition: Generate report.
Table 6 Table generate report
16. 11
Use case name: View Report
Identifier: UC8
Actor: Bill collector
Description: View report that was done monthly.
Precondition: UC1, UC3.
Basic course of
action:
The Bill
collector:
Open the homepage
Login
Enter user name and password
System validates the address.
Click report link
Select report type that wants to view.
Back to main page.
End use case.
Post condition: Generate report.
Table 7 View report table
Table 2.8
2.5.2. Activity diagram
Activity Diagram
Activity diagrams model is a high level business or processes or transitions between states of a
class. In this activity diagram tried to document the flow of logic for the major business processes.
17. 12
Open home page
Click login button
Redirect to the page
Login:
Login
Enter username and password
[ invalid
]
valid
Figure 2 activity diagram login
18. 13
Open home page
Take the payment and debit value
Check the payment and debit
Login
Enter user name and password
Click login
[ invalid
]
Successfully inserted
valid
invalid
valid
auditing and analysis:
Figure 3 activity diagram audit and analysis
19. 14
open home page
login
Enter usermane and password
click login
employee registration page
register employee:
register successfull
register
adminstrator
Figure 4 activity diagram apply register
20. 15
Open home page
check the monthly payment and debit
Login
Enter user name and password
Click login
[ invalid
]
check Duplicate files
bill collector:
[Valid
]
[Invalid]
[Approv
e ]
succesfully inserted
Figure 5 activity diagram bill collector
21. 16
Open home page
Enter the data to update
Login
[ invalid]
Enter user name and password
[ incorrect ID]
[ correct ID]
update customer information:
Insert customer identification number
Successfully update
customer registration page
Figure 6 activity diagram update customer information
22. 17
Figure 7 activity diagram
delete customer information
Open home page
Login
[ invalid]
Enter user name and password
Insert data to be delete
Delete
Delete custemet information:
23. 18
Enter Username and password
[ Correct address]
The Bill officer open the homepage
Click print button
Signin
[ Incorrect Address]
Click report link
Select report type that want to generate
Generate Report
Figure 8 activity diagram generate report
24. 19
Enter Username and password
[ Correct address]
The Bill collector open the homepage
Click view button
[ Incorrect Address]
Click report link
Select report type that want to view
View Report
Login
Figure 9 activity diagram view report
2.5.3. Sequence diagram
A sequence diagram shows an interaction arranged in time sequence. In particular, it shows the
instances participating in the interaction by their “lifelines” and the stimuli that they arranged in
time sequence. It does not show the associations among the objects.
33. 28
2.5.4. Class diagram
Class diagrams show the static structure of the model, in particular, the things that exist
(such as classes and types), their internal structure, and their relationships to other things
Figure 18 Class diagram
Employee
-ID: int
-Fname: string
-Lname: string
-Role: string
-Age: int
-Phone No: int
-Sex: char
-Emp_ID: string
-create ()
-delete ()
-update
User account
-Account_ID: int
-username: string
-password: string
-Role: string
-Emp_ID: int
-Create ()
-delete ()
Customer
-ID: int
-customer ID: string
-cus_Fname: string
-cus_Lname: string
-Age: int
-Sex: char
-keble: int
-home_no: int
-phone_no: int
-get service ()
Bill collector
-ID: int
-collect_ID: string
-collect ()
Report
-ID: int
-type ID
-generate ()
Report type
-ID: INT
-type: string
-report: string
-identify ()
34. 29
CHAPTER 3
3. SYSTEM DESIGN
3.1 Over view
The purpose of design is to determine how we are going to build our system and to obtain the
information needed to drive the actual implementation of our system. This is different from
analysis, which focuses on understanding what will be built.
3.2. Design Goals
The goal of the design phase is to transform the requirements into complete and detailed system
design specifications.
It also improves the performance.
Establish a baseline for requirements change control, design, and testing
Provide users with detailed information to fully utilize the system
Increases reliability and speed
Once the design is approved, the development team begins the development phase.
3.3 user interface
This layer is used to join to the system through which the system user can communicate with the
system.
The users intended to face login form on the first page to enter the user based on their account
level. If the entered user is administrator or he/ she can meet with the main form which contains
menus and submenus like sign up for new users delete user, update account for system user. But,
if the logged user is not administrator he can’t access all things. If entered user is acquisition officer
he/she can use forms to registering new employee information, updating existing files, searching,
report, etc.
Login page
35. 30
Figure 19 login interface
Customer registration page
Figure 20 interface for customer registration form
Employee registration form
36. 31
Figure 21 Employee registration form
3.4. Proposed System architecture
The general architecture of the system looks like the following picture. At the top of layer is put
the user interface of the system and water management system application logic. Finally, at the
back end, the organization data is placed. We can show as follows
37. 32
3.5. System decomposition
To reduce the complexity of the solution domain, we decompose a system into simpler parts, called
subsystems, which are made of a number of solution domain classes. In the case of complex
subsystems, we recursively apply this principle and decompose a sub- system into simpler
subsystems. Decomposition Results large systems in to a set of loosely dependent parts which
make up the system. The main need of this portion is to design the external part of the system.
Sub-System Decomposition is the way that helps us to distinguish the part of the operations that
takes place under the organization.
System Layer
Data Source
Data Layer
(Persistence layer)
Interface Layer
(User interface layer)
Process layer
(Application & control
Layer)
Business Layer
(Domain layer)
Users
System Architecture
Figure 22 system proposed architecture
38. 33
HWSSMS
ADMINSTRATOR ACCOUNTANT
BILL COLLECTOR
Figure 23 Decomposition diagram
3.6. Package
Package is UML structure diagram which shows packages and dependencies between the
packages. Package diagram enables us to gain a high level understanding of the collaboration
among model elements through analyzing the relationships among their user package.
Package diagrams depict the various packages of the software system and the relationships among
them. Advantages of using packages to model the constituents of a software system are enable
visualizing the functional groups and the relationships among them. Facilitates easy management
of the large software systems. Persistence layers encapsulate the capability to store, retrieve, and delete
objects/data permanently without revealing details of the underlying storage technology. Often
implement between your object schema and your database schema and there are various available to you.
3.7. Deployment diagram
Deployment diagram show how the system is deployed on computers. In other words, it shows
which component of the software is installed on which machine and how they communicate with
each other if they are on different machines. It also depicts a static view of the run-time
configuration of processing nodes and the components that run on those nodes. In other
words, deployment diagrams show the hardware for your system, the software installed on
that hardware, and the middleware used to connect the disparate machines to one another.
39. 34
The purpose of deployment diagrams can be described as:
Visualize hardware topology of a system.
Describe the hardware components used to deploy software components.
Describe runtime processing nodes.
Application server layer
Dtatabase Server
layer
Registor customer
Registor employee
Update cus_inform
Update Emp_inform
Delate Emp_info
audit & analise
Database
Bill collect
View Report
Adminstrator
: Bill database layer
Adminstrator
Bill collector
Accountant
put penality
create account
Fig 3.5.2. Deployment Diagram
3.8. Database design
Database design is transforming an E-R model and their data specifications design into a
normalized relation. A relation is a named, two dimensional tables of data, having set of named
columns and an arbitrary number of unnamed rows, Each column in a relation corresponds to an
attribute of that relation and each row of a relation corresponds to a records that contains data
40. 35
values for an entity. Well-structured relation corresponds to records that contain a minimum
amount of redundancy and allows users to insert, modify and delete the rows without errors or
inconsistencies. It is the process of converting complex data structures into simple, stable data
structures using a process called normalization.
Table 8 Employee table
42. 37
Table 11 Bill collector table
Table 12 Report table
Table 13 Report type table
3.8.1 ER Diagram
Entity-relationship diagrams were first proposed as a means of quickly obtaining, with minimum
effort, a good sense of the structure of a database. They are used to plan and design a database and
to model a system’s data.
Due to lack of space it’s difficult to place all attributes to their corresponding entities so they are
listed below and assumed to be drawn to their respective entities.
43. 38
Figure 24 Entity relationship diagram
EmployeeAccount Bill collector
Customer
Report
generate
Create
Register
Collect
Lname
Enamel
Name
ID
TypeID
ID
Age
ID Cstomer_ID
Collect ID
Fname
Name
emp_ID
Lname
Password
Age
Phone no
Home no
Keble
Role
Username
Monthly
Wea
kly
Annually
44. 39
3.9. System Security
Hossan water supply Management System needs authentication mechanism to control the data
access by different users, as it is information has to be protected from using by unauthorized users.
So that the software have a particular server, which manage the data access by users and gives
permission to each users according to their priority given by system administrator, to modify
(manipulate) the data. The other important thing in software development is security. The software
system first asks every user to be login to the system, before performing certain operation.
When the administrator creates account for the user, the user gets a username and Password.
When the user used the system in first time it can be change the user name and it answer
two questions in terms of used to reset the username and password when it forget the username or
password.
3.10. Reference
1. Valacich /George/ Hoffer (2012), Essentials of System Analysis and Design, Fifth edition.
2. ScottW.Ambler, the Application Developer’s Guide to Object Orientation and UML, second
edition.
3. System analysis and Design methods (in analysis and design phase).
