Woldia University - 3 Year Cs Section 1 Group 5

DISTRIBUTED ELECTRIC POWER BILLING SYSTEM FOR WOLDIA CITY
WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5 i

INSTITUTE OF TECHNOLOGY
DEPARTMENT OF COMPUTER
SCIENCE
OBJECT ORIENTED SOFTWARE ENGINEERING

PROJECT
GROUP MEMBER ID
1.MEKASH HABTAM…………………………………..111323
2.MAREW NEGA………………………………………….112085
3.DAGNACHEW KINDIE………………………………….
4.GETNET ABATE…………………………………………….
5.MELKAMU GEDEFAW……………………………………..
6.SEGED MULUGETA…………………………………………
WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5

ii
Table of Contents
Title Page No.
CHAPTER ONE..............................................................................................................................1
1. INTRODUCTION.......................................................................................................................1
1.1 Background of The Organization......................................................................................1
1.2 Statement of The Problem.................................................................................................1
1.3Objective.................................................................................................................................2
1.3.1 General Objective............................................................................................................2
1.3.2 Specific Objectives..........................................................................................................2
1.4The Scope................................................................................................................................2
1.5Methodology...........................................................................................................................3
1.5.1 Data Gathering Methodology..........................................................................................3
1.5.2System Analysis and Design Methodology......................................................................3
1.6System Development Model...................................................................................................3
1.7 System Development Tools...................................................................................................4
1.7.1 Software Tools................................................................................................................4
1.7.2 Hardware Tool.................................................................................................................4
1.7.3 Programming Language..................................................................................................4
1.8 Significance............................................................................................................................5
1.9 Feasibility...............................................................................................................................5
1.9.1 Technical Feasibility.......................................................................................................5
1.9.2 Operational Feasibility....................................................................................................5
1.9.3 Economic Feasibility (Cost Benefit Analysis)................................................................6
1.19.4 Schedule Feasibility......................................................................................................7
1.10Work Breakdown Structure..................................................................................................8
CHAPTER TWO.............................................................................................................................9
2. SYSTEM ANALYSIS.................................................................................................................9
2.1 Introduction............................................................................................................................9
2.2 Existing system......................................................................................................................9
2.2.1. Existing System Description..........................................................................................9

iii
2.2.2 Supplementary Requirements..........................................................................................9

2.3 Proposed system...................................................................................................................10
2.3.1 Functional Requirements...............................................................................................11
2.3.2 Non-Functional Requirements......................................................................................11
2.4 Use Case Model...................................................................................................................12
2.4.1 Actor Identification.......................................................................................................12
2.4.2 Use Case Identification.................................................................................................12
2.4.3 Use Case Diagram.........................................................................................................13
2.5 Use Case Description...........................................................................................................14
2.6 Sequence Diagram...............................................................................................................34
2.7 Activity Diagram..................................................................................................................53
2.8 Class Diagram......................................................................................................................67
2.8.1 Class Implementation....................................................................................................68
2.9 Entity-Relationship (ER) Model..........................................................................................69
CHAPTER THREE.......................................................................................................................70
3.DESIGN......................................................................................................................................70
3.1 Design Goal..........................................................................................................................70
3.1.2 Maintenance Criteria.....................................................................................................70
3.1.3 End user Criteria............................................................................................................70
3.1.4 Security requirement.....................................................................................................70
3.2Software Architecture...........................................................................................................71
3.3 Deployment Diagram.......................................................................................................72
3.4 Access Control and Security................................................................................................74
3.5Boundary Conditions and Exception Handling.................................................................75
3.5.1 Boundary Conditions.....................................................................................................75
3.5.2 Exception Handling.......................................................................................................75
CHAPTER 4..................................................................................................................................76
4. IMPLEMENTATION AND TESTING....................................................................................76
4.1 Interface...............................................................................................................................76
4.3 Testing..................................................................................................................................76
4.3.1 Unit Testing...................................................................................................................77

iv
4.3.2 Integration Testing........................................................................................................77

