DIRE DAWA UNIVERSITY

INSTITUTE OF TECHNOLOGY
SCHOOL OF COMPUTING
DEPARTMENT OF COMPUTER SCINCE

TITLE: - WEB BASED ELECTRIC BILLING SYSTEM

1. Besufekad Terefe
2. Bikila Mitiku
3. Haftia Adisalem
4. Helen Solomon
5. Henok Megersa

A Project Document Submitted to Dire Dawa University School of Computing Department of

Computer Science in Partial Fulfillment of the Requirements for the Degree of Bachelor of
Science in computer science

Advisor: Ins. Shemelis H. (Msc)

Dire Dawa, Ethiopia

26 August 2021
 DIRE DAWA UNIVERSITY
INSTITUTE OF TECHNOLOGY
SCHOOL OF COMPUTING
DEPARTMENT OF COMPUTER SCINCE
TITLE: - WEB BASED ELECTRIC BILLING SYSTEM

Name Id
1. Besufekad Terefe…………DDU1002161
2. Bikila Mitiku……………. DDU1001890
3. Haftia Adisalem…………..R/1796/09
4. Helen Solomon………….. DDU1001651
5. Henok Megersa ……………...DDU1001604

Advisor: - Shemelis H.(Msc)

This is to declare that the project is prepared by Besufekad Terefe, Bikila Mitiku, Haftia
Adisalem, Helen Solomon, Henok Megersa and titled: “web based electric billing system” and
submitted in Partial Fulfillment of the Requirements for the Degree of Bachelor of Science in
computer science in accordance with the university’s rule and regulation and meets acceptance
with respect to quality and originality.

Name and signature of Members of the Examining Board

Chairman Name__________________________ Signature________________________

Name Signature Date

Advisor _____________ ______________ _____________
Examiner _____________ _______________ ______________
Examiner _____________ ________________ ______________
 Acknowledgement
First of all, we would like to thank almighty GOD forgiving us strength and health to do this
project. Secondly we would like to express our sincere gratitude to our advisor Mr. Shemalis H.
(Msc) for his guidance, support and continuous encouragement throughout the project, and also
for his hard question which helped us to widen our project proposal from various perspectives. We
also extend our sincere thanks to our department (Computer Science) very much; they give us
necessary facilities such as computer lab and internet access and our classmates for their
contribution during the development of this project. Finally, we thank Dire Dawa city electric
power utility employees, by giving the business rule of the system and much other information
voluntarily during the data gathering.
 Abstract
This project was proposed for Dire Dawa city electric power utility for personal bill generation.
The proposed system consolidates bills for the user so the user will not need to go to the
organization to pay the bills. Personal users can save time and effort on paying bills every month
and will less likely forget to pay for the bills thus avoiding paying late payment punishment. The
proposed system can also provide functionalities for the users to follow their bill status back in
time and online from anywhere. Reports can also be generated for all bills monthly, which is a
very useful tool for employees and admin to know and plan their expenses.
 Table of Contents
Acknowledgement ......................................................................................................................... iii
Abstract .......................................................................................................................................... iv
Acronyms and Abbreviations ........................................................................................................ iv
List of Tables .................................................................................................................................. v
List of figure .................................................................................................................................. vi
CHAPTER ONE ............................................................................................................................. 1
1. INTRODUCTION ................................................................................................................... 1
1.1 Background of the Organization ...................................................................................... 1
1.2 Background of the project ................................................................................................ 1
1.3 Statement of the Problem ................................................................................................. 1
1.4 Objective of the project .................................................................................................... 2
1.4.1 General Objective ..................................................................................................... 2
1.4.2 Specific Objectives ................................................................................................... 2
1.5 The Scope of the project................................................................................................... 2
1.6 Limitation of the project ................................................................................................... 2
1.7 Constraint ......................................................................................................................... 3
1.8 Methodology .................................................................................................................... 3
1.8.1 Data Gathering Methodology ................................................................................... 3
1.8.2 System Analysis and Design Methodology .............................................................. 3
1.9 System Development Approach ....................................................................................... 4
1.9.1 System Development Tools .......................................................................................... 5
1.9.1.1 Software Tools ...................................................................................................... 5
1.9.1.2 Hardware Tool....................................................................................................... 5
1.9.2 Programming Language ............................................................................................ 6
1.10 Significance of the project................................................................................................ 6
1.11 Beneficiaries of the project .............................................................................................. 6
1.12 Feasibility ......................................................................................................................... 6
1.12.1 Technical Feasibility ................................................................................................. 7
1.12.2 Operational Feasibility .............................................................................................. 7

i
 1.12.3 Economic Feasibility (Cost Benefit Analysis) .......................................................... 7
1.12.4 Schedule Feasibility .................................................................................................. 8
CHAPTER TWO ............................................................................................................................ 9
2. Requirement Elicitation ........................................................................................................... 9
2.1 Overview of existing system ............................................................................................ 9
2.2 Existing system ................................................................................................................ 9
2.2.1 Existing System Description ..................................................................................... 9
2.2.2 Supplementary Requirements ................................................................................... 9
2.3 Advantages Existing system........................................................................................... 10
2.4 Disadvantages Existing system ...................................................................................... 10
2.5 Proposed Solution .......................................................................................................... 11
2.6 Prefered solution ............................................................................................................ 11
2.7 Domain modelling with CRC card ................................................................................. 12
2.8 Essential Use Case diagram ........................................................................................... 13
2.8.1 Actor Identification ................................................................................................. 13
2.8.2 Use Case Identification ........................................................................................... 13
2.8.3 Use Case Diagram................................................................................................... 13
2.9 Use Case Description ..................................................................................................... 14
2.10 Essential User Interface Prototyping .............................................................................. 21
CHAPTER THREE ...................................................................................................................... 22
3. SYSTEM ANALYSIS ....................................................................................................... 22
3.1 Overview of New system ............................................................................................... 22
3.2 System requirement ........................................................................................................ 22
3.2.1 Functional Requirements ........................................................................................ 22
3.2.2 Non-Functional Requirements ................................................................................ 23
3.3 System modelling ........................................................................................................... 24
3.3.1 System use case diagram ........................................................................................ 24
3.3.2 System use case diagram documentation ................................................................ 24
3.4 Sequence diagram .......................................................................................................... 35
3.5 Activity diagram ............................................................................................................. 43
3.6 Class diagram ................................................................................................................. 50

ii
CHAPTER FOUR ......................................................................................................................... 52
4. SYSTEM DESIGN ................................................................................................................ 52
4.1 Design goal ..................................................................................................................... 52
4.2 System Architecture ....................................................................................................... 53
4.3 Sub-system Decomposition ............................................................................................ 53
4.4 State chart diagram ......................................................................................................... 54
4.5 Collaboration Diagram ................................................................................................... 55
4.6 Deployment Diagram ..................................................................................................... 58
4.7 Persistent data storage and management ........................................................................ 59
4.8 Graphical user interface Design ..................................................................................... 60
CHAPTER FIVE .......................................................................................................................... 62
5. CONCLUSION AND RECOMMENDATIONS .................................................................. 62
5.1 Conclusion...................................................................................................................... 62
5.2 Recommendation ............................................................................................................ 62
Reference ................................................................................................................................... 63

