Budget Tracking

WITH THE NAME OF ALLAH, MOST GRACIOUS MOST MERCIFUL.

Final Project

Budget Tracking

Project Supervisor
Dr. Khurram Shahzad
CS &IT Department

Submitted By
Muhammad Rashid Ashraf
Student ID: MCC02143020
Ahsan Hanif
Student ID: MCC02141013
The University Of Lahore.
Department of Computer Science and Information Technology.

UNIVERSITY OF LAHORE 1
 Budget Tracking

Undertaking

We certify that project work titled Budget Tracker is our own work. No portion of the
work presented in this project has been submitted in support of another award or qualification
either at this institution or elsewhere. Where material has been used from other sources, it has
been properly acknowledged.

Group Members:

Name: Muhammad Rashid Ashraf (MCC02143020)

Signature: ____________________

Name: Ahsan Hanif (MCC02141013)

Signature: ____________________

Approved by:

Dr. Khurram Shahzad

Signature: __________

UNIVERSITY OF LAHORE 2
 Budget Tracking

UNIVERSITY OF LAHORE 3
 Budget Tracking

DEDICATION

We would like to dedicate this project to our parents, teachers and friends whose
encouragement, motivation and assistance ensured our successful completion of this project,
especially Dr. Khurram Shahzad who help us in all situations and their thoughtful suggestions.

UNIVERSITY OF LAHORE 4
 Budget Tracking

ACKNOWLEDGEMENT

We would like to thank our parents for their encouragement; our various teachers whose
teaching helped us to complete this project. We would like to express our gratitude towards our
project instructor Dr. Khurram Shahzad for his dedication, motivation and sincere guidance
throughout project work. Special thanks to all friends and teachers. Finally we would like to
acknowledge our University for giving us opportunity to work on this project.

UNIVERSITY OF LAHORE 5
 Budget Tracking

Abstract
Budget Tracker offers a virtual platform to people and Business to adjust the budget of
daily routine. Budget tracker is a simple app for adjustment of daily routine expense and income.

Budget tracker provide an online access for every register person. Business can manage
their business expense and income through this application.

Budget Tracker is use for daily monthly and weekly expense. Tax is increase after one
year on everything.

The basic theme of this project to manage the budget through application where user can
manage their budgets. The Budget tracking application is supposed document to have the
following features. This app should provide login facility to the Admin and the app also provides
the admin to check the information of display edit, delete and update it.

The purpose of this mobile application is developing structured, efficient and

effectiveness to manage the budgets. Through this application user may be able to manage their
expenses according to their income.

UNIVERSITY OF LAHORE 6
 Budget Tracking

Table of Contents
1. Introduction ....................................................................................................................... 11
1.1 Project Overview ............................................................................................................ 11
1.2 Problem Statement ......................................................................................................... 11
1.3 Why we use it? ............................................................................................................... 12
1.4 Groups ............................................................................................................................ 12
1.4.1 Administration:............................................................................................................... 12
1.4.2 User: ............................................................................................................................... 12
1.5 Scope .............................................................................................................................. 12
1.6 Design Goals .................................................................................................................. 12
1.6.1 Main App Pages: ............................................................................................................ 12
1.7 Goals............................................................................................................................... 13
2. Software Requirement Specification (SRS) ........................................................................ 14
2.1 Introduction .................................................................................................................... 14
2.2 Existing Solution ............................................................................................................ 14
2.3 Proposed Solution .......................................................................................................... 15
2.4 Project Scope .................................................................................................................. 15
2.4.1 Admin site ...................................................................................................................... 15
2.5 Overall description product ............................................................................................ 15
2.5.1 Product perspective ........................................................................................................ 15
2.5.2 Product function ............................................................................................................. 16
2.6 System analysis .............................................................................................................. 16
2.6.1 Hardware specification ................................................................................................... 16
2.6.2 Software Requirement .................................................................................................... 16
2.6.3 Network requirement...................................................................................................... 16
2.7 System Requirements ..................................................................................................... 17
2.7.1 Functional Requirements................................................................................................ 17
2.7.2 Non-Functional Requirements. ...................................................................................... 17
2.8 Vision Document............................................................................................................ 19
2.9 Supplementary Specification ......................................................................................... 19
2.9.1 Usability: ........................................................................................................................ 19
2.9.2 Legal Requirement: ........................................................................................................ 19

UNIVERSITY OF LAHORE 7
 Budget Tracking

2.9.3 Supportability: ................................................................................................................ 19

2.10 Quality Assurance Plan .............................................................................................. 19
2.10.1 Hardware and Software Specification ............................................................................ 20
2.10.2 QA Planning ................................................................................................................... 20
2.10.3 Agile Development Model (Scrum) ............................................................................... 20
2.11 Configuration Management Plan ................................................................................ 22
3. Analysis .............................................................................................................................. 24
3.1 USE CASES ................................................................................................................... 24
3.2 Use-Case (Essential) ...................................................................................................... 25
3.3 Use-Case Scenarios and Usage: ..................................................................................... 25
3.3.1 Table1: User Registration............................................................................................... 25
3.3.2 Table2: Budget Tracking Setting ................................................................................... 26
3.3.3 Table3: Budget Tracker Online Check-up ..................................................................... 27
3.3.4 Table4: User Registration............................................................................................... 28
3.3.5 Table5: Set Budget ......................................................................................................... 29
3.3.6 Table6: User Registration Approval .............................................................................. 30
3.3.7 Table8: Static Page Handling ......................................................................................... 31
3.4 Use-Cases (Elaborated) .................................................................................................. 32
3.4.1 Table10: Budget Tracking (Elaborated) ......................................................................... 33
3.4.2 Table15: User Account Verification .............................................................................. 35
4. Design ................................................................................................................................ 36
4.1 Database Design ............................................................................................................. 36
4.2 Entity Relationship Diagram .......................................................................................... 37
4.3 Domain Model................................................................................................................ 38
4.4 Operation Contracts........................................................................................................ 39
4.5 System Sequence Diagram ............................................................................................. 40
4.5.1 Sequence Diagram (User Login) .................................................................................... 40
4.5.2 Sequence Diagram (User) .............................................................................................. 41
4.6 Collaboration Diagram ................................................................................................... 41
4.6.1 Collaboration Diagram (Set budget) .............................................................................. 42
4.6.2 Collaboration Diagram (User Registration) ................................................................... 42
4.6.3 Collaboration Diagram (Admin Panel) .......................................................................... 43