4.3.3 System Testing..............................................................................................................77
CHAPTER 5..................................................................................................................................79
5. CONCLUSION AND RECOMMENDATION........................................................................79
5.1 Conclusion...........................................................................................................................79
5.2 Recommendation.................................................................................................................79
References......................................................................................................................................80

v
CHAPTER ONE
1. INTRODUCTION
1.1 Background of The Organization
Woldia city is found in Amhara region in north wollo which is located on 360km far away
from Bahirdar town and 520km far away from Addis Ababa. The city was organized as a zone
since 1938 E.C. In wollo there are different cultural holidays and celebrations like coffee
ceremony and most of the year is hot all the day, but always with a refreshing breeze. At night it
cools down. Today besides its potential attractions, woldia already has a significance flow of
tourist traffic because of its location on the main historic route of the country. In woldia city
there are governmental and nongovernmental organizations which facilitate the development of
the town and provide services to the community. Most of these organization uses manual type of
billing system [1].
Woldia city electric power utility is found in woldia city around manahariya. currently there
are 100 employees found in the organization and it distributes the service based on user’s
requirement. That means whether the service is residential, commercial or other services. The
distributed electric power billing system that is proposed to develop is a system that provides
billing system service for electric power utility of woldia city. The system controlled by central
administrator. Currently the organizations information system process tasks in the form of paper
based or traditional file systems. Therefore, the new system should solve this system.
1.2 Statement of The Problem
Many problems that exist in woldia city electric power billing system to finish their works
properly and the organization are currently facing a challenge among thus challenges there are
losing of data because for the current system there is no software that performs billing system
that means their bill is prepare in dessie so there is no designed database for woldia city electric
power utility office and the system is less secure. 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 because it is paper based. Generally, this all recommend us
WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5 1

to develop web based billing system as well as desktop application to make the operation easy,
accurate, flexible and to prevent data loss.
1.3Objective
1.3.1 General Objective
The general objective of this project is to develop Distributed Electric Power Billing System for
woldia city.
1.3.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.4The Scope
The scope of this project focuses mainly on functional aspects of distributed electric power
billing system such as: -
 Accurate way of recording and storing user information into the database.
 Accurate way of accessing and retrieving bill information from the database.
 Updating customer information
 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 customer information
 Enable the employee to generate reports of bill
 Enable the user to pay money for bill
 Enable the employee to check payment of customer

2
1.5Methodology
1.5.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.
1.5.2System 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 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.
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 allowsus
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[2]. Therefore, we enforced to select this system development
approach.
1.6System Development Model
The system development model methodology used was waterfall with feedback model
among other model because it is simple and good for developer when they knows requirement
specification. [2].

3
1.7 System Development Tools
There are some tools that are used to develop the system. These are:
1.7.1 Software Tools
 WAMP server 2.5: we use it as server.

 Adobe Photoshop:for editing images and design some interfaces.
 Notepad++ 6.7.4:also for designing tool.
 Google Chrome 1.3.26.9: to run the system
 Mozilla Firefox 4.42.0.0: to run the system
 NetBeans 8.0.2: to develop admin page.
 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
 mysql-connector: to connect java program with database.
 Sharit: to share file from mobile toPC
1.7.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 4GB RAM
o Windows 10 operating system
o Intel(R) Core(TM) i3-4005U CPU @ 1.70GHz processor
1.7.3 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.

4
 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.8 Significance
The benefits gained from the project after implementation are: -

 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.9 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.
1.9.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.9.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.

5
1.9.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 Table
No Name of item Quantity Single price Total
1. Flash-disk 2 180 360
2. Paper 1 packet 130 130
3. Printing paper 80 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

6
1.19.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.
Figure 1.1 Project Time Schedule