iii
Acronyms and Abbreviations

Cases

OOA: Object Oriented Analysis...................................................................................................... 4

OOSAD: Object Oriented System Analysis and Design ................................................................ 3
UML : Unified Modelling Language .............................................................................................. 3

iv
 List of Tables
Table 1.1 Budget of the project....................................................................................................... 7
Table 1.2 schedule plan................................................................................................................... 8

Table 2.1 CRC Diagram for Customer ......................................................................................... 12

Table 2.2 CRC Diagram for Admin .............................................................................................. 12
Table 2.3 CRC Diagram for Admin .............................................................................................. 12
Table 2.4 Use case Description for Current Service ..................................................................... 14
Table 2.5 Use case Description for Pay Bill ................................................................................. 15
Table 2.6 Use case Description for Complaint ............................................................................. 15
Table 2.7 Use Case Description for Deactivate Account ............................................................. 16
Table 2.8 Use Case Description for Add Account ........................................................................ 16
Table 2.9 Use case Description for View Report ......................................................................... 17
Table 2.10 Use case Description for View Complaint ................................................................. 18
Table 2.11 Use Case Description for Generate Bill ...................................................................... 18
Table 2.12 Use Case Description for Generate Report ................................................................. 19
Table 2.13 Use case Description for Assign Service .................................................................... 19
Table 2. 14 Use Case Description for View bill ........................................................................... 20

Table 3. 1use Case Description for Register ................................................................................. 24

Table 3.2 Use Case Description for Login.................................................................................... 25
Table 3.3 Use Case Description for Current Service .................................................................... 25
Table 3. 4 Use Case Description for Pay Bill ............................................................................... 26
Table 3. 5 Use Case Description for Send Complaint .................................................................. 27
Table 3. 6 Use Case Description for Change Password................................................................ 27
Table 3. 7 Use Case Description for Deactivate Account ............................................................ 28
Table 3. 8 Use Case Description for Add Account ....................................................................... 28
Table 3. 9 Use Case Description for View Report........................................................................ 29
Table 3.10 Use Case Description for View Complaint................................................................. 29
Table 3.11 Use Case Description for Generate Bill ...................................................................... 30
Table 3.12 Use Case Description for Generate Report ................................................................. 31
Table 3.13 Use Case Description for Assign Service ................................................................... 31
Table 3. 14 Use Case Description for Stop Service ...................................................................... 32
Table 3. 15 Use Case Description for View bill ........................................................................... 32
Table 3. 16 Use Case Description for View Users ....................................................................... 33
Table 3.17 Use Case Description for Import ................................................................................ 34
Table 3.18 Use Case Description for Logout................................................................................ 35

v
 List of figure
Figure 2. 1 use case diagram of existing system ........................................................................... 14

Figure 3.1use case diagram of existing system ............................................................................ 24

Figure 3. 2 Sequence Diagram for Register .................................................................................. 36
Figure 3. 3Sequence Diagram for Login....................................................................................... 36
Figure 3. 4Sequence Diagram for Current Service ....................................................................... 36
Figure 3. 5Figure 2.5 Sequence Diagram for Pay Bill .................................................................. 37
Figure 3. 6 Sequence Diagram for Send Complaint ..................................................................... 37
Figure 3. 7 Sequence Diagram for Change Password................................................................... 38
Figure 3. 8 Sequence Diagram for Deactivate Account ............................................................... 38
Figure 3. 9 Sequence Diagram for Add Account .......................................................................... 39
Figure 3. 10 Sequence Diagram for View Report......................................................................... 39
Figure 3. 11 Sequence Diagram for View Complaint................................................................... 40
Figure 3. 12 Sequence Diagram for Generate Bill ........................................................................ 40
Figure 3. 13 Sequence Diagram for Generate Report ................................................................... 41
Figure 3. 14 Sequence Diagram for Assign Service ..................................................................... 41
Figure 3. 15 Sequence Diagram for Stop Service ......................................................................... 42
Figure 3. 16 Sequence Diagram for View Bill ............................................................................. 42
Figure 3. 17 Sequence Diagram for View user ............................................................................. 43
Figure 3. 18 Activity Diagram for Register .................................................................................. 44
Figure 3. 19Activity Diagram for Login ....................................................................................... 44
Figure 3. 20Activity Diagram for Current Service ....................................................................... 44
Figure 3. 21 Activity Diagram for Add Service ........................................................................... 44
Figure 3. 22 Activity Diagram for Pay Bill .................................................................................. 45
Figure 3. 23 Activity Diagram for Send Complaint ..................................................................... 45
Figure 3. 24 Activity Diagram for Change Password ................................................................... 46
Figure 3. 25 Activity Diagram for Deactivate Account ................................................................ 46
Figure 3. 26 Activity Diagram for Add Account .......................................................................... 47
Figure 3. 27 Activity Diagram for View Report ........................................................................... 47
Figure 3. 28 Activity Diagram for View Complaint ..................................................................... 47

vi
Figure 3. 29 activity Diagram for Generate Bill ........................................................................... 48
Figure 3. 30 Activity Diagram for Generate Report ..................................................................... 48
Figure 3. 31Activity Diagram for Assign Service ........................................................................ 48
Figure 3. 32 Activity Diagram for Stop Service ........................................................................... 49
Figure 3. 33 Activity Diagram for View bill ................................................................................ 49
Figure 3. 34Activity Diagram for View users .............................................................................. 49
Figure 3. 35Activity Diagram for Add News ............................................................................... 50
Figure 3. 36 Activity Diagram for Import .................................................................................... 50
Figure 3. 37 class diagram ............................................................................................................ 51

Figure 4. 1 system architecture ..................................................................................................... 53

Figure 4. 2 state diagram for login ................................................................................................ 55
Figure 4. 3 state diagram for registration ...................................................................................... 55
Figure 4. 4 collaboration diagram for login .................................................................................. 56
Figure 4. 5 Collaboration diagram for view report ....................................................................... 57
Figure 4. 6 Collaboration diagram for Generate report ................................................................ 58
Figure 4. 7 deployment diagram ................................................................................................... 59
Figure 4. 8 Persistent data storage ................................................................................................ 60
Figure 4. 9 User interface for login page .................................................................................... 60

vii
 CHAPTER ONE

1. INTRODUCTION
Now a day our world is globalized with the help of technologies and other applications. For that
reason developed and some developing countries are using the application and other computer
technologies to be part of the globalized world. Many organization and individuals have their
computer based applications for the purpose of running their business, to perform different activity.

1.1 Background of the Organization

Dire Dawa city electric power utility is found in Dire Dawa city around shell. Currently there are
410 employees found in the organization with in this 276 are males and 134 females (kidist, 2021).
It has around 21 departments (stuffs). It distributes the service based on user’s requirement. That
means whether the service is residential, commercial or other services.

1.2 Background of the project

The distributed electric power billing system that is proposed to develop is a system that provides
billing system service for electric power utility of Dire Dawa city. The system controlled by central
administrator. Currently the organizations use desktop application to do the job and process the
data of customer.