UNIVERSITY OF LAHORE 8
 Budget Tracking

4.7 Class Diagram ................................................................................................................ 43

4.8 Component Diagram ...................................................................................................... 45
4.9 Deployment Diagram ..................................................................................................... 45
4.10 Architectural Design ................................................................................................... 47
4.11 Activity Diagram ........................................................................................................ 47
4.11.1 Activity Diagram (Admin) ............................................................................................. 48
4.11.2 Activity Diagram (User)................................................................................................. 49
4.12 Data Flow Diagram .................................................................................................... 50
5. Testing [SQA Introduction and Test Cases]........................................................................ 51
5.1 Testing ............................................................................................................................ 51
5.2 Black Box Testing .......................................................................................................... 51
5.2.1 Equivalence partitioning ................................................................................................ 51
5.2.2 Methodology Adopted for EP ........................................................................................ 51
5.3 Test case for Budget Tracking ....................................................................................... 52
5.3.1 Test case for Signup ....................................................................................................... 52
5.3.2 Test case for Login ......................................................................................................... 52
5.3.3 Test case for My Budget ................................................................................................ 52
5.3.4 Test case for Add Expenses ........................................................................................... 53
5.3.5 Test case for Add Income............................................................................................... 53
5.3.6 Test case for Add Budget ............................................................................................... 53
5.3.7 Test case for Display Budget ......................................................................................... 54
5.3.8 Test case for Add Account ............................................................................................. 54
5.4 White Box Testing ......................................................................................................... 54
5.5 Cyclomatic Complexity.................................................................................................. 54
5.6 Regression Testing ......................................................................................................... 55
5.7 System Testing ............................................................................................................... 56
5.8 Stress Testing ................................................................................................................. 56
5.9 Performance Testing ...................................................................................................... 56
6. Tools and Techniques ........................................................................................................ 58
6.1 Tools and technique ....................................................................................................... 58
6.1.1 Language used ................................................................................................................ 58
6.2 Android Development .................................................................................................... 58

UNIVERSITY OF LAHORE 9
 Budget Tracking

6.3 Using Shared Preferences............................................................................................... 59

6.3.1 User Preferences ............................................................................................................. 59
6.3.2 Using the Internal Storage .............................................................................................. 59
6.3.3 Saving cache files ........................................................................................................... 59
7. Summary and Conclusion .................................................................................................. 60
7.1 Conclusions .................................................................................................................... 60
8. User Manual ....................................................................................................................... 61
8.1 Introduction .................................................................................................................... 61
8.2 Login Screen .................................................................................................................. 61
8.3 Signup Screen ................................................................................................................. 62
8.4 Main Screen.................................................................................................................... 63
8.5 Add Expenses ................................................................................................................. 64
8.6 Add Income .................................................................................................................... 65
8.7 Budget ............................................................................................................................ 66
8.8 Add Budget .................................................................................................................... 67
8.9 Account .......................................................................................................................... 68
8.10 Account ....................................................................................................................... 69
8.11 Add Expenses ............................................................................................................. 70
8.12 Add Account ............................................................................................................... 71
9. Lessons Learnt and Future Enhancements ....................................................................... 72
9.1 Limitations ..................................................................................................................... 72
9.2 Lessons Learnt................................................................................................................ 72
9.3 Future Enhancements ..................................................................................................... 72
9.4 BIBLIOGRAPHY .......................................................................................................... 73

UNIVERSITY OF LAHORE 10
 Budget Tracking

CHAPTER 1

1. Introduction

1.1 Project Overview

Budget Tracker offers a virtual platform to people and Business to adjust the budget of
daily routine. Budget tracker is a simple app for adjustment of daily routine expense and income.
Budget tracker provide a online access for every register person. Business can manage
their business expense and income through this application.
Budget Tracker is use for daily monthly and weekly expense. Tax is increase after one
year on everything.
1.2 Problem Statement
In Pakistan, there is no application offering to maintain budget tracking for every citizen.
People are facing problems because there is no proper way to manage their income and expense.
Tax expense will increase 10% after 1 year.
This application will adjust the following four things given below:
Manage Budget
Arrange Daily expense and income
Automatically Increase tax 10% after 1 year

UNIVERSITY OF LAHORE 11
 Budget Tracking

Every person can register

After registration use it service(Budget Tracking)
1.3 Why we use it?
Apply online anytime, anywhere.
No need to maintain data manually.
No location boundaries.
Time saving
Resource saving
Secured Privacy.

1.4 Groups
The actors of Budget Tracker are
1.4.1 Administration:
Administration is to approve, reject and cancel the user registration.
Admin maintain the proper functionality ofApp and troubleshoot the problem.
Admin also manage the working, operations, queries and feedback of the users.
1.4.2 User:
User can register him/herself simply filling an online registration form.
Each user has its own user name and password.
User have its brief portfolio.
Each user can maintain their budget plane.
User can save their data securely.
Administration has the rights to view user details.