7
1.10Work Breakdown Structure
Software development is a team work that every group member plays a role by his /her
ability they have in different phases of the project. Therefore, our work breakdown structure was
described in table 1.2.
Table 1.2 Work Breakdown Structure
No Phase Student to be participated
1 Coordinators Mekash Habtam
2 Data collecting Melkamu Gedafaw
3 Requirement analysis Getnet Abate
4 System designing Dagnachew Kindie
5 System implementation Marew Nega
6 Testing Seged Mulugeta
CHAPTER TWO
2. SYSTEM ANALYSIS

8
2.1 Introduction
In this project, we used an object oriented System development methodology which

incorporates two principal phases. In this chapter, what will we do is the object oriented analysis
(OOA) in this phase we can identify the relationship between objects and the interaction between
each object.
2.2 Existing system
2.2.1. Existing System Description
The existing system of the electric power billing system for woldia city is working manually
that means the bill was prepared in dessie electric power utility then the bill paper was sent to
woldia electric power utility. For each month the bill was prepare in dessie so it reaches to
woldia after one month. Therefore, there are a lot of problems involved in the system. For
example, when bill paper is transmitted from town to town there is losing of file, transportation
cost, the system doesn’t allow the user to pay bill for the current month, 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.Busines 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.
 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 want to use the service must have legal house.
 Every customers age must be greater than 18.

9
2.Constraints
 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 itscopy.
2.3 Proposed system
During our observation and interview of users we have observed certain problems from the
manual based system; the general overview of our proposed system is to address the problem of
the existing manual system of electric power bill. The proposed system solves those entire
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.
 Easy to use (user friendly).
 Reduce the need of paper
2.3.1 Functional Requirements
A functional requirement specifies what the proposed system should do. And describe the
interactions between the system and its environment [2]. For example, functional requirement of
our system is must assign customer bill account and make accessible for a user, allow the
employee 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

10
 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
2.3.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)
[2]. 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.

11
2.4 Use Case Model
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 [3].
2.4.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 control bill information.
2.4.2 Use Case Identification
 Register: - it allows the new user to sign up to the system.

 Login: - it allows the authenticated user to sign in to the system.
 Current service: - allows the customer to see his service status.
 Add service: - allows the user to add the new service.
 Pay bill: - allows the user to pay his/her bill payment.
 Send complaint: - allows the user to send his complaints.
 Change password: - allows the user to change his account password.
 Deactivate account: - allows administrator to block employee account.
 Add account: - allows the administrator to add employee account.
 View report: - allows the employee and the administrator to view the report.
 View complaint: - allows the employee and the administrator to view the complaints.
 Generate bill: - allows the employee to generate the customer’s bill.
 Generate report: - allows the employee to generate the report.
 Assign service: - allows the employee to assign deactivated services.
 Stop service: - allows the employee to deactivate the required service.
 View bill: - allows the employee to view all bills status.
 View users: - allows the employee to view all customer’s information.
 Add news: - allows the employee to add news
 Import: - allows the employee to import user id and house number

12
 Logout: - allows the users to leave out from his/her page.
2.4.3 Use Case Diagram
Use Case Diagram represents user requirements gathered during requirement elicitation,
contains use case, actors, system boundary and their relationships. Use Case diagram of our
system is shown in figure 2.1 below.
Figure 2.1 Use Case Diagram

13
2.5 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 from Table 2.1 to 2.20 below.
Table 2.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.
Basic flow of events User action System response
1.The customer will click on 2.The system will display registration
register tab of the main 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 inform to re-enter again if incorrect
Events information is given and stay on step2.
Postcondition Account will be created for thecustomer.

14
Table 2.2Use Case Description for Login
Section Purpose
Name Login
Identifier 2
Description It allow theactor enter to their page.
Actor Administrator, Employee and customer
Precondition The actor must have correct user name and Password.
Basic flowofevents Useraction Systemresponse

1. Userclicks the login button 2.TheSystem displays login window
3. User fillshis/her user name 4. System authenticates the user
and password. anddisplaysthe required window
Alternative flow of Thesystem shows an errormessageforincorrectness oftheusername and

events password thenresume to step2.
Postcondition System userlogged in tothe system