The purpose of this proposed project is to establish the method electric power billing service for
the city community. As well to establish the specification pertaining to the design and maintenance
of decentralized treatment and full service as well as facilities within the city service boundary.

1.3 Statement of the Problem

Many problems that exist in Dire dawa city electric power billing system to finish their works
properly and the organization are currently facing a some challenge among thus there are losing
of data because for the current system there is not such suitable to store and retrieve data. And also
time consuming process for the customers by going to the organizations to bill. In addition to this
the current system is not user-friendly and not accurate to read data from everywhere because it is
window based. Generally, this all recommend us to develop web based billing system to make the
operation easy, accurate, flexible and to prevent data loss.

1
 1.4 Objective of the project

1.4.1 General Objective

The general objective of this project is to develop web based system for Dire dawa city Electric
Billing System.

1.4.2 Specific Objectives

The specific objective of this project is:-
 Collecting relevant data and analysing the collected data.
 Designing the system using UML language.
 Implementing the system
 Testing the system
1.5 The Scope of the project
The scope of this project focuses mainly on functional aspects of electric billing system such as:-
 Customer registration
 View current service
 Deactivate Existing User from the system
 Enable the users to send complaints to the organization
 Enable the employee or the admin to view complaints of customer
 Enable the employee to view the bill
 Enable the employee to generate reports of bill
 Enables employee to Import information of user
 Enable the employee to assign the service
 Enable the employee to view customers information
 Enable the user to pay money for bill
 Enable the employee to check payment of customer

1.6 Limitation of the project

Since the system needs some media to conduct transactions, every transaction will be passed via
internet. Therefore, a user must have an access to internet.

The other limitation of the project is

2
  In order to pay the bill online the user must have CBE account with balance and that is
integrated with electric utility providers.
 The system doesn’t read the distance.
 It is Web based system.

1.7 Constraint
While doing this project we faced different types of problems that obstacles our work in order to
finish work timely. Some of these problems are listed below.

 Absence of sufficient time

 Absence materials that used to use
 While collecting data absence of a person who is willing to give us information precisely.

1.8 Methodology

1.8.1 Data Gathering Methodology

 Interview:
We interviewed with some of the employees about their existing system functionality, their
problems and background. The collected information helps us:

 To deeper understanding of the data resources used by the system.

 To know what the current level of system usage by the office.
 Observations:
We observed that the present manual system has lot of functionalities which can overcome by
proposed system such as time, manpower, readiness of customer details etc.

 Reading documents:
To have detailed awareness about our project we used documents such as books. During the
Analysis of documents, we give a special consideration to those documents which can bring more
features to our system.
 Questioners :
We would conduct questioners for the Dire Dawa city electric power utility to study the existing
system and develop the new system.

1.8.2 System Analysis and Design Methodology

For the proposed system or new system, we preferred the object oriented system analysis and
design (OOSAD) approach, which is by using unified modelling language (UML). Because it

3
includes the overall features of OOSAD. The other reason is that using object-oriented
programming we can write clear, more reliable, more easily maintained programs.

Object Oriented Analysis (OOA)

During this phase the team used to model the function of the system (use case modelling), find and
identify the business objects, organize the objects and identify the relationship between them and
finally model the behaviour of the objects.

We preferred Object-oriented approach for the following advantages: -

 Simplify the design and implementation complexity of our program.
 Increase reusability: it helps us for reusability of the system’s code
 It helps us to upgrade our system easily.
 Reduce communication complexity between our team and client because it allows us
to design both the static and dynamic part of the system.
Generally, object oriented principle makes this method powerful than other method of system
development approach. Therefore, we enforced to select this system development approach.

1.9 System Development Approach

There are many different development approaches available those are:

 Waterfall

 Prototyping

 Incremental

 Iterative

 Spiral.

From those developments methodology’s we will use incremental model. In this model, each
module passes through the requirements, design, implementation and testing phases. A
working version of software is produced during the first module, so we have working software
early on during the software life cycle. Each subsequent release of the module adds function
to the previous release. The process continues till the complete system is achieved.
Additionally we choose the incremental model because it has advantages we listed below.

4
Advantages of Incremental model:

 This model is more flexible, less costly to change scope and requirements.

 It is easier to test and debug during a smaller increments.

 In this model customer can respond to each built.

 Lowers initial delivery cost.

 A new technology will be used during a smaller increments.

 Easier to manage risk because risky pieces are identified and handled during it’s
incremental.

1.9.1 System Development Tools

There are some tools that are used to develop the system. These are:

1.9.1.1 Software Tools

 WAMP server 2.5: we use it as server.
 Adobe Photoshop: for editing images.
 Notepad++ 6.7.4, vs code: also for text editing.
 Google Chrome 1.3.26.9: to run the system
 MS office 2016: used for documentation part of our project.
 Visio2016: to draw different diagram
 Edraw-max: to draw user interface prototype
 Snipping tools: to screen shoot the picture

1.9.1.2 Hardware Tool

 Flush disk: for backup and file transfer.
 Data cables: to transfer files from mobile to PC.
 Printer: to print the document.
 Laptop with the following specification
o CPU Core I3
o 500 GB disk space
o 2GB RAM
o Windows 10 operating system
o Intel(R) Core(TM) i3-4005U CPU @ 1.70GHz processor

5
 1.9.2 Programming Language
 HTML: for describing webpage and interface application.
 JS: designing to add interactivity to HTML through validation.
 CSS: we have used it add style to HTML elements for decoration and attractively.
 PHP 5.5.12: we used it as a server script because of it run on different platform like
Linux, windows, and on other servers like Apache server.

1.10 Significance of the project

The benefits gained from the project after implementation is :-

 Save times of employee and customers
 Make the system easier for the users
 Reduces work burden of employees of the organization
 Prevent data loss
 Enable the administrator to manage data easily
 Create fast and efficient sharing of critical information for users and employee of the
organization.

1.11 Beneficiaries of the project

The outcome of this project solve electric power billing system problems that addresses on
customer’s service, then all the customers and service provider was more beneficiary and satisfied
because it helps to save resources like:-

 time,
 money,
 power and
 Increase efficiency and effectiveness.

So, it results in excellent out come to the organization.

1.12 Feasibility

While doing this project, it is fair to see some conditions with regard to cost, clients (end users)
and also about the system developer.

6
 1.12.1 Technical Feasibility
At the implementation stage, we will use the latest technology development tools. Such as HTML,
CSS and JavaScript for front end, and WAMP server and PHP as back end which is the most recent
and open source popular technologies to develop web based systems and to design the database.
As the result our system is technically feasible.

1.12.2 Operational Feasibility

When the system is installed and become operational the organization personnel or who is
supposed to manipulate this system shall train how to work with the new system. Therefore, the
proposed system or the new system would be operationally feasible because:

 The new system fits with the existing operational system.

 Satisfy the user need or requirement.

1.12.3 Economic Feasibility (Cost Benefit Analysis)

Economic feasibility consists of tangible and intangible feasibility which are described as
follows.

Tangible cost:

 Reduce the amount of resource required in office.

 Reduce transportation cost for the customers.
Intangible cost:

 Getting well organized information in short period of time

 Make quick decisions based on the organized information retrieved
 Better service to Customer
 Easy and better way of doing activity in the electric power billing office.