1.5 Scope
Initially for our project we offer user to access online and create username and password
through registration panel. After registration user can access the application. Maintain their own
credentials.
1.6 Design Goals
We are providing all these features in this application:
1.6.1 Main App Pages:
Home
Expense Entry
Income Entry

UNIVERSITY OF LAHORE 12
 Budget Tracking

Accounts Add
Budget
Feedback
1.7 Goals
Our goal is to achieve No. 1 online portal covering all possible online person to keep
track of their budget along with their expenses and incomes.

UNIVERSITY OF LAHORE 13
 Budget Tracking

CHAPTER 2

2. Software Requirement Specification (SRS)

2.1 Introduction
There are currently running many applications that cover the whole information of
budget. Sometime user would not be able to find the complete information of that budget.

Through use of this app minimize the effort and time. By this app user can adjust their
desire budget in a short period of time. In this chapter we will cover

Existing solution
Purpose solution
Scope
Overall description
Supplementary Requirement Specifications

2.2 Existing Solution

There are many mobile apps that serve users to keep track of their budget and other
information that required during month period.

The Second solution is to make a budget on the paper in a traditional way.

But the problem with this solution is that they cannot be updated all the time, as well as it
also wastes the time of users.

UNIVERSITY OF LAHORE 14
 Budget Tracking

2.3 Proposed Solution

To solve this problem, there should be some interactive information screens, where user
can provide their required information. User can get the updated budget information on time.

Through this application user save a lot of time and money. For an administrator point of
view admin can easily maintain the record. Our application has the following advantages

User friendly interface

Fast access
Less error
Updated information
Complete information on just one click

2.4 Project Scope

2.4.1 Admin site

Basic profile registration

Maintain the record
Control over the whole application
Keep track about all the timetable
Delete the information

2.5 Overall description product

2.5.1 Product perspective

The budget tracking application is used by users to reduce the wastage of time and
money.
The budget tracking application is developed to the benefit of the common user.
Admin can keep track the information and update it.

UNIVERSITY OF LAHORE 15
 Budget Tracking

2.5.2 Product function

The budget tracking application provides the information about the budget which are
available in present time. Product function is likely same as describe in product prospective the
function of this Information System is to provide different type of services of for admin. The
admin is given a provision to check their account information and change it any time. The user
should be allowed to maintain their budget. The admin is provided an interface to edit, delete,
add, and update the information.

2.6 System analysis

System Analysis is depending on following:

Hardware specification
Software requirement
Network requirement

2.6.1 Hardware specification

Following specification are require for developing this application

Processor c2duo or higher

Ram 4 Gb or higher
Hard drive 40Gb
There would be some free memory which is used to perform some necessary
operation like internet service a Wi-Fi connection

2.6.2 Software Requirement

Following are the software requirement for the develop of this application

IDE: Android Studio

Front End: XML
Database: Firebase
Microsoft world
Operating system: Microsoft Windows

2.6.3 Network requirement

Internet connection is required.

UNIVERSITY OF LAHORE 16
 Budget Tracking

2.7 System Requirements

2.7.1 Functional Requirements

The system shall incorporate mechanism to authenticate its users.

The system shall verify and validate admin input and should notify in case of error
detection and should help the admin in error correction.
The system shall allow quick messages.
The system shall display all the setting that can be configured.
The system shall allow user to select the specific item to configure.
The system shall display all the available components of the budget to configure
The system shall enable admin to add one or more component to the configuration.
The system shall notify the admin about any conflict in the current configuration.
The system shall allow admin to update the configuration to resolve conflict in the
current configuration.
The system shall allow admin to confirm the completion of current configuration
The system shall allow the students to watch latest update in time table
2.7.2 Non-Functional Requirements.
Non-functional requirement are those requirements that specifies criteria that can be
used to judge the operation of a system or application, rather than specific behaviors.

2.7.2.1 User Friendly

The application interface is user friendly and should facilitate the user using the
application conveniently. The interface components should be self-evident.

2.7.2.2 Accessibility
The system is accessible easily on the android phone.

2.7.2.3 Backup
The system should not have a backup of each entry or transaction.

UNIVERSITY OF LAHORE 17
 Budget Tracking

2.7.2.4 Efficiency
It is the resource consumption for a given work load. Our system should be efficient.

2.7.2.5 Effectiveness
The Resulting performance in relation to effort should be better

2.7.2.6 Extensibility
The system should be extensible. Adding features and carry-forward of customizations at next
major version upgrade should be easy and convenient.

2.7.2.7 Interoperability

The system components should be interoperable.

2.7.2.8 Maintainability
Maintainability of the system should be simple.

2.7.2.9 Modifiability
The application should be easily changeable if required.

2.7.2.10 Quality
The quality of the system should be better.

2.7.2.11 Reliability

The system should be much reliable.

2.7.2.12 Security
The System must have a strong security to protect itself from any external threats and
fraud.

2.7.2.13 Cost Effective

The system should be cost effective and must not be too expensive

UNIVERSITY OF LAHORE 18
 Budget Tracking

2.8 Vision Document

Our vision is to become the standard online budget tracker application that provide very
effective virtual platform to every citizen and business, covering all possible expense and profit
system.
2.9 Supplementary Specification
2.9.1 Usability:
Budget Tracker is a user friendly application. All interfaces are quite user friendly.

2.9.2 Legal Requirement:

The user can register through this application and after that maintain their budget record.