15
Table 2.3Use Case Description for Current Service
Section Purpose
Name Current service
Identifier 3
Description It allow theuser to see the status of the current service.
Actor Customer
Precondition The user must login first.

1. Userclicks the current 2.TheSystem displays the status of the
service button current service
Postcondition Userview detail information

16
Table 2.4Use Case Description for Add Service
Section Purpose
Name Add service
Identifier 4
Description It allow the customer to add new services.
Actor Customer
Precondition The customer must login first.

1. Userclicks the add service 2.TheSystem displays the form
button window
3. User fillshis/her 4. The systemwillcheckentereddata
information. andthendisplaysuccessfuladdition of
the new service for the customer.
Alternative flow of Thesystemverifiesandinformtore-enteragainifincorrect information is
events givenand stayon step2.
Postcondition New service added.

17
Table 2.5Use Case Description for Pay Bill
Section Purpose
Name Pay bill
Identifier 5
Description It allow thecustomer to pay their bill.
Actor Customer

1. customerclicks the pay bill 2.TheSystem displays pay bill form
button window
3. customerfillshis/her credit 4. System checks the entered credit
card number. card number whether it is correct or
not and
Alternative flow of Thesystem shows an errormessageforincorrectness oftheaccount
events balance and credit card and stay at step 2.
Postcondition Customer payed his/her bill birr

18
Table 2.6 Use Case Description for Send Complaint
Section Purpose
Name Send complaint
Identifier 6
Description It allow the customer to send their complaints.
Actor Customer

1. Userclicks the send 2.TheSystem displays complaint form
complaint button window
3. User write his/her 4. System checks the either message
complaints. is entered or not anddisplay success
message.
Alternative flow of Thesystem shows an errormessageif no data is insertedthenstay on

events step2.
Postcondition Customer complaint sent

19
Table 2.7 Use Case Description for Change Password
Section Purpose
Name Change password
Identifier 7
Description It allow thesystem users to change their passwords.
Actor Administrator, customer and employee
Precondition Any of the actors must login first.

1. Userclicks the change 2.TheSystem displays change
password button password form
3. User fillshis/her old 4. System checks the entered password
password and new password anddisplayssuccess message
Alternative flow of Thesystem shows an errormessageforincorrectness ofthe entered old

events password and the new password confirmationthenresume to step2.
Postcondition Users changed his/her password.

20
Table 2.8 Use Case Description for DeactivateAccount
Section Purpose
Name Deactivate account
Identifier 8
Description It allow theadministrator to deactivate the accounts.
Actor Administrator
Precondition The administrator must login first.
1. The administratorclicks the 2.TheSystem blocks the selected

deactivatebutton account
4. System display success message.
Postcondition The selected account deactivated.

21
Table 2.9 Use Case Description for Add Account
Section Purpose
Name Add account
Identifier 9
Description It allow 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. anddisplayssuccess message
Alternative flow of Thesystem shows an errormessageforincorrectness ofany employee

events data then stayon step2.
Postcondition Employee account created.

22
Table 2.10 Use Case Description for View Report
Section Purpose
Name View report
Identifier 10
Description It allow the administrator and the employee to see reports.
Actor Administrator and Employee
Precondition The administrator and the employee must login first.

1. The administrator or 2.TheSystem displays report
employee clicks the view report information’s.
button
3. Administrator or employee
view the report
Postcondition The administrator or the employee viewed the report.
Table 2.11 Use Case Description for View Complaint
Section Purpose
Name View complaint
Identifier 11
Description It allows administrator and employee to view complaints of users.
Actor Administrator and Employee
Precondition Administrator and employee must login first.

1. Administrator or 2.TheSystem displays user complaint
employeeclicks the view information window
complaint button
3. Administrator or
employeeview users complaints
Postcondition Administrator or employee viewed users complaint.

23
Table 2.12 Use Case Description for Generate Bill
Section Purpose
Name Generate bill
Identifier 12
Description It allow theemployee to generate the bill.
Actor Employee
Precondition The employee must login first.