The cost benefit analysis of our project is described in table 1.1 below.

Table 1.1 Budget of the project

No Name of item Quantity Single price Total

1. Flash-disk 2 180 360

7
 2. Paper 1 packet 130 130

3. Printing paper 232 pages 3 682

4. Laptop computer 1 11,000 11,000

5. Pen 10 5 50

6. Transport 2 10 20

7. Mobile card 10 10 100

8. CD-RW 2 8 16

Total 12,358

1.12.4 Schedule Feasibility

For the plan of our project, we have calculated the time that each task will take from us. So
by following schedule plan time we can finish and deliver the project on time. For that of reason,
the system is time feasible. The following figure describes time schedule of our project.

Table 1.2 schedule plan

Id Task name Start Finish Duration 2021 (month)

(days) June July Aug Sept Oct

1 Data collection 20-06-21 04-07-21 14d

2 Requirement analysis 05-07-21 29-07-21 25d

3 System analysis 30-07-21 22-08-21 23d

4 Implementation 23-08-21 07-10-21 44d

5 Testing 08-10-21 20-10-21 12d

8
 CHAPTER TWO

2. Requirement Elicitation

2.1 Overview of existing system

The existing system of the billing system for electric is working slowly in different places.
Whatever be the process involved in the system is working through desktop way, there is a lot of
complexities involved in the system. When any customer takes new interaction with the system
then separate files are maintained. Updating of data is very tedious job. It is not easy to do several
administrative works like managing rates of calls, addition or modification of metered calls &
customer entries. The existing system required different data about customer name, sex,
nationalities, Keble, house number which are customers give to the employee. In this system
administrators accept the request of the customer from employee and the administrator sends
customer request to the central administrator and the central administrator provide registration
number of customer to the administrator then the administrator gives the bill number to the
customer.

2.2 Existing system

2.2.1 Existing System Description

The existing system of the electric power billing system for Dire Dawa city is working window
based. Therefore, there are a lot of problems involved in the system. For example, the system
doesn’t allow the users to follow their bill information everywhere and at any time, inserting,
deleting and updating of data is very tedious job for customer and employee of the organization
and it is not easy to do several administrative works.

2.2.2 Supplementary Requirements

1. Business Rules

The main business rules or principles of the existing system are:

 Costumers will pay money for what they use per month. And no payment difference
for the same service.

9
  Costumer should get the bill paper for what they are paying.
 Some gap is given for a costumer to pay their bill payment. If they didn´t pay within a
given day, it postponed to the next month.
 Anyone who wants to use the service must have an identity card with its legal number.
 Anyone who wants to use the service must have legal house.
 Every customer’s age must be greater than 18.
 Every user must pay their payments within the given period of time
 The employee stops the service of anyone who don’t pay his/her bill payment
 Any user who lost his/her bill paper will inform to the office and can get its copy.

2.3 Advantages Existing system

The current system was carried out window based and no need of web association. What is more,
the other significance of the existing system is that electric utility power did not hire an expert
administrator who has a place to actually monitor the billing online.

2.4 Disadvantages Existing system

The organization has many drawbacks. Some of these are list below.
Customer information not properly handling: -
 They use window to store customer information's.
Lack of security of data: -
 All files are kept on desktop computer they are exposed to theft and other environmental
disaster.
Time consuming: -
 It is difficult to generate daily, monthly and annually report on timely and it may have
errors as they work in quickly.
Tiredness of employees: -
 As they search some data is takes time for the employees who assigned on this work and
they are unsatisfactory on the existing system which leads to endanger on the sustainability
of the company.
More man power is needed: -
 Requires many numbers of peoples to billing selling and maintenance.
Lack of materials: -
 They have no enough materials that used to facilitate their services like computers, printers.

10
  Duplication of data occurs when data input in to the system.
 Checking the validity of input data is difficult
 The services provided by the office are not as fast as possible.

2.5 Proposed Solution

During our observation and interview of users we have observed certain problems from the
window based system; the general overview of our proposed system is to address the problem of
the existing window system of electric power bill. The proposed system solves those problems in
the existing system. Because the system is very integrated and it controls all the data input and
error which happened during filling any forms whether during bill information registration or any
other actions. The new system will be able to access and retrieve different data effectively and
efficiently.

The proposed system will be able to:

 Reduce wastage of time
 Retrieve bill information from the database
 Update the bill information
 Give data availability
 Generate the report within needed time.
 Facilitate the activity of the organization.
 Easy to use (user friendly).
 Reduce the need of paper

2.6 Prefered solution

The preferred solution is to develop web-base electric billing system.
Following are reasons we prefer web-based electric billing system: -
 Web-based electric billing system allows administrator to interact with a remote
server through a web browser interface.
 Electric utility power doesn’t have to install additional software.
 Web-based electric billing system work on any device that can run a supported
browser and has an active internet connection.

11
  The system is accessible anywhere and anytime, as long as administrator have
access to a device with an Internet connection, and the system is great at storing
data

2.7 Domain modelling with CRC card

Table 2.1 CRC Diagram for Customer

Customer<<actor class>>
Customer id
Customer name
Phone number
Address Admin, employee
Feed back
Transfer Money
Pay Money
Add money

Table 2.2 CRC Diagram for Admin

Admin<<actor class>>
Admin id
Name
Address Customer , employee
add account
deactivate account
Report

Table 2.3 CRC Diagram for Admin

Employee<<actor class>>
Employee id
Name

12
 Address Customer , Admin
add account
deactivate account
Report

2.8 Essential Use Case diagram

A use case is a collection of interactions between external actors and a system. In UML, a use
case is the specification of a sequence of actions, including variants, that a system (or entity) can
perform, interacting with actors of the system (Fowler).

2.8.1 Actor Identification

In the existing system there are numbers of actors each having their own responsibility.

1. Customer: someone who want to access the service.

2. Administrator: users of the system who can control access right for other users.
3. Employee: is a person who controls bill information.

2.8.2 Use Case Identification

 Current service: - allows the customer to see his service status.
 Pay bill: - allows the user to pay his/her bill payment.
 Complain: - allows the user to send his complaints.
 Deactivate account: - allows administrator to block employee account.
 Add account: - allows the administrator to add employee account.
 Make report: - allows the employee and the administrator to view the report.
 Take complaint: - allows the employee and the administrator to view the complaints.
 Make report: - allows the employee to generate the report.
 Assign service: - allows the employee to assign deactivated services.
 Check bill: - allows the employee to view all bills status.

2.8.3 Use Case Diagram

Use Case Diagram represents user requirements gathered during requirement elicitation,
contains use case, actors, system boundary and their relationships.

13
Figure 2.1 use case diagram of existing system

2.9 Use Case Description

Use case description includes descriptions of the use case, preconditions, post conditions, flow
of event and whatever which is important in modelling the user goal. The description of each use
case is described below.

Table 2.4 Use case Description for Current Service

Section Purpose
Name Current service
Identifier 01
Description It allows the user to see the status of the current service.
Actor Customer
Precondition none

Basic flow of events Actor action System response

1. User sees the current service 2.The System provides the status of the
current service

Post condition User see detail information

14
Table 2.5 Use case Description for Pay Bill