2.9.3 Supportability:
Budget Tracker application is developed at android studio. The source code of Budget
Tracker is quite simple and easily readable with proper comments where needed.
2.10 Quality Assurance Plan
Software quality assurance is a pre-planned and systematic pattern of complete required
steps in order to achieve appropriate level of confidence that an item or whole product meet the
established
Technical and user requirements

Figure: Software Quality Assurance Plan

UNIVERSITY OF LAHORE 19
 Budget Tracking

2.10.1 Hardware and Software Specification

Internet is required to access the application online. For testing purpose it can run on
Emulator. A computer with normal specification is needed to run the website.
2.10.2 QA Planning
We build our application by using agile framework in order to occupy changes and
immediate output so we can test our program. Therefore quality of code and program is
maintained throughout the project.
2.10.3 Agile Development Model (Scrum)
We are going to use, Scrum software development methodology by dividing work in
iterations. After gathering requirements we made user stories which were prioritized in backlog.
We divide our whole project into four sprints.
In First Sprint, we developed database and index page. In second sprint doctor and admin
panel are created. In third sprint patient panel and static pages are developed. In forth sprint all
remaining tasks in backlog are covered.

Figure : Agile Life Cycle

UNIVERSITY OF LAHORE 20
 Budget Tracking

The above figure shows the life cycle of agile process. Project starts by defining
requirements by priority are taken in iterations. Development process and testing goes side by
side, when iterations completed the working software is delivered for feedback .When feedback
collected and reviewed, the product is released to market. In case of rejection, product is
reviewed again and in case of major issues, it is added to new iteration.

Our Sprint duration was 4 weeks. Sprint cycle started when we created prioritized sprint
backlog from product backlog. After completing design, development, documentation, and
testing phases there was sprint review meeting to decide unfinished item, either to skip or put
back them into product backlog. Every day, there was a daily stand up meeting to discuss
problems and progress. The following figure shows the sprint cycle.

Figure: Sprint Cycle

UNIVERSITY OF LAHORE 21
 Budget Tracking

2.11 Configuration Management Plan

Software configuration management (SCM or S/W CM) is used to track and control
changes in the software, part of the wider cross-disciplinary field of configuration
management. SCM process involves revision control and baselines establishment. In case of
trouble, SCM can describe what was changed and who changed it. If a configuration is working
well, SCM can regulate how to duplicate it through several hosts.

UNIVERSITY OF LAHORE 22
 Budget Tracking

UNIVERSITY OF LAHORE 23
 Budget Tracking

CHAPTER 3

3. Analysis

3.1 USE CASES

Use Cases are used for identification, clarification and organization of requirements of
system. It is set of possible orders of interactions among systems and users in a specific situation
and associated to a specific goal. It contains of a set of elements (for example, classes and
interfaces) that can be used together in a way that will have an outcome more than the
summation of the isolated elements joined. All system activities that have implication to the
users are included.

UNIVERSITY OF LAHORE 24
 Budget Tracking

3.2 Use-Case (Essential)

Figure 4: Roles of Actors in Android App

3.3 Use-Case Scenarios and Usage:

3.3.1 Table1: User Registration

Use Case Name Budget Tracker Registration

Use Case ID UC-1
Description This use case describes the process of user Register on the website.
Primary Actor All user
Trigger When user clicks on the Registration button.
User must be at the Registration page of the Android App.
Pre -Condition
The user must have not registered his/her name in the database.
When the user wishes to Register on the Android App.
Application demands the user to fill his/her Registration form.
The user inserts his/her Degrees and Documents.
The application verifies the inserted data and after
Main Course confirmation user will be registered.
The application demands the name and password of the user.
The name and password of the user are inserted
The application verifies the user, surname& password and
logins the user into user panel.
If the registration form is not validate the system return message of
Alternate Course error.
Or perhaps cancel the registration where the use case draws to a close.
If the use case was successful register the user and can login into the
Post-Condition
Android App.
Exception The application returns error if invalid entries are inserted.

UNIVERSITY OF LAHORE 25
 Budget Tracking

3.3.2 Table2: Budget Tracking Setting

Use-Case Name User Schedule

Use Case ID UC -2
Description This Use-Case describes how user schedules his/her expense.
Primary Actor All users
Trigger When user clicks on his/her details.
Pre Condition User must be at their profile of the app.
The user must have login.
Main Course The Case begin as the user starts to budget table on app.
User set expense.
User set income
Accounts
Budgets

Alternative Course If the actor is not login the system returns to login page.
Post-Condition After set the schedule actor saves or update his/her schedule.
Exception The app returns error if invalid entries are inserted.

UNIVERSITY OF LAHORE 26
 Budget Tracking

3.3.3 Table3: Budget Tracker Online Check-up

Use-Case Name Budget Tracking online

Use-Case ID Use-Case -3
Description This Use-Case describes online access in budget tracking app.
Primary Actor All users
Trigger When User clicks on the online access button.
User must have his/her login Id.
Pre -Condition User must have internet access
Each user has their own id and data list.
The Case begin as the user wants to start online check-up on the
app.
User must register

Main Course User login its own Id.

User make online access in app.
User check his detail.
User can update data.
Alternative Course If user is not login then user return on login page.
If the online check-up successfully done, user punch Checked
Post-Condition
status.
Exception The app give error if user is not login.

UNIVERSITY OF LAHORE 27
 Budget Tracking

3.3.4 Table4: User Registration

Use Case Name Registration