1. Employeeclicks the generate 2.TheSystem displays bill generation
bill button form window
3. Employeefillsthe current 4. System calculate in birr
metre reading and dates.
Alternative flow of Thesystem shows an errormessageforincorrectness ofthecurrent metre

events readingthenstayon step2.
Postcondition Bill generated.

24
Table 2.13 Use Case Description for Generate Report
Section Purpose
Name Generate report
Identifier 13
Description It allow the employee to generate the report.
Actor Employee

1. Employeeclicks the generate 2.TheSystem displays report
report button generation form window
3. Employee select the date 4. System display success message
Postcondition Report generated.

25
Table 2.14 Use Case Description for Assign Service
Section Purpose
Name Assign service
Identifier 14
Description It allow theemployee to assign services.
Actor Employee

1. The employeeclicks the 2.TheSystem displays the deactivated
assignservicebutton services
3. The employee clicks the 4.The system assigns metre number
required service from the for the new service
listsand fill the metre number
and press assign button.
Alternative flow of Thesystem shows an empty select menu if there is no deactivated

events services in the system.
Postcondition The user service assigned.

26
Table 2.15 Use Case Description for Stop Service
Section Purpose
Name Stop service
Identifier 15
Description It allow theemployee to stop the working services.
Actor Employee

1. Employeeclicks the view 2.TheSystem displays all services
usersbutton 4.The system deactivates the selected
3. The employee clicks the service.
required service from the lists
Alternative flow of Thesystem shows an empty table if there is no any services in the
events system.
Postcondition The system block the service.

27
Table 2.16 Use Case Description for View bill
Section Purpose
Name View bill
Identifier 16
Description It allow theemployee to view all bills information.
Actor Employee

1. Employeeclicks the view bill 2.TheSystem displays all bills detail
button
3.Employeeview the allbills
Information including
payment status
Alternative flow of Thesystem shows anempty table if there is no bill in the system.
events
Postcondition Employee viewed all bill information.

28
Table 2.17 Use Case Description for View Users
Section Purpose
Name View users
Identifier 17
Description It allow the employee to view all users information.
Actor Employee

1. Employeeclicks the view 2.TheSystem displays all users detail
users button
3.Employee view the allusers
Information
Alternative flow of Thesystem shows an empty table if there is no users in the system.
events
Postcondition Employee viewed all users information.

29
Table 2.18 Use Case Description for Add News
Section Purpose
Name Add news
Identifier 18
Description It allow the employee to add news.
Actor Employee

1. Employeeclicks the add 2.TheSystem displays add news form
news button 4.thesystem display success message.
3.Employee insert news and
click send button.
Alternative flow of Thesystem display error message if no data is inserted.

events
Postcondition News successfully added.

30
Table 2.19 Use Case Description for Import
Section Purpose
Name Import
Identifier 19
Description It allow the employee to import user id and house number.
Actor Employee

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

31
Table 2.20 Use Case Description for Logout
Section Purpose
Name Logout
Identifier 20
Description It allow theall the actors to leave out their pages.
Actor Administrator, Employee and customer
Precondition They must login first.

1.Userclicks the logout button 2.TheSystem displays login window
Postcondition System userlogged out from the system.

32
2.6 Sequence Diagram
Sequence diagrams show a succession of interactions between classes or object instances

over time [4]. The sequence diagram of each use case described in the following figures from
Figure 2.2 to Figure 2.20.
Figure 2.2 Sequence Diagram for Register

33
Figure 2.3 Sequence Diagram for Login

34
Figure 2.4 Sequence Diagram for Current Service

35
Figure 2.5 Sequence Diagram for Add Service

36
Figure 2.6 Sequence Diagram for Pay Bill

37
Figure2.7 Sequence Diagram for Send Complaint

38
Figure2.8 Sequence Diagram for Change Password

39
Figure 2.9 Sequence Diagram for Deactivate Account

40
Figure 2.10 Sequence Diagram for Add Account

41
Figure 2.11 Sequence Diagram for View Report