Section Purpose
Name Pay bill
Identifier 02
Description It allows the customer to pay their bill.
Actor Customer
Precondition The customer must use first.

Basic flow of events

Step1:- meter reader reads the amount electricity the customer used.
Step2:- the employee calculates the money for the electric used by user
according to the calculations interval.

Step3:- customer pay bill

Alternative flow of Step 4:-isthe

If there anemployee confirms
error reading the payment.
and calculating it is redone.
events

Post condition Customer pay his/her bill birr

Table 2.6 Use case Description for Complaint

Section Purpose
Name complain
Identifier 03
Description It allows the customer to report their complaints.
Actor Customer

15
 Precondition The customer must take the complain form first.

Basic flow of events Actor action System response

1. User fill the complaint form 2.The System accepts the complaint
form

Alternative flow of If the form filled is not correct again the customer fill it.
events

Post condition Customer complaint accepted

Table 2.7 Use Case Description for Deactivate Account

Section Purpose
Name Deactivate account
Identifier 04
Description It allows the administrator to deactivate the accounts.
Actor Administrator
Precondition The Admin must have users account first.

Basic flow of events Actor action System response

1. The administrator takes the 2.The System blocks the selected

account. account

Post condition The selected account deactivated.

Table 2.8 Use Case Description for Add Account

16
 Section Purpose
Name Add account
Identifier 05
Description It allows the administrator to add new employee account.
Actor Administrator
Precondition The administrator must take customer.

Basic flow of events Actor action System response

1. The administrator takes the 2.TheSystem provide add account form
add account form 4. System check the filled information
3. The administrator fills the
employee details.

Alternative flow of The system shows an error message or incorrectness of any employee
events data then stay on step2.

Post condition Employee account created.

Table 2.9 Use case Description for View Report

Section Purpose
Name report
Identifier 06
Description It allows the administrator and the employee to see reports.
Actor Administrator and Employee
Precondition The administrator and the employee must login first.

Basic flow of events Actor action System response

1. The administrator or 2. The System view report
employee takes report. information’s.

Post condition The administrator or the employee viewed the report.

17
Table 2.10 Use case Description for View Complaint

Section Purpose
Name take complaint
Identifier 07
Description It allows administrator and employee to view complaints of users.
Actor Administrator and Employee
Precondition Administrator and employee must have access first.

Basic flow of events Actor action System response

1. Administrator or employee 2.The System displays user complaint
view complaint information

Post condition Administrator or employee viewed users complaint.

Table 2.11 Use Case Description for Generate Bill

Section Purpose
Name check bill
Identifier 08
Description It allows the employee to generate the bill.
Actor Employee
Precondition The employee must have access first.

Basic flow of events Actor action System response

1. Employee takes the generate 2.TheSystem displays bill generation
bill form form window
3. Employee fills the current 4. System calculate in birr
metre reading and dates.

Alternative flow of The system shows an error message for incorrectness of the current
events metre reading then stay on step2.

Post condition Bill generated.

18
Table 2.12 Use Case Description for Generate Report

Section Purpose
Name make report
Identifier 09
Description It allows the employee to generate the report.
Actor Employee
Precondition The employee must have authority first.

Basic flow of events Actor action System response

1. Employee generate report 2.TheSystem displays report generation
3. Employee select the date form
4.success

Post condition Report generated.

Table 2.13 Use case Description for Assign Service

Section Purpose
Name Assign service
Identifier 10
Description It allows the employee to assign services.
Actor Employee
Precondition The employee must have access first.

Basic flow of events Actor action System response

19
 1. The employee takes the 2.TheSystem displays the deactivated
assign service form services
3. The employee assign the 4.The system assigns metre number
required service from the list for the new service
sand fill the metre number and
press assign button.

Alternative flow of The system shows an empty select menu if there are no deactivated
events services in the system.
Post condition The user service assigned.

Table 2. 14 Use Case Description for View bill

Section Purpose
Name View bill
Identifier 10
Description It allows the employee to view all bills information.
Actor Employee
Precondition The employee must have the authority.

Basic flow of events User action System response

1. Employee clicks the view bill 2.TheSystem displays all bills detail
button
3.Employee view the all bills
Information including
payment status
Alternative flow of The system shows an empty table if there is no bill in the system.
events

20
Post condition Employee viewed all bill information.

2.10 Essential User Interface Prototyping

21
 CHAPTER THREE
3. SYSTEM ANALYSIS
System analysis is the process of understanding and identifying basic requirements that the
system need and should do. System analysis documentation discuss the over view of the new
system, this topic explain functions provided by the system and its operational constraint. These
system requirements can be seen in two different perspectives, one is what the system should do
and the other is what it needs in order to accomplish its work.

3.1Overview of New system

The proposed system consolidates bills for the user so the user will not need to go to the
organization to pay the bills. Personal users can save time and effort on paying bills every month
and will less likely forget to pay for the bills thus avoiding paying late payment punishment. The
proposed system can also provide functionalities for the users to follow their bill status back in
time and online from anywhere. Reports can also be generated for all bills monthly, which is a
very useful tool for employees and admin to know and plan their expenses.

3.2System requirement
3.2.1 Functional Requirements
A functional requirement specifies what the proposed system should do. And describe the
interactions between the system and its environment (Booch, 1994). For example, functional
requirement of our system is must assign customer bill account and make accessible for a user,
allow the employees to manage data easily and allow the administrator to control account. The
main requirement that used to handle are observable tasks or processes that must be performed
by the system:

 Make accessible interface for system user

 Assign new customers to the system
 Generate report at any time
 Allow the customer to follow their bill information at any time and everywhere.
 Allow the customer to send their complaints
 Allow the employee to view customer’s complaint
 Allow the administrator to create account for employees
 Allow system users to change their passwords

22
 3.2.2 Non-Functional Requirements
It describes user-visible aspects of the system that are not directly related with the functional
behaviour of the system. Non-functional requirements include quantitative constraints, such as:-

 Response time (i.e., how fast the system reacts to user commands) or
 Accuracy (i.e., how precise).

The constraints are described below: -

Performance

Performance requirements define acceptable response times for system functionality.

Response time of the distributed electric power billing System should be faster than the existing
system. Response time refers to the waiting time while the system accesses, queries and retrieves
the information from the databases. And also the system should support many users at a time

User Interface

 The forms prepared for the information are easy to user they can easily understand.
 The system should include attractive interfaces and should replace existing system.

Security and Access permissions

 The system should be secure because the admin page and user page is developed
separately by different language
 The system should be secure and must use encryption to protect the databases. Users
need to be authenticated before having access to any personal data.

23
 3.3 System modelling
3.3.1 System use case diagram

Figure 3.1use case diagram of existing system

3.3.2 System use case diagram documentation

Table 3. 1use Case Description for Register

Section Purpose
Name Register
Identifier 1
Description The customer will create an account for himself.
Actor Customer
Precondition The customer must have valid identity and house number.
User action System response

24
 Basic flow of events 1. The customer will click on 2. The system will display
register tab of the main registration form.
window. 4. The system will check entered data
3.the customer will fill all the and then display successful creation
information’s and click ok. of account and gives privilege for the
customer.