Use Case ID UC-4
Description This use case depict the procedure of user Registration on the app.
Primary Actor All Users
Trigger When user clicks on the Registration button.
User must be at the Registration page of the app.
Pre -Condition
The user must have not registered his/her name in the database.
Use case begins as the user tries to Register on the app.
The application demands that the user fills registration form.
The application verifies the inserted data and after confirmation
user will be registered.

Main Course The application demands that the user inserts his/her name and
password.
The name and password are inserted by the user.
The application verifies the inserted name and password and
the user get login into the system.
User can update his/her profile.
If the registration form is not validate the system return error message.
Alternative Course The user can pick to either go back to the error message
Or end the case by canceling the registration.
Post-Condition The user can login into the app in case of successful registration.
Exception The app returns error if invalid entries are inserted.

UNIVERSITY OF LAHORE 28
 Budget Tracking

3.3.5 Table5: Set Budget

Use-Case Name Setting Budget Online

Use-Case ID Use-Case -6
Description This Use-Case describes online check-up on the website.
Primary Actor All Users
Trigger When User clicks on the Add income button.
Patient must have his/her LOG IN.
Pre -Condition
Must have verified Email.

It should add the income

Types of income and expenses

Main Course Balance as per year

Source

Per month/year

Amount
If the registration form is not validate the system return error
Alternative Course message. The user can pick to either go back to the error message
Or end the case by canceling the registration.
Post-Condition User should have logged into the application.
Exception The app returns error if invalid entries are inserted.

UNIVERSITY OF LAHORE 29
 Budget Tracking

3.3.6 Table6: User Registration Approval

Use-Case Name User Account Verification

Use-Case ID Use-Case -7
This Use-Case describes the approval of user registration form on the
Description
app.
Primary Actor Administrator
Trigger When user clicks on save button after registration.
The user must have submitted his/her registration form.
Pre -Condition User must have rights to approve or reject.
User must be login on website.
The Case begin as the admin verify the registration form.
User gets registration form from app.
Admin verifies all the data inserted by User.
Main Course
Admin verifies all the documents inserted by user.
Admin verifies all the degrees inserted by user.
Admin can approve, pending or reject the account.

Alternative Course Admin can approve, pending or reject the account.

Post-Condition After approval of account user access the app.
Exception The app returns error if admin not login on Android app.

UNIVERSITY OF LAHORE 30
 Budget Tracking

3.3.7 Table8: Static Page Handling

Use-Case Name Static Page Handling

Use-Case ID UC -8
Description This Use-Case describes the static data on the app.
Primary Actor Administrator
Trigger When admin wants to update the app.
Pre -Condition Admin must be login on app.
The Case begin as the admin wishes to update website.
Admin may add features.
Main Course
Admin may add, delete or modify data on app.
Admin may add social links like Facebook, Twitter etc.
Alternative Course Admin can add, delete and modify data on app.
Post-Condition After data management admin update app.
Exception The application returns error if admin not login on app.

UNIVERSITY OF LAHORE 31
 Budget Tracking

3.4 Use-Cases (Elaborated)

(i) User Panel

Figure5: User and Admin Panel

UNIVERSITY OF LAHORE 32
 Budget Tracking

3.4.1 Table10: Budget Tracking (Elaborated)

Use-Case Name Budget Tracking Manage

Use-Case ID UC -2
Description This Use-Case describes how to manage the budget.
Primary Actor All User
Trigger When user clicks on his/her details.
User must be at their profile of the app.
Pre -Condition
The user must have login.
The Case begin as the user tries to manage his/her data:
User adjust income.
Main Course
User adjust expense.
User adjust budget.

Alternative Course If the user is not login the system returns to login page.
Post-Condition After set the username and password user login.
Exception The app returns error if invalid entries are inserted.

UNIVERSITY OF LAHORE 33
 Budget Tracking

Administrator Panel

Figure7: Administrator Panel

UNIVERSITY OF LAHORE 34
 Budget Tracking

3.4.2 Table15: User Account Verification

Use-Case Name User Account Verification

Use-Case ID Use-Case -7
This Use-Case describes the approval of user registration form on the
Description
app.
Primary Actor Administrator
Trigger When user clicks on save button after registration.
The user must have submitted his/her registration form.
Pre Condition Admin must have rights to approve or reject.
Admin must be login on app.
The Case begin as the admin verify the registration form.
Admin gets registration form application.
Admin verifies all the data inserted by user.
Main Course
Admin verifies all the documents inserted by user.
Admin verifies all the budget plane.
Admin can approve, detail of user.

Alternative Course Admin can approve, pending or reject the account.

Post-Condition After approval user can login this application
Exception The application returns error if admin not login on app.

UNIVERSITY OF LAHORE 35
 Budget Tracking

CHAPTER 4

4. Design

In Software Design we build all the artifacts required in conceptualizing, framing,

applying, assigning, and finally revising complex systems following our requirements
specification before programming.
We build database design(ER-Diagram & RDM), Domain Model, Operation Contracts,
System Sequence Diagram, Class Diagram, component Diagram and Deployments Diagram of
our project.

4.1 Database Design

In Database Design first we identify the flow of data in our website. After this we build
entity relationship diagram and Relational data model in order to make Database Tables,
attributes, their primary keys and foreign keys.

UNIVERSITY OF LAHORE 36
 Budget Tracking

4.2 Entity Relationship Diagram

Figure 8: Entity Relationship Diagram

UNIVERSITY OF LAHORE 37
 Budget Tracking

4.3 Domain Model

Domain Modeling is the process of describing the model real world entities and their
relationships, which as a whole explain the problem domain space

Figure 10: Domain Model

UNIVERSITY OF LAHORE 38
 Budget Tracking

4.4 Operation Contracts