42
Figure 2.12 Sequence Diagram for View Complaint

43
Figure 2.13 Sequence Diagram for Generate Bill

44
Figure 2.14 Sequence Diagram for Generate Report

45
Figure 2.15 Sequence Diagram for Assign Service

46
Figure 2.16 Sequence Diagram for Stop Service

47
Figure 2.17 Sequence Diagram for View Bill

48
Figure 2.18 Sequence Diagram for View Bill

49
Figure 2.19 Sequence Diagram for Add News

50
Figure 2.20 Sequence Diagram for Import

51
2.7 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 [2]. The
activity diagram of each use case described in the following figures from Figure 2.19 to Figure
2.39.
Figure 2.21 Activity Diagram for Register

52
Figure 2.22 Activity Diagram for Login
Figure 2.23Activity Diagram for Current Service

53
Figure 2.24 Activity Diagram for Add Service

54
Figure 2.25 Activity Diagram for Pay Bill

55
Figure 2.26 Activity Diagram for Send Complaint

56
Figure 2.27Activity Diagram for Change Password

57
Figure 2.28 Activity Diagram for Deactivate Account

58
Figure 2.29 Activity Diagram for Add Account

59
Figure 2.30 Activity Diagram for View Report
Figure 2.31 Activity Diagram for View Complaint

60
Figure 2.32 Activity Diagram for Generate Bill
Figure 2.33 Activity Diagram for Generate Report

61
Figure 2.34 Activity Diagram for Assign Service

62
Figure 2.35 Activity Diagram for Stop Service
Figure 2.36 Activity Diagram for View bill

63
Figure 2.37Activity Diagram for View users
Figure 2.38Activity Diagram for Add News

64
Figure 2.39 Activity Diagram for Import

65
2.8 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)

 A list of attributes (int, double, boolean, string etc.)
 A list of methods [4].
Figure 2.40 Class Diagram

66
2.8.1 Class Implementation
The pseudocode for some of use cases are given below.

Pseudocode for login
Procedure
Method name: login ()
Begin
Get username;
Get password;
Roll;
IF (Username==Entered Username && password==Entered password &&
Roll==selected roll)
THEN
Login successful
Else
Login failed you have entered incorrect username and password
End
Pseudocode for create account
Procedure
Method name:register ()
Begin
Get full name;
Get ID_No;
Get password;
(Check input validation)
IF (input is valid)
{
Register account to database
Show success message
} ELSE
Display error message and ask correct user information
END

67
2.9 Entity-Relationship (ER) Model
The E-R diagram represents the conceptual database as viewed by the end user. It depicts the
database’s main components: entities, attributes, and relationships. Entities is object of interest of
end user. Attributes is characteristics of entities. Relationship is association between entities
[5].E-R diagram for the system is represented in figure 2.37 below.
Figure 2.41 ER Diagram

68
CHAPTER THREE
3.DESIGN
3.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 [2].Design goals are:
3.1.1 Performance criteria
The system is programmed with Java,PHP and MYSQL that reduce the complexity of the
algorithm such as amount of space that the algorithm needs and running time that replies in a
minimum amount of time.
3.1.2 Maintenance Criteria
The system was easily modifiable like registering new users, activating and deactivating
from the database. It is readable since the source code of the system is restricted to be understood
by the programmer of the system or a person who has a great knowledge on Microsoft web
developing languages. Such as PHP, HTML, CSS.
3.1.3 End user Criteria
From the end users’ perspective, the system was designed in such a way that it is easy to
learn and use efficiently although the system can be flexible and responsible for the mobile users,
laptop users as well as Desktop users.
3.1.4 Security requirement

Security For users of the system
 The system provides privileges to Administrator can create username and password to log
in to the system.
 No one can view the sites of administrator.
 And also system has another security keeping mechanism, which is called Session and
JavaScript which can help users to log in to the system and cannot back to the securable
pages such as user name and password respectively.
 The Administrator of the system which is more secured part of the system protection
because it uses desktop application.