Alternative flow of 1. The system verifies and informs to re-enter again if incorrect
Events information is given and stay on step2.
Post-condition Account will be created for the customer.

Table 3.2 Use Case Description for Login

Section Purpose
Name Login
Identifier 2
Description It allow the actor enter to their page.
Actor Administrator, Employee and customer
Precondition The actor must have correct user name and Password.

Basic flow of events User action System response

1. User clicks the login button 2.TheSystem displays login window
3. User fills his/her user name 4. System authenticates the user
and password. And displays the required window

Alternative flow of The system shows an error message for incorrectness of the username
events and password then resume to step2.

Post-condition System user logged in to the system

Table 3.3 Use Case Description for Current Service

25
 Section Purpose
Name Current service
Identifier 3
Description It allows the user to see the status of the current service.
Actor Customer
Precondition The user must login first.

Basic flow of events User action System response

1. User clicks the current 2.TheSystem displays the status of the
service button current service

Post condition User view detail information

Table 3. 4 Use Case Description for Pay Bill

Section Purpose
Name Pay bill
Identifier 4
Description It allow the customer to pay their bill.
Actor Customer
Precondition The customer must login first.

Basic flow of events User action System response

1. customer clicks the pay bill 2.TheSystem displays pay bill form
button window
3. Customer fills his/her credit 4. System checks the entered credit
card number. card number whether it is correct or
not and
Alternative flow of 5.system
The system shows an error message display the success
for incorrectness of the account
events message
balance and credit card and stay at step 2.

Post condition Customer pay his/her bill birr

26
Table 3. 5 Use Case Description for Send Complaint

Section Purpose
Name Send complaint
Identifier 5
Description It allows the customer to send their complaints.
Actor Customer
Precondition The customer must login first.

Basic flow of events User action System response

1. User clicks the send 2.TheSystem displays complaint form
complaint button window
3. User write his/her 4. System checks the either message is
complaints. entered or not and display success
message.

Alternative flow of The system shows an error message if no data is inserted then stay on
events step2.

Post condition Customer complaint sent

Table 3. 6 Use Case Description for Change Password

Section Purpose
Name Change password
Identifier 6
Description It allow the system users to change their passwords.
Actor Administrator, customer and employee
Precondition Any of the actors must login first.

Basic flow of events User action System response

27
 1. User clicks the change 2.TheSystem displays change
password button password form
3. User fills his/her old 4. System checks the entered password
password and new password And displays success message

Alternative flow of The system shows an error message for incorrectness of the entered old
events password and the new password confirmation then resume to step2.

Post condition Users changed his/her password.

Table 3. 7 Use Case Description for Deactivate Account

Section Purpose
Name Deactivate account
Identifier 7
Description It allows the administrator to deactivate the accounts.
Actor Administrator
Precondition The administrator must login first.

Basic flow of events User action System response

1. The administrator clicks the 2.TheSystem blocks the selected

deactivate button account
4. System display success message.

Post condition The selected account deactivated.

Table 3. 8 Use Case Description for Add Account

Section Purpose
Name Add account
Identifier 8

28
 Description It allows the administrator to add new employee account.
Actor Administrator
Precondition The administrator must login first.

Basic flow of events User action System response

1. The administrator clicks the 2.TheSystem displays add account
add account button form
3. The administrator fills the 4. System check the filled information
employee details. And displays success message

Alternative flow of The system shows an error message or incorrectness of any employee
events data then stay on step2.

Post condition Employee account created.

Table 3. 9 Use Case Description for View Report

Section Purpose
Name View report
Identifier 9
Description It allows the administrator and the employee to see reports.
Actor Administrator and Employee
Precondition The administrator and the employee must login first.

Basic flow of events User action System response

1. The administrator or 2.The System displays report
employee clicks the view report information’s.
button
3. Administrator or employee
view the report

Post condition The administrator or the employee viewed the report.

Table 3.10 Use Case Description for View Complaint

29
 Section Purpose
Name View complaint
Identifier 10
Description It allows administrator and employee to view complaints of users.
Actor Administrator and Employee
Precondition Administrator and employee must login first.

Basic flow of events User action System response

1. Administrator or employee 2.TheSystem displays user complaint
clicks the view complaint information window
button
3. Administrator or employee
view users complaints
Post condition Administrator or employee viewed users complaint.

Table 3.11 Use Case Description for Generate Bill

Section Purpose
Name Generate bill
Identifier 11
Description It allows the employee to generate the bill.
Actor Employee
Precondition The employee must login first.

Basic flow of events User action System response

1. Employee clicks the 2.TheSystem displays bill generation
generate bill button form window
3. Employee fills the current 4. System calculate in birr
metre reading and dates.

Alternative flow of The system shows an error message for incorrectness of the current
events metre reading then stay on step2.

30
 Post condition Bill generated.

Table 3.12 Use Case Description for Generate Report

Section Purpose
Name Generate report
Identifier 12
Description It allows the employee to generate the report.
Actor Employee
Precondition The employee must login first.

Basic flow of events User action System response

1. Employee clicks the 2.The System displays report
generate report button generation form window
3. Employee select the date 4. System display success message

Post condition Report generated.

Table 3.13 Use Case Description for Assign Service

Section Purpose
Name Assign service
Identifier 13
Description It allow the employee to assign services.
Actor Employee
Precondition The employee must login first.

Basic flow of events User action System response

31
 1. The employee clicks the 2.TheSystem displays the deactivated
assign service button services
3. The employee clicks the 4.The system assigns metre number
required service from the list for the new service
sand fill the metre number and
press assign button.

Alternative flow of The system shows an empty select menu if there are no deactivated
events services in the system.
Post condition The user service assigned.

Table 3. 14 Use Case Description for Stop Service

Section Purpose
Name Stop service
Identifier 14
Description It allows the employee to stop the working services.
Actor Employee
Precondition The employee must login first.

Basic flow of events User action System response

1. Employee clicks the view 2.TheSystem displays all services
users button 4. The system deactivates the selected
3. The employee clicks the service.
required service from the lists

Alternative flow of The system shows an empty table if there is no any services in the
events system.
Post condition The system blocks the service.

Table 3. 15 Use Case Description for View bill

32
 Section Purpose
Name View bill
Identifier 15
Description It allows the employee to view all bills information.
Actor Employee
Precondition The employee must login first.

Basic flow of events User action System response

1. Employee clicks the view 2.TheSystem displays all bills detail
bill button
3.Employeeview the all bills
Information including
payment status
Alternative flow of The system shows an empty table if there is no bill in the system.
events
Post condition Employee viewed all bill information.

Table 3. 16 Use Case Description for View Users

Section Purpose
Name View users
Identifier 16
Description It allows the employee to view all users information.
Actor Employee
Precondition The employee must login first.

Basic flow of events User action System response

33
 1. Employee clicks the view 2.TheSystem displays all users detail
users button
3.Employee view the all users
Information

Alternative flow of The system shows an empty table if there is no users in the system.
events
Post condition Employee viewed all users’ information.

Table 3.17 Use Case Description for Import

Section Purpose
Name import
Identifier 17
Description It allows the employee to import user id and house number.
Actor Employee
Precondition The employee must login first.