UML Operation contract represent the changes in system when an operation occurs. It
will describe the nature of operation. An operation contract can be generated from system
sequence diagram. This is the solo event from that diagram. A domain model can also be utilized
for generating an operation contract

Contract User Login

Cross Reference Use-Case (1)
Pre-Condition User must be at the Registration page of the app.
The user must have not registered his/her name in the database.
Post-Condition If the Use-Case was successfully registered then actor can login into
the app.

Contract Admin Login

Cross Reference Use-Case (1)
Pre-Condition Admin must be at the login name and password.
The admin username and password save in database.
Post-Condition If the Use-Case was enter detail.

Contract Budget Tracker

Cross Reference Use-Case (5)
Pre-Condition User must be login on app.
User must have profile on app
Post-Condition User can check detail.
Access through username and password.

UNIVERSITY OF LAHORE 39
 Budget Tracking

Contract Income detail

Cross Reference Use-Case (3)
Pre-Condition User must be access online income detail.
User must have maintain detail.
Post-Condition Online access will only for register users.

4.5 System Sequence Diagram

In software engineering, a diagram that shows the specific condition of a use case,
generation of events by external actor, order of them, and possible event outcomes.

4.5.1 Sequence Diagram (User Login)

Figure 11: Sequence Diagram (User Login)

UNIVERSITY OF LAHORE 40
 Budget Tracking

4.5.2 Sequence Diagram (User)

Figure 12: Sequence Diagram (User)

4.6 Collaboration Diagram

Collaboration diagrams are used to show how objects interact to perform the behavior of
a particular use case, or a part of a use case. Along with sequence diagrams, collaborations are
used by designers to define and clarify the roles of the objects that perform a particular flow of
events of a use case. They are the primary source of information used to determining class
responsibilities and interfaces.

UNIVERSITY OF LAHORE 41
 Budget Tracking

4.6.1 Collaboration Diagram (Set budget)

Figure 4: Collaboration Diagram (Set budget)

4.6.2 Collaboration Diagram (User Registration)

Figure 5: Collaboration Diagram (User Registration)

UNIVERSITY OF LAHORE 42
 Budget Tracking

4.6.3 Collaboration Diagram (Admin Panel)

Figure 6: Collaboration Diagram (Admin Panel)

4.7 Class Diagram

The nature class diagram is a static. It demonstrate the static view of an application. The
class diagram depict the numbers of classes, associations, interfaces, constraints and
collaborations. It is also named as structural diagram.

UNIVERSITY OF LAHORE 43
 Budget Tracking

UNIVERSITY OF LAHORE 44
 Budget Tracking

4.8 Component Diagram

It shows the static aspect of a system implementation. Static implementation displays the
association of the components at a particular point.

Figure 15: Component Diagram

4.9 Deployment Diagram

It elaborate the association of hardware components with software components, deployed
in the system. Component diagrams and deployment diagrams are slightly different.

UNIVERSITY OF LAHORE 45
 Budget Tracking

Figure 16: Deployment Diagram

UNIVERSITY OF LAHORE 46
 Budget Tracking

4.10 Architectural Design

Figure 17: Architectural Diagram

4.11 Activity Diagram

Activity diagrams, which are related to program flow plans (flowcharts), are used to
illustrate activities. In the external view, we use activity diagrams for the description of those
business processes that describe the functionality of the business system.

UNIVERSITY OF LAHORE 47
 Budget Tracking

4.11.1 Activity Diagram (Admin)

Figure 18: Activity Diagram (Admin)

UNIVERSITY OF LAHORE 48
 Budget Tracking

4.11.2 Activity Diagram (User)

Figure 19: Activity Diagram (User)

UNIVERSITY OF LAHORE 49
 Budget Tracking

4.12 Data Flow Diagram

Figure 20: Data Flow Diagram

UNIVERSITY OF LAHORE 50
 Budget Tracking

CHAPTER 5

5. Testing [SQA Introduction and Test Cases]

5.1 Testing
Application testing is a very important part of all implementation projects evaluation.
Before sharing an application and making it available for wide audience it is necessary to test it
in case for errors, unusual situations and different users behaviors.
5.2 Black Box Testing
It views the software as a black box with inputs and outputs, but they have no
knowledge of how the system or component is structured inside the box. Black
box testing techniques for sub-divisions for our application are implemented
below.
5.2.1 Equivalence partitioning
It is to divide the input data of software into partitions of data from which test
cases can be derived. In principle, test cases are derived to cover each partition at
least ones. This technique tries to define test cases thereby reducing the total
number of test cases that must be developed.
5.2.2 Methodology Adopted for EP
In this method, the input domain data is divided into different equivalence data
classes.

This method is typically used to reduce number of test cases.

In short, it is the process of taking all possible test cases and placing them into
classes. One test values picked from each class while testing.

UNIVERSITY OF LAHORE 51
 Budget Tracking

5.3 Test case for Budget Tracking

5.3.1 Test case for Signup

Test Case Id TC-1-1

Description Take the user to signup mode of the
application
Purpose User able to sign up from level one
Precondition Budget Tracking is Install and running
Input Criteria Take input from the user
Expected Result User can write his Email and password

5.3.2 Test case for Login

Test Case Id TC-1-2

Description Take the user to main menu mode of the
application
Purpose User able to Login from level one
Precondition Budget Tracking is Install and running
Input Criteria Take input from the user
Expected Result User can write his Email and password

5.3.3 Test case for My Budget

Test Case Id TC-1-3

Description The user watch the budget
Purpose User able to find and select the desire
setting
Precondition User Should be login
Input Criteria Take input from the user
Expected Result User can change watch the budget