69
 Only a person who have a privilege to the system can logon by providing username and
password.
 And also the password was encrypted by md5 encryption mechanism.
3.2Software Architecture
The architecture that we have used for the system is a 3tierwhichisa web based application
in which the presentation tier, a business or data access tier ,and a data tier are developed and
maintained as independent modules on separate platforms [2].Three layers in the three tier
architecture areas follows:
1. Clientlayer:
2. MiddleLayer:
3. Datalayer:
1. Client layer:
The client tier is the applications of user interface containing data entry forms and client
side applications. For example, registrations form for new users which contain text box, labels,
and button set c. So, it displays data to the user and users interact directly with the application
through user interface. The client tier interacts with the web/application server to make requests
and to retrieve data from the database. It then display to the user the data retrieved from the
server.
2.Middle Layer:
The middle tier(web/application server) implements the business logic, controller logic and
presentation logic to control the interaction between the application’s clients and data. The
controller logic processes client requests such as requests to view complaints, to deactivate
users or to retrieve data from the database.
3. Data layer:
The system has data access layer which requires QL skill in the form of DDL and DML
contains methods to connect with database and to perform insert ,update ,delete, get data from
database based on users input data.

70
Figure 3.1Software Architecture diagram
3.3 Deployment Diagram
A Deployment Modelling shows the configuration of run-time processing elements and

the software components, processes, and objects. And also it shows the physical configuration of
software and hardware [2].Figure 3.3 represents deployment diagram below.

71
Figure 3.2 Deployment Diagram
Figure 3.3 relation among tables

72
3.4 Access Control and Security

Access control is way of limiting access to a system or to physical or virtual resources. In
computing, access control is a process by which users are granted access and certain privileges to
systems, resources or information[4].
Table 3.1 Table of Access Control and Security
Actor
Function Admin Customer Employee
Login   
Register  
Pay bill 
View bill status   
Send complaint  
View complaint  
Change password    
Generate bill 
Assign service   
View user   
Generate report   

73
View report   
Add news   
View news   
3.5Boundary Conditions and Exception Handling
3.5.1 Boundary Conditions
Client side
 Internet connection should be available on the client side

 Web browser is demanding to connect with the web server of the system
 The customer should be legitimate and having an account provided by the system
 It should give the URL (Uniform Resource Locator) address of the web site.
 The customer communicates the different hyperlinks/pages using the homepage.
 The Customer can get different service from viewing the available bill up to
downloading and making payment.
Server side
 The system administrator manages the employee account using his/her preferred
privileges
 It automatically saves the changes when manages employees account.
3.5.2 Exception Handling
 The system displays messages if it is tried to access using wrong/invalid account by

checking against the account table.
 The Customer can’t make transaction if they have not sufficient balance from the
bank database.
 If the customer enters credit card number, it checks make transaction if there is
sufficient balance in his account.
 If the employee is blocked, he cannot login to the system
 If the user did not make payment their bill was not active to download.

74
CHAPTER 4
4. IMPLEMENTATION AND TESTING
4.1 Interface
Interface of DEPBS admin login page
Figure 4.1 Admin Login Page
4.2 implementation
4.3 Testing
From different testing methodologies we have used the following one to ensure that the
proposed system is meet its goal or to identify any error/problem and to take an appropriate
measure.

75
4.3.1 Unit Testing
In this type of testing we divided the general system transaction in to number of modules.
Since we have functionalities which is a collection of the use case's that we have test each
module separately whether each use case works correctly or not. We have used this testing
technique to verify the functionality of a specific section of code, usually at the function level. So
we enforced to use this method of testing to ensure that the specific function is working as
expected.
4.3.2 Integration Testing
Here we used this type of testing to test whether one module is integrated to the other
module or not .In general, we have used this testing to verify the interfaces between components
against a software design. We used to expose defects in the interfaces and interaction between
integrated components (modules)
4.3.3 System Testing
This is the third testing techniques that we have used it at the end of the implementation.
To ensure whether it meets the requirements of the organization and the clients or not
4.4 Functional Test Specification
Test name: Login Customer