Basic flow of events User action System response

1. Employee clicks the import 2.TheSystem displays import form
button 4.the system display success message.
3. Employee browse the excel
file and click import button
below the file.
Alternative flow of The system display error message if we select another data format.
events
Post condition User id and house number successfully imported.

34
Table 3.18 Use Case Description for Logout

Section Purpose
Name Logout
Identifier 18
Description It allow the all the actors to leave out their pages.
Actor Administrator, Employee and customer
Precondition They must login first.

Basic flow of events User action System response

1.Userclicks the logout button 2.TheSystem displays login window

Post condition System user logged out from the system.

3.4 Sequence diagram

Sequence diagrams show a succession of interactions between classes or object instances over
time.

SD for register

register form
customer home page database
form controler

click register
button()
display()

validate()
if valid()
fills forms and click ok()
check
integrity()
integrity status()

store()
success message()

if not valid()
error message()

35
Figure 3. 2 Sequence Diagram for Register

SD for login

admin/
admin/
login DB employee/
employee/ home page login form
controler account customer
customer
page

clicks login
button()
display()

enter username and password and click ok()

validate()
if valid()

send()
validate()

user autunticated()
if invalid()

incorrect()

Figure 3. 3Sequence Diagram for Login

SD for current service

customer
customer system database
database
page

login and clicks

current service
button()
initiate()
retrive()

display current service status()

Figure 3. 4Sequence Diagram for Current Service

36
 SD for pay bill

customer payment payment

customer database bank
page form controler

login and clicks

pay bill button()

display()
enter credit card number()

validate()
if valid()

send()
validate()

update ()
pay()
if invalid()

incorrect()

success message()

Figure 3. 5Figure 2.5 Sequence Diagram for Pay Bill

SD for send complaint

customer complaint form

customer databse
page form controler

login and clicks

send complaint
button()

display()
fills and click ok()
validate()
if valid()

send()
success()

if not valid()

incorrect()

Figure 3. 6 Sequence Diagram for Send Complaint

37
 SD for change password

admin/ change
admin/employee/ form
employee/ password databse
customer page controler
customer form

login and clicks

change password
button()

display()

fills and click ok() validate()

if valid()

check()

validate()
save()
success()
if not valid()

incorrect()

Figure 3. 7 Sequence Diagram for Change Password

SD for deactivate account

admin account
admin databse
page table

login and clicks

deactivate button()

display()

select and click ok()

deactivate()

success message()

Figure 3. 8 Sequence Diagram for Deactivate Account

38
 SD for add account

add
admin form
admin account databse
page controler
form

login and clicks

add account
button()

display()

fills the form and click ok() validate()

if valid()
check()
incorrect()
create()
success()

if not valid()

incorrect()

Figure 3. 9 Sequence Diagram for Add Account

SD for view report

employee/
employee/
admin system database
database
admin
page

login and clicks

view report
button()
initiate()

retrive()
display the report status()

Figure 3. 10 Sequence Diagram for View Report

39
 SD for view complaint

employee/
employee/
admin system database
database
admin
page

login and clicks

view complaint
button()
initiate()
retrive()

display the complaint status()

Figure 3. 11 Sequence Diagram for View Complaint

SD for generate bill

employee generate
employee system Database
page bill form

login and clicks

generate report
button()
display()

fills the form and click ok()

validate()
if valid()
check()

validate()

save()
success message()

if not valid()
error message()

Figure 3. 12 Sequence Diagram for Generate Bill

40
 SD for generate report

employee bill
employee Database
page information

login tand clicks

generate report
button()

initiate() retrive()

select the date and click ok()

success message()

Figure 3. 13 Sequence Diagram for Generate Report

SD for assign service

employee deactivated
employee databse
page service

login and clicks

assign service
button()

display()

select the service and click ok() save()

success()

Figure 3. 14 Sequence Diagram for Assign Service

41
 SD for stop service

employee active
employee databse
page service

login and clicks

stop service
button()

display()

select the service and click ok()

save()

success()

Figure 3. 15 Sequence Diagram for Stop Service

SD for view bill

employee
employee system database
database
page

login and clicks

view users
button()
initiate()

retrive()
display all users()

Figure 3. 16 Sequence Diagram for View Bill

42
 SD for view users

employee
employee system database
database
page

login and clicks

view users
button()
initiate()

retrive()
dis play all use rs()

Figure 3. 17 Sequence Diagram for View user

3.5 Activity diagram

Activity diagram used to emphasize the flow of control from activity to activity or to model the
flow of an object as it moves from state at different points in the flow of control.

register

registration form

no

registration
form==valid

yes

store in DB

43
Figure 3. 18 Activity Diagram for Register

login

username and password

no

Username and
password==DB

yes

display required page

Figure 3. 19Activity Diagram for Login

customer login

current service

view from DB

Figure 3. 20Activity Diagram for Current Service

customer login

add service

add service form

no
Add service
form==valid

yes

store in DB

Figure 3. 21 Activity Diagram for Add Service

44
 customer login

pay bill

pay bill form

no
Pay bill
form==valid

yes

update DB

Figure 3. 22 Activity Diagram for Pay Bill

customer login

send complaint

complaint form

no
Complaint
form==valid

yes

save in to DB

Figure 3. 23 Activity Diagram for Send Complaint

45
 customer/employee/
admin login

change password

change password form

no

The form==valid

yes

save in to DB

Figure 3. 24 Activity Diagram for Change Password

admin login

deactivate account

account table

deactivate

update DB

Figure 3. 25 Activity Diagram for Deactivate Account

46
 admin login

add account

add account form

no
Account
form==valid

yes

save in to DB

Figure 3. 26 Activity Diagram for Add Account

employee/admin
login

view report

view from DB

Figure 3. 27 Activity Diagram for View Report

employee/admin
login

view complaint

view from DB

Figure 3. 28 Activity Diagram for View Complaint

47
 employee login

generate bill

generate bill form

update in to DB

Figure 3. 29 activity Diagram for Generate Bill

employee login

generate report

generate form form

update in to DB

Figure 3. 30 Activity Diagram for Generate Report

employee login

assign service

assign service menu

update in to DB

Figure 3. 31Activity Diagram for Assign Service

48
 employee login

stop service

stop service menu

update in to DB

Figure 3. 32 Activity Diagram for Stop Service

employee login

view bill

retrive from DB

Figure 3. 33 Activity Diagram for View bill

employee login

view users

retrive from DB

Figure 3. 34Activity Diagram for View users

49
 employee login

add news

add news form

no
Add news
form==valid

yes

store in DB

Figure 3. 35Activity Diagram for Add News

employee login

import

import form

no
Import
form==valid

yes

store in DB

Figure 3. 36 Activity Diagram for Import

3.6 Class diagram

Class are the basic components of any object oriented software system and UML class
diagrams provide an easy way to represent the system. As well as showing individual classes, in
detail, class diagrams show multiple classes and how they are related to each other.

A class consists of: -

 A unique name (conventionally starting with an uppercase letter)

50
  A list of attributes (int, double, Boolean, string etc.)

Figure 3. 37 class diagram

51
 CHAPTER FOUR