UNIVERSITY OF LAHORE 52
 Budget Tracking

5.3.4 Test case for Add Expenses

Test Case Id TC-1-4

Description The user add the expenses
Purpose To add the monthly expenses
Precondition User must have Login
Input Criteria Take input from user
Expected Result User add the expenses

5.3.5 Test case for Add Income

Test Case Id TC-1-5

Description The user add the income
Purpose To add the income
Precondition User must have Login
Input Criteria Take input from the user
Expected Result User add the income

5.3.6 Test case for Add Budget

Test Case Id TC-1-6

Description The user add the budget
Purpose To add the budget
Precondition User must have Login
Input Criteria Take input from the user
Expected Result User add the budget

UNIVERSITY OF LAHORE 53
 Budget Tracking

5.3.7 Test case for Display Budget

Test Case Id TC-1-7

Description The user set to display the budget
Purpose Display the budget
Precondition User must have Login
Input Criteria Take input from the user
Expected Result Display the budget

5.3.8 Test case for Add Account

Test Case Id TC-1-8

Description The user can add the account
Purpose User wants to add account
Precondition User must have Login
Input Criteria Take input from the user
Expected Result Account will be added

5.4 White Box Testing

The test approach that takes an internal view of software is called a White-box
testing. White-box testing sometimes called glass-box testing. White-box testing
is a test case design method that uses the control structure of procedural design
to derive test cases.
It is actually applied to know the internal workings of product. Tests are
conducted to ensure that all gears mesh that internal operations perform
according to the specification and all internal components are adequately
exercised. I will conduct white-box testing with the perspective of cyclomatic
complexity.

5.5 Cyclomatic Complexity

Cyclomatic Complexity is software metric that provides a quantitative measure of
the logical complexity of a program. When used in the context of the basis path
testing method, the value computed for cyclomatic complexity defines the
number of independent paths in the basis set of a program and provides you with
an upper bound for the number of tests that must be conducted to ensure that all

UNIVERSITY OF LAHORE 54
 Budget Tracking

statements have been executed at least once. General rules to find Complexity
are given below:

The number of regions of the flow graph corresponds to the cyclomatic

complexity.
Cyclomatic Complexity V(G) = Number of flow graph edges (E) Number of
flow graph s (N) + 2
Cyclomatic Complexity V (G) = Number of predicate s (P) + 1

5.6 Regression Testing

Each time a new module is added as part of integration testing, the software
changes. New data flow paths are established, new I/O may occur, that previously
worked flawlessly. In the context of an integration test strategy, Regression
testing is the re execution of some subset of tests that have already been
conducted to ensure that changes have not propagated unintended side effects.
In a broader context, successful tests result in the discovery of errors and errors
must be corrected. Whenever software is corrected, some aspect of the software
configuration (the program, its documentation, or the data that support it) is
changed Regression testing helps to ensure that changes (due to testing or for other reasons) do not
introduce unintended behavior or additional errors.

UNIVERSITY OF LAHORE 55
 Budget Tracking

5.7 System Testing

System testing is actually a series of different tests whose primary purpose is to
fully exercise the computer-based system. Although each test has a different
purpose, all work to verify that system elements have been properly integrated
and perform allocated functions. Below are given two of them:

Stress Testing

Performance Testing

5.8 Stress Testing

Stress testing is the process of determining the ability of a computer program to
maintain a certain level of effectiveness under unfavorable conditions. It involves
testing beyond normal operational capacity, often to a breaking point, in order to
observe the results. Reasons can include:

To determine breaking points or safe usage limits

To confirm intended specifications are being met

To determine modes of failure (how exactly a system fails)

To test stable operation of a part or system outside standard usage

The tester who performs stress testing asks: How high can we crank this up
before it fails?

5.9 Performance Testing

Performance testing is designed to test the run-time performance of software
within the context of an integrated system. Performance testing occurs
throughout all steps in the testing process. Even at the unit level, the
performance of an individual module may be assessed as tests are conducted.
Performance testing also occurs after all system elements (components) are
integrated. Performance tests are often coupled with stress testing and usually
require both hardware and software instrumentation. By incrementing a system,
the tester can uncover situations that lead to degradation and possible system

UNIVERSITY OF LAHORE 56
 Budget Tracking

failure.The real performance can only be tested on real environment. So, I test and verify
this application on a physical real device Samsung Galaxy S6. And its
performance was accurate.

UNIVERSITY OF LAHORE 57
 Budget Tracking

CHAPTER 6

6. Tools and Techniques

6.1 Tools and technique

Description of technology used in project.
6.1.1 Language used
XML is a file extension for an Extensible Markup Language (XML) file format used to
create common information formats and share both the format and the data on the World Wide
Web, intranets, and elsewhere using standard ASCII text. XML is similar to HTML
X ML Main features include:
Gradients

Web fonts

Media Queries

Box sizing

Border images

Multiple backgrounds

CSS columns

CSS 3D transforms

Many Advanced Selectors

6.2 Android Development

Android-based smart phones are in vogue due to the flexibility they offer for
customization. The Android application development kit is an open-source Linux-based
operation system, which has its own middleware and key applications. The platform for app
development in Android is Java. This means that you use the Java library and code the
applications in Java, C, and C++ programming language.
Android provides several options for you to save persistent application data. The solution
you choose depends on your specific needs, such as whether the data should be private to your
application or accessible to other applications (and the user) and how much space your data
requires.

UNIVERSITY OF LAHORE 58
 Budget Tracking