Test Description: The login test is used to check whether any one access the system or only
those registered customers have an access to the system
Test case Name: Login
Table 4.1 Login Test Description Table
Action Test Procedure Input Expected result test Pass/fail
Test login The customer should click Customer’s The page that enables Pass-the
system login button appropriate userId the customer to pay customer can
and password. bill, download bill pay, download
Log-in Page screen is
and send complaint is and viewbills.
displayed
displayed

76
Customer enters his/her

user name and password.
Incorrect user Id “Please Enter correct Fail - Customer
and password username and can’t access the
password “ message pages.
display,
Purpose of test: authorization test
Testing objects: Login checking
Test focus: correct User Id and Password validation
Test Process
1. Starting condition
 The customer should click login button

 The login Page screen is shown.
2. Input
 Customer enters his/her personal user Id and password

 Then clicks login button.
3. Expected result
 At the time of login, if the user Id and password are valid customers page
displayed and accessible to the customer.
4. Failure Condition
 If customer enters invalid user Id and password, please enter valid username
and passwordmessage displayed.

77
CHAPTER 5
5. CONCLUSION AND RECOMMENDATION

5.1 Conclusion
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.2 Recommendation
We strongly recommend that one who under goes through this project can succeed, and
they pay attention for woldia 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.
After all, General recommendation that we will give for any person is that there is
nothing that is impossible to do even from nothing but as much as you can be confidential and
use the time properly. Then all things will be effective with the help of “almighty God”.

78
References
[1] woldiatourism, “home”,Availabel at http://www.woldiatourism.wordpress.com, last accessed

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

79

80

Woldia University - 3 Year Cs Section 1 Group 5

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Woldia University - 3 Year Cs Section 1 Group 5

Uploaded by

Copyright:

Available Formats

DISTRIBUTED ELECTRIC POWER BILLING SYSTEM FOR WOLDIA CITY

WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5 i

OBJECT ORIENTED SOFTWARE ENGINEERING

WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5

WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5

2.2.2 Supplementary Requirements..........................................................................................9

WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5

4.3.2 Integration Testing........................................................................................................77

WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5

1.1 Background of The Organization

1.2 Statement of The Problem

WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5 1

1.3.1 General Objective

1.3.2 Specific Objectives

The specific objective of this project is: -

WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5

1.5.1 Data Gathering Methodology

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

1.5.2System Analysis and Design Methodology

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

1.6System Development Model

WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5

1.7 System Development Tools

 WAMP server 2.5: we use it as server.

1.7.2 Hardware Tool

 Flush disk:for backup and file transfer.

1.7.3 Programming Language

 HTML: for describing webpage and interface application.

WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5

The benefits gained from the project after implementation are: -

1.9.1 Technical Feasibility

1.9.2 Operational Feasibility

 The new system fits with the existing operational system.

WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5

1.9.3 Economic Feasibility (Cost Benefit Analysis)

 Reduce the amount of resource required in office.

 Getting well organized information in short period of time

Table 1.1 Budget Table

No Name of item Quantity Single price Total

1. Flash-disk 2 180 360

2. Paper 1 packet 130 130

3. Printing paper 80 pages 3 682

4. Laptop computer 1 11,000 11,000

7. Mobile card 10 10 100

WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5

1.19.4 Schedule Feasibility

Figure 1.1 Project Time Schedule

WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5

1.10Work Breakdown Structure

Table 1.2 Work Breakdown Structure

No Phase Student to be participated

1 Coordinators Mekash Habtam

2 Data collecting Melkamu Gedafaw

3 Requirement analysis Getnet Abate

4 System designing Dagnachew Kindie

5 System implementation Marew Nega

6 Testing Seged Mulugeta

WOLDIA UNIVERSITY | 3TH YEAR CS SECTION 1 GROUP 5

In this project, we used an object oriented System development methodology which

2.2 Existing system

2.2.1. Existing System Description

2.2.2 Supplementary Requirements