4. SYSTEM DESIGN
System design is the transformation of the analysis model into a system design model. During
system design, developers define the design goals of the project and decompose the system into
smaller subsystems that can be realized by individual teams. The result of system design is a model
that includes a clear description of each of these strategies, subsystem decomposition, and a UML
deployment diagram representing the hardware/software mapping of the system. This chapter
mainly concerned with the design part of all about the billing system.

4.1 Design goal

Design goals describe the qualities of the system that developers should optimize. The design
goals are derived from the non-functional requirements.

Some of the design goals are:

Security:- Since the system hold an important information (data), the system require strong
security features to protect that valuable information i.e. not allow other users or unauthorized
users to access data that has no the right to access it.

Performance: - They should have a fast response time (real time) with maximum throughput. In
the case of the timetabling subsystem, the system should be more reliable in order to satisfy the
constraints than fast response time.

Maintenance:-The system should be easily extensible to add new functionalities at a later stage.
It should also be easily modifiable to make changes to the features and functionalities.

Fault Tolerance:-The system should be able to give response (error message) When the user
enter incorrect input. This recommends the user to enter correct input.

Throughput:-Since electric billing system has web application it is able to perform many tasks
at any time.

Robustness: - The system has the ability to survive wrong applicant inputs. Besides this end
applicant that use electric billing system site have limited access regarding info about applicant
(like name phone no, email address).

52
Modifiability:-The proposed system able to handle applicant data based on selected service
centre such as electric service.

Usability: - electric billing system provide easy user friendly interface for users of the systems.

4.2 System Architecture

Architecture of the System provides a strategy for layering the classes of the system to distribute
the functionality of the software among classes. Furthermore, architectures of the system provide
guidance as to what other types of classes a given type of class will interact with, and how that
interaction will occur. This increases the extensibility, maintainability, and portability of the
systems.

Figure 4. 1 system architecture

4.3 Sub-system Decomposition

Subsystem decompositions help to reduce the complexity of the system. Subsystem is the
collection of classes, associations, operations, events and constraints that are closely interrelated
with each other.

Actors of electric billing systems are:-

 Admin,
 Employee and
 Customer.
53
 Admin user account
 add account
 deactivate account
 View complaint
 View report

Employee/Bill officer use account

 Assign service
 View user
 Generate report.
 Generate bill.
 Change password.
 View bill
 Import
 Stop service
 View report

Customer use account

 Register
 Current service
 Pay bill
 Change password
 Send complaint

4.4 State chart diagram

State chart diagram is used for modelling the dynamic aspects of systems. It is similar to
activity diagram. Both activity and state chart diagrams are useful in modelling the lifetime of an
object. However, activity diagram shows flow of control from activity to activity; whereas state
chart diagram shows flow of control from state to state. State chart modelling is a dynamic

54
modelling technique, one that focuses on identifying the behaviour within our system, behaviour
specified to the instances of a single class. It tries to show different state that an object passes
through its life span. However, it is not necessary to build state chart for every class in the
system; only state charts of complex objects are necessary to be modelled. State chart diagram
enables us to observe the state of complex that simplifies.

Figure 4. 2 state diagram for login

Figure 4. 3 state diagram for registration

4.5Collaboration Diagram
Collaboration diagram represent a combination of information taken from class, sequence, and
use case diagrams describing both static structure and dynamic behaviour of a system.

55
Collaboration diagram show the message flow between objects in an object oriented (OO)
application, and also imply the basic associations or relationships between classes. The rectangle
represent the various objects involves that make up the application, and the line between the
classes represents the relationships (association, aggregation, composition, dependencies, or
inheritance).Use a collaboration diagram (collaboration diagram: An interaction diagram that
shows, for one system event described by one use case, how a group of objects collaborate with
one another.) to show relationships among object roles such as the set of messages exchanged
among the objects to achieve an operation or result.

9: check ()

6: validate ()
Login form Database

10: response ()

7: try again () Login

8: step 4 continues () Controller

4: fill user name and password ()

3: Display the login form ()

5: submit ()

2: select login form ()

: Users
1: users activate UI ()

User
Interface (UI)

Figure 4.4 collaboration diagram for login

56
Figure 4. 5 Collaboration diagram for view report

57
 Generate report.
Generate report
Form Link

3: Bill Officer/Employee
1: Employee click link ()
Fills the form ()

2: Display the form ()

6: return to step 3 ()
9: 9.response ()

: Employee/Bill officer

4: Report ()
5: validate () 8: check ()

7: continue step 4()

Database
Controller

Figure 4.6 Collaboration diagram for Generate report

4.6 Deployment Diagram

Deployment diagram depicts static view of the run time configuration of processing nodes and the
components that run on those nodes. Deployment diagram also shows the hardware for the system,
the software that is installing on that hardware and the middleware used to connect the disparate
machines to one another. A deployment diagram in the unified modelling language models
the physical deployment of artifact on nodes. The nodes appear as boxes, and the artifacts
allocated to each node appear as rectangles within the boxes. Nodes may have sub nodes, which

58
appear as nested boxes. A single node in a deployment diagram may conceptually represent
multiple physical nodes, such as a cluster of database servers.

Figure 4. 7 deployment diagram

4.7Persistent data storage and management

Persistence models also called data model or Entity relationship (ER) models, are used to
communicate the design of a database, usually a relational database, to both users and other
developers. Persistence are used the schema of database. The strength of persistence models is
that data entities are conceptually the same as the table of relation data base and that attributes
are the same as table columns.

59
Figure 4.8 Persistent data storage

4.8Graphical user interface Design

User interface design is the overall process of designing how a user will be able to interact with a
system. The goal of user interface design is to make the user's interaction as simple and efficient
as possible, in terms of accomplishing user goals.

Figure 4.9 User interface for login page

60
Figure 4. 10 User interface for Admin page

61
 CHAPTER FIVE

5. CONCLUSION AND RECOMMENDATIONS

5.1Conclusion
The outcome of this project solve electric power billing system problems that addresses on
customer’s service, then all the customers and service provider was more beneficiary and
satisfied because it helps to save resources like time, money, power and increase efficiency and
effectiveness. So, it results in excellent out come to the organization.

5.2Recommendation
We strongly recommend that one who under goes through this project can succeed, and they pay
attention for Dire Dawa electric power billing. Most of the time has been taken for understanding
the working of existing system, how applications are written in existing system and how a third
party tool can be integrated in this system. The final recommendation towards the target group
who need to work on and improving it can even think of different Billing system entirely developed
for every country. If anybody can their will be functional interface that we didn’t do so using our
project as a source you can improve your own system.

62
 Reference
1. G. Booch, Object-Oriented Analysis and Design with Applications,2nd edition, 1994.
2. M. Fowler, UML Distilled: A Brief Guide to the Standard Object, Third Edition.
3. S. Kendal, Object oriented programing using java, 2009.
4. Carlos Coronel, Steven Morris, and Peter Rob, Design, Implementation, and
Management, Ninth Edition, Joe Sabatino.

63
Submitted by:

________________________ ____________________ ______________________

Student’s Team Leader Signature Date

Approved by:

1. _____________________ ____________________ ______________________

Advisor Signature Date

2. _____________________ ____________________ ______________________

DPC Signature Date

64