Android provides a way for you to expose even your private data to other applications
with a content provider. A content provider is an optional component that exposes read/write
access to your application data, subject to whatever restrictions you want to impose.
6.3 Using Shared Preferences
The Shared Preferences class provides a general framework that allows you to save and
retrieve persistent key-value pairs of primitive data types. You can use Shared Preferences to
save any primitive data: Booleans, floats, ints, longs, and strings. This data will persist across
user sessions (even if your application is killed).
6.3.1 User Preferences
Shared preferences are not strictly for saving "user preferences," such as what ringtone a
user has chosen. If you're interested in creating user preferences for your application, see
Preference Activity, which provides an Activity framework for you to create user preferences,
which will be automatically persisted (using shared preferences).
6.3.2 Using the Internal Storage
We can save files directly on the device's internal storage. By default, files saved to the
internal storage are private to your application and other applications cannot access them (nor
can the user). When the user uninstalls your application, these files are removed.
6.3.3 Saving cache files
We save our user data into cache some data, rather than store it persistently, when the
device is low on internal storage space, Android may delete these cache files to recover space.
However, you should not rely on the system to clean up these files for you. You should always
maintain the cache files yourself and stay within a reasonable limit of space consumed, such as
1MB. When the user uninstalls your application, these files are removed.

UNIVERSITY OF LAHORE 59
 Budget Tracking

CHAPTER 7

7. Summary and Conclusion

7.1 Conclusions
"If one advances confidently in the direction of his dreams, and endeavors to live the life
which he has imagined, he will meet with a success unexpected in common hours".

The main purpose of this is to make an information system to become a means to save
precious time. I developed structured, efficient and effectiveness Budget Tracking Application.
Through this application students may be able to adjust their budget. User would not need to
remember their expenses and income statements.

Personally, I am proud on my work. During development of this project I learned the

basics of the Android Studio platform architecture and implementation acquainted myself with
Mobile Application architecture and generally with the basics of Java programming. All these
elements were unknown to us before beginning of the final project.

Further Development
Due to its universal architecture the system presented in the project can be further
developed and extended with a number of functionalities.

UNIVERSITY OF LAHORE 60
 Budget Tracking

CHAPTER 8

8. User Manual

8.1 Introduction
This document is the guideline for Budget Tracking, so that user can use application in
more useful, easy and efficient way. This manual provides help to users for using this application
without any dissonance; moreover it facilitates users with the description of almost all main
features of application.

Each main function that can be performed through this application is explained with the
help of screenshots and their brief description.

8.2 Login Screen

Login: user can login by entering authorized email and password. This is a login model.

UNIVERSITY OF LAHORE 61
 Budget Tracking

8.3 Signup Screen

Signup: user can register to Budget Tracking from here

UNIVERSITY OF LAHORE 62
 Budget Tracking

8.4 Main Screen

Home Screen: After login user see main page where user can view their budget.

UNIVERSITY OF LAHORE 63
 Budget Tracking

8.5 Add Expenses

Add Expenses: user can add expenses:, here user can select category, sub category and
account details

UNIVERSITY OF LAHORE 64
 Budget Tracking

8.6 Add Income

Add Income: user can add income:, here user can select amount , description and account
details

UNIVERSITY OF LAHORE 65
 Budget Tracking

8.7 Budget
Budget: user can view budget.

UNIVERSITY OF LAHORE 66
 Budget Tracking

8.8 Add Budget

Add budget: user can add budget:, here user can add home rent, mortgage etc.

UNIVERSITY OF LAHORE 67
 Budget Tracking

8.9 Account
Here user can view the accounts.

UNIVERSITY OF LAHORE 68
 Budget Tracking

8.10 Account
Here user can add the new accounts.

UNIVERSITY OF LAHORE 69
 Budget Tracking

8.11 Add Expenses

Here user can add the expenses on daily bases.

UNIVERSITY OF LAHORE 70
 Budget Tracking

8.12 Add Account

Here user can add new accounts.

UNIVERSITY OF LAHORE 71
 Budget Tracking

CHAPTER 9

9. Lessons Learnt and Future Enhancements

9.1 Limitations
Budget Tracking is a mobile Application and it is restricted to different type of users. In
this application, only valid user have been given access rights and they are restricted up to their
functionalities, so that the data is maintained securely and redundant data is prevented.

9.2 Lessons Learnt

This project has been very excellent learning source for us. It had been a great journey
from the start of the project. As it was just like an R&D (Research and Development) project for
us because I had to learn all the technologies that I have used in this project and then develop the
System.
We followed different blogs for learning and issues. From the beginning this project has
been adding great things in our knowledge. We learnt different applications and languages which
are now very demanding in Software market. Before entering into professional life this project
showed me a way to enhance our communication skills, behavior and focus toward the goal. This
would be really very helpful in our future working environment.

9.3 Future Enhancements

Every Edition of a book comes with new topics and modifications if any errors are
present. In the similar way, in near future, our application will overcome the flaws if occurred,
and attains new features offered to employees for the Flexible and easy Information. After years
of steady consolidation in the Mobile market, the field of potential providers is once again
widening. This evolution toward a broader and more comprehensive user experience of mobile
development, the continuing development of mobile services. There can be many future
enhancements in this project. But these enhancements depend on the requirements. The layout of
the pages can also be updated to give it a very nice and fresh look because the look for now is a
little bit flat. There is always room for improvement also in the project scope as well.

UNIVERSITY OF LAHORE 72
 Budget Tracking

9.4 BIBLIOGRAPHY

FOR DEFINITION:

https://www.wikipedia.com

FOR ANDROID STUDIO

https://developer.android.com/

UNIVERSITY OF LAHORE 73