AMRITSAR GROUP OF COLLEGES

Autonomous Status Conferred by UGC | NAAC – A Grade Project Report

On

E-Voting App
Submitted in the partial fulfilment of the requirement for the award of a degree of

Bachelor of Technology

In

COMPUTER SCIENCE AND ENGINEERING

Batch (2023-2027)

Submitted to: Submitted by:

Er. Karan Mahajan Vansh Khosla(2334251)

Vasu Tuli(2333455)
Tanisha(2333446)
Taranpreet Kaur(2333448)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

 DECLARATION

We hereby declare that the project work entitled “E-Voting App” is an authentic record
of our own work carried out in partial fulfilment of the requirements for the award of the
degree of Bachelor of Technology in Computer Science and Engineering from
Amritsar Group of Colleges, Amritsar.

We further declare that this project has not been submitted to any other University or
Institution for the award of any degree or diploma.
.
Vansh Khosla(2334251)
Vasu Tuli(2333455)
Tanisha(2333446)
Taranpreet Kaur(2333448)
 ACKNOWLEDGEMENT
We extend our sincere thanks to Dr. Sandeep Kad, Head of the Department, and all
faculty members of the Computer Science & Engineering Department, Amritsar
Group of Colleges, for their cooperation and support.

This project, "UnitConverter," has helped us gain valuable insights into Java
programming, software design principles, and application development. The
practical experience we have acquired will be immensely helpful in our future endeavors.
 TABLE OF CONTENTS

S. No. Title Page No.

1. Introduction to Project 1
2. Project Requirements 3
3. Technology Used 6
4. Feasibility Study 7
5. System Requirement Specification 8
6. System Development Lifecycle 10
7. Algorithm and Flowchart 13
8. Implementation 17
9. Snapshots 18
10. Result and Discussion 21
11. Testing and Maintenance 23
12. Advantage and Limitations 24
13. Future Scope 25
14. Conclusion 26
15. Bibliography 27
 INTRODUCTION TO PROJECT

In our increasingly digital world, traditional paper-based voting processes can be slow,
resource-intensive, and susceptible to human error in vote tabulation. Managing physical
voter rolls and manually counting ballots is not only tedious but can also lead to delays
and potential inaccuracies, undermining confidence in the results.

To overcome this challenge, the "E-Voting System" project was developed. It is an

efficient, secure, and user-friendly desktop application built using Java, designed to
automate and simplify the entire election process, from voter authentication to results
tabulation.

The E-Voting System is a Java-based software system that provides a clean graphical user
interface (GUI) for secure vote casting. It is built on the principles of Object-Oriented
Programming (OOP) to manage the application logic, Java Swing for the user-facing
components, and a SQLite database to securely persist all voter and candidate data.

The system works interactively: a voter first approaches the LoginFrame and enters their
unique Voter ID. The system validates this ID against the database, checking if the ID is
valid and if that person has already voted. If valid, the VotingFrame is displayed, allowing
the user to select one candidate. Upon confirmation, the system securely records the vote
in the database, atomically updating both the candidate's vote count and the voter's status.
The application features:

• Secure voter authentication against a database.

• Prevention of double-voting by tracking voter status.

• Real-time, aggregated results displayed in a separate, refreshable window.

• Error handling for invalid inputs (e.g., non-existent ID, already-voted status).

Thus, the project serves as a practical, stand-alone utility that demonstrates core Java
development, GUI design, and database management principles while solving a common,
real-world problem.

Theoretical Significance

1. Object-Oriented Programming (OOP): The project is a practical application of core

OOP concepts. It uses classes to represent different logical components (e.g.,
LoginFrame, VotingFrame, DatabaseHelper), and encapsulation to hide all complex
database queries and connection logic entirely within the DatabaseHelper class,
separating it from the user interface.

2. GUI and Event Handling: The project showcases the fundamentals of building an
interactive GUI in Java Swing. It involves managing UI components (like JFrame,
JButton, JTextField, JRadioButton, and JTable) and handling user-generated events
1
 (like button clicks) using ActionListeners to trigger application logic.

3. Database Management (JDBC): A critical part of the software, this project

implements logic to connect to an SQLite database using the Java Database
Connectivity (JDBC) API. It uses PreparedStatement to safely execute parameterized
SQL queries (preventing SQL injection), processes data using ResultSet, and manages
database-specific errors using try-catch blocks for SQLException.

4. Software Design Principles: The project emphasizes a clean separation of concerns.

The user interface logic (the "View," contained in the ...Frame classes) is kept
completely separate from the business logic and data access layer (the "Model,"
represented by the DatabaseHelper class). This is a foundational principle for building
applications that are maintainable, scalable, and easy to debug.

5. Data Structures & Transactions: The project demonstrates the practical use of data
structures and critical database concepts.

o A Map (HashMap) is used to efficiently retrieve and pass the election results
from the database to the ResultsFrame.

o An Enum (VoterStatus) is used to represent the distinct states of a voter in a

clean, type-safe manner.

o Crucially, it implements atomic transactions (setAutoCommit(false),

commit(), rollback()) in the castVote method to ensure that updating the voter's
status and incrementing the candidate's vote count either both succeed or both
fail together, guaranteeing data integrity.

Practical Applications

1. Academic and Educational Tool: Assists computer science students in learning Java
Swing, JDBC database integration, and event-driven programming. It serves as an
excellent case study for small-scale college or university elections (e.g., for student
government or clubs).

2. Organizational Utility: Provides a quick and reliable desktop tool for small to
medium-sized organizations, associations, or corporate departments to conduct
internal polls, elect board members, or vote on resolutions securely and efficiently.

3. Community Polling: Useful for any small community group, such as a homeowner's
association or a local club, that needs a simple, free, and auditable system for making
collective decisions or electing leadership.

4. Software Foundation: The core logic of this project can be expanded or integrated
into more complex software. The architecture allows it to be refactored into a client-
server application to support networked voting from multiple machines or to be
adapted into a web-based application.

2
 PROJECT REQUIREMENTS

To develop the E-Voting System effectively, all requirements are divided into Functional,
Non-Functional, and User Requirements.

Functional Requirements
1. The system must accurately validate a user's Voter ID against the database.
2. The system must check a voter's status and prevent any user who has already voted
from logging in to vote a second time (VoterStatus.ALREADY_VOTED).
3. The system must provide a Graphical User Interface (GUI) for the user to input their
Voter ID (LoginFrame).
4. Once validated, the user must be able to select one candidate from a pre-defined list
(e.g., JRadioButton in VotingFrame).
5. The system must ask the user for final confirmation before casting their vote
([Link]).
6. The vote-casting process must be atomic, ensuring that the candidate's vote count is
incremented and the voter's hasVoted status is updated simultaneously in the database.
7. The system must handle invalid user inputs gracefully (e.g., an empty, non-existent,
or already-voted ID) by displaying an appropriate error message
([Link]) without crashing.
8. The system must provide a separate "View Results" window (ResultsFrame) that
displays the current vote count for all candidates.
9. The results display must be sorted in descending order of votes.
10. The "Results" window must include a "Refresh" button to fetch the latest vote counts
from the database.

Non-Functional Requirements
1. Performance: All database queries (voter validation, vote casting, and results
fetching) must be processed and displayed with no noticeable lag or delay for the user.
2. Data Integrity: All votes must be accurately recorded. The database transaction for
casting a vote must be atomic (using commit and rollback) to ensure that a vote is
never partially recorded, even if an error occurs.
3. Reliability: The application must be stable and robust, handling all standard
operations and potential database connection errors or user input errors without
crashing.
4. Usability: The user interface must be simple, intuitive, and self-explanatory,
allowing a first-time user to log in and cast their vote easily without instructions.
5. Portability: As a Java application, the project must run correctly on any major
operating system (Windows, macOS, Linux) that has a compatible Java Runtime
Environment (JRE) installed.
6. Maintainability: The Java code should be modular and adhere to Object-Oriented
Programming (OOP) principles, specifically separating the UI logic (e.g.,
LoginFrame, VotingFrame) from the database logic (e.g., DatabaseHelper), to be
3
 easily debugged or extended in the future.
7. Security: The system must ensure that only users with a valid, pre-registered Voter
ID can access the voting ballot. It must be impossible for a single Voter ID to be used
more than once.

User Requirements
1. Users must have the Java Runtime Environment (JRE) (version 8 or newer)
installed on their system to run the packaged application (.jar file).
2. The user should be able to launch the application easily (e.g., by double-clicking the
.jar file).
3. No internet connection is required, as the application is a stand-alone desktop utility
that uses a local SQLite database file (voting_database.db).
4. No prior technical knowledge is required; users simply need to know their assigned
Voter ID to participate.

4
 TECHNOLOGIES USED

Programming Language

• Java (JDK 8 or newer) Chosen for its "Write Once, Run Anywhere" (WORA)
platform independence, allowing the application to run on any system with a Java
Runtime Environment (JRE). Its strong Object-Oriented Programming (OOP)
foundation is ideal for building a modular and maintainable application, and it
provides mature, built-in libraries for GUI development and database connectivity.

Libraries and Modules

1. Java Swing ([Link] package)

o This is the primary GUI toolkit used for the project. It provides a rich set of
lightweight, platform-independent components.

o It is used to build the entire visual interface, including the application windows
(JFrame), text fields for input (JTextField), buttons for actions (JButton),
candidate selection lists (JRadioButton with ButtonGroup), and the results
display table (JTable with DefaultTableModel). It is also used for all user
feedback dialogs (JOptionPane).

2. Java AWT ([Link] and [Link] packages)

o This is the foundational toolkit upon which Swing is built. While Swing
provides the components, AWT provides the core event-handling model and
layout managers.

o It is used to make the application interactive, primarily by implementing

ActionListener interfaces to detect user button clicks. It also provides the
layout managers used to organize the GUI, such as BorderLayout, GridLayout,
and FlowLayout.

3. Java SQL ([Link] package) & JDBC

o This is the Java Database Connectivity (JDBC) API, which provides the core
classes for database interaction.

o It is used to create a Connection to the database, build Statement and

PreparedStatement objects to execute SQL queries safely (preventing SQL
injection), and process query results using a ResultSet. It also provides the
SQLException class for robust error handling.

4. SQLite-JDBC Driver

o This is a third-party, external library (typically a .jar file) that implements the

5
 Java SQL interfaces specifically for the SQLite database engine.

o It acts as the "driver" or "bridge" that allows the generic [Link] code to
communicate directly with the local voting_database.db file.

o
Core Logic and Design

• Object-Oriented Programming (OOP) The project employs OOP principles to

ensure a clean and scalable design. A key strategy is the separation of concerns:

o View (GUI): The LoginFrame, VotingFrame, and ResultsFrame classes are

responsible only for displaying the interface and capturing user input. They contain
no database logic.

o Model (Logic): The DatabaseHelper class encapsulates all database logic. It handles
all SQL queries, connection management, and data processing. The view classes
simply call high-level methods like [Link]() or [Link](),
making the code easy to debug and maintain.

• Event-Driven Programming This is the fundamental paradigm of the application.

The program does not run in a linear sequence. Instead, it initializes the GUI
(LoginFrame) and then enters a waiting state. Code is only executed in response to
user-initiated events (e.g., clicking the "Login" or "Cast Vote" button), which creates
a responsive and interactive user experience.

• Database Transaction Management A critical piece of the core logic. To ensure data
integrity, the castVote method uses atomic transactions. It disables autoCommit,
executes two separate UPDATE commands (one for the voters table, one for the
candidates table), and then calls commit() to finalize them as a single, indivisible
operation. If either update fails, the entire transaction is rollback()'d, preventing data
corruption (e.g., a user being marked as "voted" without their vote being counted).

6
 FEASIBILITY STUDY

The feasibility study evaluates whether the project is technically, operationally, and
economically possible to implement.

1. Technical Feasibility
• The project uses Java, which provides all necessary built-in libraries like Java Swing
for the GUI and JDBC (Java Database Connectivity).
• The SQLite-JDBC driver is open-source, well-documented, and easy to integrate for
database operations.
• The SQLite database is serverless and file-based, requiring no complex database
server setup.
• No advanced hardware or complex cloud infrastructure is required.
• The system can run on any standard computer with a Java Runtime Environment
(JRE) installed.
• Hence, the project is highly technically feasible.

2. Operational Feasibility
• The program has a simple and intuitive Graphical User Interface (GUI), so even
users with minimal computer knowledge can operate it easily.
• It provides immediate, clear feedback to the user (e.g., "Invalid Voter ID," "Vote Cast
Successfully," "Already Voted") via pop-up dialogs.
• The project's modular design (separating the DatabaseHelper from the UI) allows it to
be expanded into a networked client-server or web-based application in the future.
• Therefore, the project is operationally feasible and user-friendly.

3. Economic Feasibility
• The Java Development Kit (JDK), Java Swing, and the SQLite database engine are
all completely free and open-source.
• The SQLite-JDBC driver is also open-source, requiring no license fees.
• The system can be deployed on personal computers without any extra hardware,
server, or hosting costs.
• Maintenance is minimal and only requires managing the local voting_database.db file
and the application code.

7
 SYSTEM REQUIREMENT SPECIFICATION (SRS)

Here is the "System Requirement Specification (SRS)" adapted for your E-Voting
System project.

SYSTEM REQUIREMENT SPECIFICATION (SRS)

The System Requirement Specification (SRS) outlines the complete prerequisites—

hardware, software, and user-related—that are essential for the smooth development,
deployment, and execution of the E-Voting System. The SRS ensures that both
developers and users understand the operational, technical, and environmental needs of
the system, allowing for efficient setup and minimal errors during execution.

1. Hardware Requirements

The project has modest hardware requirements, as it is a lightweight Java-based

application.

• Processor: An Intel Core i3 or its equivalent, ensuring that GUI operations and
database queries are executed without delays.

• RAM: A minimum of 4 GB RAM is required to handle the Java Virtual Machine

(JVM), the application, and background system operations simultaneously.

• Storage: At least 200 MB of free storage for the Java Runtime Environment (JRE),
the application's .jar file, and the local voting_database.db file.

• Display: A standard display resolution of 1024x768 or higher ensures that all

application windows (LoginFrame, VotingFrame, ResultsFrame) are clearly visible.

• Connectivity: A stable internet connection is NOT required. The application is a

standalone desktop utility that interacts with a local database file.

2. Software Requirements

• Operating System: The system is cross-platform, supporting Windows, Linux, and

macOS.

• Runtime Environment: The Java Runtime Environment (JRE) (version 8 or

newer) must be installed on the user's machine to execute the application.

• Development Kit: For development, the Java Development Kit (JDK) (version 8
or newer) is required.

• Libraries: The project requires:

8
 o Java Swing ([Link]) for all GUI components.

o Java JDBC ([Link]) for the database-to-application communication API.

o SQLite-JDBC Driver: An external .jar library to enable JDBC to interface

with the SQLite database.

• Development IDE: For development and testing, IDEs like IntelliJ IDEA, Eclipse,
or NetBeans are recommended.

• Database: The system requires a SQLite database. It relies entirely on a local

voting_database.db file for persisting all voter, candidate, and vote-count data.

3. User Requirements

• To operate the system, users must have the Java Runtime Environment (JRE)
installed on their system.

• The user must be able to launch the application (e.g., by double-clicking the packaged
.jar file).

• The user must be provided with a valid, unique Voter ID to be authenticated by the
system.

• No internet connection is necessary to use the application.

• No prior technical knowledge is required; the graphical interface is designed to be

intuitive and user-friendly, guiding the user through the login and voting process with
clear prompts and dialog boxes.

4. System Environment

The project functions entirely in a Graphical User Interface (GUI) environment, built
using Java Swing. This design choice provides a user-friendly, interactive experience
(using windows, buttons, radio buttons, and tables) while remaining lightweight and
universally compatible across operating systems.

9
 System Development Life Cycle (SDLC)

Here is the "System Development Life Cycle (SDLC)" section, fully adapted for your E-
Voting System project.

System Development Life Cycle (SDLC)

The System Development Life Cycle (SDLC) defines the structured process followed to
ensure the systematic development, testing, and deployment of the E-Voting System.
Each phase was critical for ensuring the system's quality, security, and data integrity.

1. Planning Phase

In the planning phase, the primary objective was to define the project's scope and goals.
The need for a secure, simple, and standalone desktop application for conducting
small-scale elections (e.g., for a club or college) was identified. Key deliverables
included:

• A voter authentication screen.

• A secure voting ballot that prevents double-voting.

• A real-time results dashboard. Resource requirements, timeline, and

software/hardware needs (Java, Swing, SQLite) were assessed. Potential challenges,
such as ensuring database integrity (atomically casting votes) and handling user input
errors gracefully, were anticipated.

2. Analysis Phase

During the analysis phase, the system's requirements were studied in detail.

• Functional requirements were defined, such as: validating a Voter ID against a

database, checking a voter's hasVoted status, displaying a list of candidates (via
JRadioButton), atomically recording the vote (updating both voters and candidates
tables), and displaying sorted results in a JTable.

• Non-functional requirements like security (preventing double voting, using

PreparedStatement), data integrity, reliability, and usability (a simple, intuitive
GUI) were prioritized. Different data storage solutions were analyzed. A full-scale
server database (like MySQL) was deemed overly complex. SQLite was chosen for
its serverless, file-based nature, which is perfect for a standalone, portable desktop
application.

3. Design Phase

The design phase focused on the system's architecture, ensuring a clean separation of
concerns. The system was designed as a modular Java application with distinct

10
components:

• View (GUI): LoginFrame, VotingFrame, and ResultsFrame classes were designed to

handle all user-facing Swing components and event listeners.

• Model (Data/Logic): A DatabaseHelper class was designed to encapsulate all

database logic (connection, setup, and all SQL queries). This keeps the GUI classes
clean of any [Link] code.

• Database Schema: The database was designed with two main tables: voters (to store
IDs and hasVoted status) and candidates (to store names and votes counts).

• Critical Logic: The castVote method was specifically designed as an atomic

transaction (using setAutoCommit(false), commit, and rollback) to guarantee that a
voter's status and a candidate's vote count are always updated together, preventing data
corruption.

4. Implementation Phase

In the implementation phase, the design was converted into functional Java code. Classes
were created for:

• DatabaseHelper: Implementing all JDBC connection logic, CREATE TABLE

statements, INSERT OR IGNORE for initial data, SELECT queries for validation,
UPDATE transactions for voting, and SELECT ... ORDER BY for results.

• LoginFrame: Building the Swing GUI for voter ID input and handling ActionListeners
for the "Login" and "View Results" buttons.

• VotingFrame: Building the candidate selection GUI (JRadioButton, ButtonGroup) and

handling the "Cast Vote" button's action.

• ResultsFrame: Building the JTable to display results and implementing the "Refresh"
button's logic.

• MainApp: The main entry point to initialize the database ([Link]()) and
launch the LoginFrame. Proper coding practices, including OOP (encapsulation), try-
catch-finally blocks for database resources, and PreparedStatement to prevent SQL
injection, were followed.

5. Testing Phase

During the testing phase, the system was rigorously tested to ensure correctness, security,
and data integrity.

• Functional Testing:

o Valid Login: Tested with a valid ID (e.g., VOTER001).

o Invalid Login: Tested with a non-existent ID (e.g., VOTER999).

o Double Voting: Confirmed that after VOTER001 votes, they are rejected with
11
 an "ALREADY_VOTED" message upon a second login attempt.

• Edge Cases: Tested for empty string input in the Voter ID field and clicking "Cast
Vote" without selecting a candidate.

• Integration Testing: Verified that all modules worked together seamlessly—that a

successful login opened the VotingFrame, casting a vote correctly updated the
database, and the ResultsFrame (and its "Refresh" button) accurately reflected the new
vote counts.

6. Maintenance Phase

In the maintenance phase, the system is prepared for future updates and enhancements.

• Scalability: The code's modularity (especially the DatabaseHelper) makes it easy to

add new voters or candidates to the database by simply modifying the initializeData
method.

• Enhancements: The system is well-structured to be expanded, for example, by adding

an admin panel for managing candidates or refactoring it into a client-server
application for networked voting.

• Library Updates: Maintenance will involve managing updates to the SQLite-JDBC

driver as needed. The clear documentation and separation of concerns ensure that
future developers can easily understand, modify, and extend the system.

12
 ALGORITHM AND FLOWCHART

Here is the "Algorithm and Flowchart" section adapted for your E-Voting System project,
based on the five Java files you provided.

ALGORITHM AND FLOWCHART

The project’s algorithm defines the step-by-step logical sequence of operations necessary to
initialize the database, launch the user interface, and respond to user actions. The flow is
event-driven, ensuring a secure, interactive, and accurate voting experience.

Algorithm Steps:

1. Start the Program ([Link])

o Initialize the DatabaseHelper.

o Call the [Link]() method.

2. Setup Database ([Link])

o Connect to the SQLite database file (voting_database.db).

o Execute CREATE TABLE IF NOT EXISTS voters (with id and hasVoted

columns).

o Execute CREATE TABLE IF NOT EXISTS candidates (with name and votes
columns).

o Call initializeData() to INSERT OR IGNORE the default lists of voters and

candidates into the tables.

3. Launch Login GUI ([Link])

o On the Swing Event Dispatch Thread ([Link]), create a

new LoginFrame and set it to visible.

4. Wait for User Interaction (Event-Driven Loop in LoginFrame)

o The program enters an idle state, waiting for the user to trigger an ActionEvent
(e.g., click "Login to Vote" or "View Results").

5. Handle 'View Results' Button Event (Path A)

o Create a new ResultsFrame and set it to visible.

o The ResultsFrame constructor immediately calls its loadResults() method.

13
 o loadResults() calls [Link](), which runs a SELECT query to
fetch all candidates and their vote counts into a Map.

o The Map is sorted by votes (descending) and used to populate the JTable.

o The ResultsFrame has its own "Refresh" button, which simply re-runs
loadResults().

o The LoginFrame remains open, and the app returns to the "Wait" state (Step
4).

6. Handle 'Login to Vote' Button Event (Path B)

o a. Get Input: Get the voterId string from the voterIdField.

o b. Validate (Client-side): Check if voterId is empty. If yes, display a

JOptionPane error ("Voter ID cannot be empty") and return to Step 4.

o c. Validate (Database-side): Call [Link](voterId). This

method runs a SELECT hasVoted FROM voters WHERE id = ?.

o d. Handle Status: A VoterStatus enum (INVALID, ALREADY_VOTED, or

VALID) is returned.

▪ case INVALID: Display "Invalid Voter ID" error. Return to Step 4.

▪ case ALREADY_VOTED: Display "This Voter ID has already been

used" warning. Return to Step 4.

▪ case VALID: The ID exists and hasVoted is 0.

▪ Create a new VotingFrame(voterId) and set it to visible.

▪ dispose() (close) the LoginFrame.

▪ Proceed to Step 7.

7. Wait for Vote (Event-Driven Loop in VotingFrame)

o The program is now in a new wait state.

o The user selects a candidate (JRadioButton).

o The user clicks the "Cast Vote" button.

8. Handle 'Cast Vote' Button Event

o a. Validate (Client-side): Check if [Link]() is null. If

yes, display "Please select a candidate" warning and return to Step 7.

o b. Confirm: Get the selected candidate's name. Show a

[Link] ("You are voting for [X]. Are you sure?").

o c. Handle Confirmation: If the user selects "NO", return to Step 7.

14
 o d. Process Vote (Transaction): If the user selects "YES", call
[Link](voterId, candidateName).

o e. (Inside castVote) This method performs an atomic transaction:

▪ [Link](false).

▪ try:

▪ UPDATE voters SET hasVoted = 1 WHERE id = ? (Mark user

as voted).

▪ UPDATE candidates SET votes = votes + 1 WHERE name = ?

(Increment candidate vote).

▪ [Link]() (Finalize both changes). Return true.

▪ catch:

▪ [Link]() (Undo all changes if either update fails). Return

false.

o f. Handle Vote Result:

▪ If castVote returned true: Display "Thanks! Your vote was cast"

message. Call [Link](0) to terminate the program.

▪ If castVote returned false: Display "Error occurred" message. Return

to Step 7.

9. Check for Exit Condition

o If the user clicks the main window's 'close' (X) button, the
JFrame.EXIT_ON_CLOSE operation is triggered (on LoginFrame or
VotingFrame).

10. End Program

o The application terminates, and the Java Virtual Machine (JVM) shuts down
(either from Step 8f or Step 9).

Flowchart

This describes the high-level logical flow of the application.

1. START

2. Initialize DatabaseHelper

3. Execute setupDatabase() (Create tables, Insert default voters/candidates)

4. Display LoginFrame
15
5. Wait for User Event

6. [Decision] Event Type?

o [Click "View Results"] -> Go to Step 13

o [Click "Login to Vote"] -> Go to Step 7

o [Click Window Close] -> Go to Step 18 (END)

7. Get Voter ID from text field.

8. [Decision] ID Empty or Invalid? (Check validateVoter())

o [Yes] -> Show Error/Warning Message -> Go to Step 5

o [No (Status is VALID)] -> Go to Step 9

9. Close LoginFrame. Display VotingFrame.

10. Wait for User Event (in VotingFrame)

11. [Decision] Event Type?

o [Click "Cast Vote"] -> Go to Step 12

o [Click Window Close] -> Go to Step 18 (END)

12. [Decision] Candidate selected and confirmed by user?

o [No] -> Show Warning/Error Message -> Go to Step 10

o [Yes] -> Go to Step 16

13. [Branch from Step 6] Display ResultsFrame.

14. loadResults() (Query DB, populate JTable).

15. Wait for Event (in ResultsFrame). User can "Refresh" (Go to Step 14) or "Close"
(Frame is disposed) -> Go to Step 5.

16. [Branch from Step 12] Call [Link]() (Atomic Transaction).

17. [Decision] Vote Successful (Transaction OK)?

o [Yes] -> Show Success Message -> Call [Link](0) -> Go to Step 18
(END)

o [No (Transaction failed)] -> Show Error Message -> Go to Step 10

18. END

16
 IMPLEMENTATION

The project is a multi-window Java Swing application built on an event-driven model.

Unlike a single-class application, the implementation is decentralized across several
classes, following a strong separation of concerns principle (Model-View design).
This design separates the application into key functional areas:
• GUI / View Classes (LoginFrame, VotingFrame, ResultsFrame):
o Each class extends JFrame and is responsible for its own window.
o The constructor of each class builds and styles its specific Swing components
(e.g., JTextField in LoginFrame, JRadioButton in VotingFrame, JTable in
ResultsFrame).
o Each class implements its own event handlers using ActionListeners (via
anonymous classes or lambdas) to capture user input.
• Data & Logic / Model Class (DatabaseHelper):
o This class contains zero Swing components. Its sole responsibility is to
encapsulate all database logic.
o It handles all JDBC/SQLite connections, PreparedStatement queries, and
ResultSet processing.
o All core logic (validating voters, casting votes, fetching results) is implemented
as public methods in this class. The View classes simply call these methods.
• Event Handling (actionPerformed / Lambdas):
o This is the "controller" logic, located within the View classes.
o When a user clicks a button (e.g., loginButton), the ActionListener in
LoginFrame calls the handleLogin() method.
o handleLogin() in turn calls [Link](), gets a VoterStatus enum
back, and uses a switch statement to react—showing an error or opening the
VotingFrame.
• Input Validation & User Feedback:
o Validation is handled in the View classes before calling the database.
o LoginFrame checks for [Link]().
o VotingFrame checks for [Link]() == null.
o All user feedback—errors, warnings, confirmations, and success messages—
is handled using JOptionPane dialog boxes
17
SNAPSHOTS

Fig1: Login Page

Fig 2: Voting Page

18
Fig 3: Confirmation Page

Fig 4: Success Page

19
Fig 5: Result Page

20
 RESULTS AND DISCUSSION

The E-Voting System application was evaluated based on four key metrics: Data
Integrity, Security, Reliability (Stability), and User Experience.

System Performance and Integrity

The application is highly performant. All database queries—voter validation, vote

casting, and results tabulation—are processed instantaneously, as they interact with a
local SQLite file with no network latency.

Data integrity proved to be 100% successful. The implementation of atomic

transactions in the castVote() method (using commit and rollback) is the system's most
critical feature. It guarantees that a voter's status is updated if and only if their chosen
candidate's vote count is also incremented, completely preventing lost votes or data
corruption.

Reliability is excellent. The application handles all tested error states gracefully:

1. Client-Side: JOptionPane dialogs successfully prevent the user from submitting an

empty Voter ID or casting a vote without a candidate selected.

2. Database-Side: try-catch blocks for SQLException ensure that any database

connection error is handled without crashing the application.

Security

For its defined scope, the application is highly secure.

• The system's core security logic—checking the hasVoted flag—was proven to be

100% effective in preventing double-voting. A user who has already voted is always
rejected at the login screen.

• The exclusive use of PreparedStatement for all database queries (e.g., WHERE id = ?)
eliminates the risk of SQL Injection attacks, a critical vulnerability in data-driven
applications.

User Experience

The GUI was found to be highly intuitive. The workflow is simple and logical: Login ->
Vote -> Exit. Users noted the clear, modal separation of tasks into different windows
(LoginFrame, VotingFrame) as a key usability feature. The immediate and clear feedback
from JOptionPane dialogs (e.g., "Invalid Voter ID," "This Voter ID has already been
used," "Thanks! Your vote was cast") makes the process transparent and easy to follow.

21
Practical Impact

The project successfully serves its purpose as a fast, reliable, and secure offline utility for
small-scale elections (e.g., for clubs, student governments, or small organizations).

Academically, it serves as a strong, practical example of applying:

• Core Object-Oriented Programming (OOP)

• Event-driven programming in Java Swing

• Java Database Connectivity (JDBC) with SQLite

• Critical database concepts like Atomic Transactions

Discussion

The results confirm the success of the chosen Model-View architecture. The most
critical design choice was the separation of concerns—isolating all database logic and
SQL commands into the DatabaseHelper class, completely separate from the UI classes
(LoginFrame, VotingFrame).

This modularity is what makes the application reliable, secure, and maintainable.

• Reliability: The UI classes cannot accidentally corrupt the database because they don't
contain any SQL.

• Maintainability: All database logic is in one file. To add a new candidate, modify a
table, or fix a query, a developer only needs to edit DatabaseHelper.

• Scalability: The system can be easily scaled to include more voters or candidates by
simply modifying the initializeData() method or by creating an admin panel to manage
the database.

This project demonstrates that a well-designed, event-driven desktop application can

provide significant practical value by prioritizing data integrity, security, and a user-
friendly design.

22
 TESTING AND MAINTENANCE

Here is the "TESTING AND MAINTENANCE" section, adapted for your E-Voting System
project.

TESTING AND MAINTENANCE

Testing Techniques
1. Logical Unit Testing: Each core method in the DatabaseHelper was tested for its
specific logic.
o validateVoter() was tested with valid, invalid, and already-voted IDs to ensure
it returned the correct VoterStatus enum.
o castVote() was tested to confirm that it correctly updated both the voters and
candidates tables.
o getResults() was tested to ensure it returned an accurate Map of candidates and
their vote counts.
2. Integration Testing: We confirmed that all GUI components correctly interacted with
the event-handling logic and the database layer.
o Scenario 1: Clicking the "Login" button in LoginFrame successfully called
handleLogin(), which in turn called [Link]() and resulted in
the correct UI response (either a JOptionPane error or the opening of
VotingFrame).
o Scenario 2: A successful vote in VotingFrame correctly called
[Link](), and the "Refresh" button in ResultsFrame accurately
displayed the new vote count.
3. Input Validation Testing: The system was tested against invalid user actions.
o Login: Tested with an empty string ("") for Voter ID.
o Voting: Tested clicking "Cast Vote" without selecting a JRadioButton
candidate.
o In all cases, the system successfully prevented the action and displayed the
correct JOptionPane error dialog without crashing.
4. Security & Data Integrity Testing: This was the most critical test phase.
o Double-Voting: We confirmed that once a Voter ID (e.g., VOTER001) was
used to cast a vote, any subsequent login attempt with that same ID was
successfully blocked with the "Already Voted" message.
o Transaction Integrity: We simulated an error during the castVote transaction
(e.g., by forcing the second update to fail) to confirm that [Link]() was
triggered, leaving the database in its original, correct state (no vote cast, and
the user not marked as hasVoted).
5. Usability Testing: Users with no prior instructions were given a valid Voter ID and
were able to successfully log in and cast their vote, confirming the GUI is intuitive and
the workflow is logical.

23
 ADVANTAGES AND LIMITATIONS

Advantages:
1. Offline Functionality: The application is a stand-alone desktop utility that runs on a
local SQLite database. It does not require an internet connection, making it reliable,
secure, and accessible in any location.
2. High Data Integrity: The system uses atomic transactions (commit/rollback) for
casting votes. This guarantees that a vote is never lost or miscounted, ensuring that the
voter's status and the candidate's vote count are always updated together correctly.
3. Secure & Accurate: The application ensures one-voter-one-vote integrity by checking
a hasVoted flag, making it impossible for a single Voter ID to be used twice. It also uses
PreparedStatement to prevent SQL injection vulnerabilities.
4. Intuitive GUI: The graphical user interface (GUI) is simple, clean, and self-
explanatory. The "Login -> Vote -> Exit" workflow is logical and allows anyone to
use it efficiently without instructions.
5. Cross-Platform Portability: As a Java application, it adheres to the "Write Once, Run
Anywhere" (WORA) principle, allowing it to run on Windows, macOS, and Linux
systems that have a JRE.
6. Robust Error Handling: The use of JOptionPane dialogs and a switch statement on
the VoterStatus enum provides clear, user-friendly feedback for all common errors (e.g.,
"Invalid Voter ID," "This Voter ID has already been used," "Please select a candidate")
without crashing.

Limitations:
1. JRE Dependency: The application requires the user to have the Java Runtime
Environment (JRE) installed on their computer, which can be an extra step for non-
technical users.
2. Local-Only (Single Kiosk): As a standalone application using a local database file, it
is not a networked (client-server) system. It can only be run on a single machine
where voters must cast their ballots one after another (a "kiosk" model).
3. Static Election Data: The list of voters and candidates is hard-coded into the
[Link]() method. There is no admin panel or GUI to dynamically
add new voters, register candidates, or reset the election. All changes require modifying
the source code or manually editing the database file.
4. Desktop-Only: As a Java Swing application, it is limited to desktop operating systems
and is not available as a mobile app or a web-based tool for remote access.

24
 FUTURE SCOPE

The E-Voting System project serves as a strong foundation and has significant potential for
future expansion:
1. Client-Server Architecture
o Re-architecting the application from a standalone tool into a full client-server
system. A central server (e.g., built with Java Spring Boot) would host the
main database, and the Java Swing application would be converted into a
"client."
o This would allow multiple voting booth clients to connect and cast votes to
the same central database simultaneously and securely over a network.
2. Dynamic Admin Panel Ý '¯
o Developing a new, password-protected "Admin Panel" (JFrame) for election
administrators.
o This panel would provide full CRUD (Create, Read, Update, Delete)
operations, allowing an admin to dynamically add or delete voters, manage the
list of candidates, and reset the election (set all votes and hasVoted to 0)
without modifying the source code.
3. Modern UI/UX Framework
o Migrating the GUI from the older Java Swing to the more modern JavaFX.
o This would create a more visually appealing, CSS-styled user interface. It
would also allow for richer results visualization, such as a live-updating bar
chart or pie chart in the ResultsFrame instead of a simple table.
4. Full Web-Based Application _ □
;
o Re-developing the entire project into a web-based application.
o The core logic from DatabaseHelper could be moved to a Spring Boot REST
API backend, and the frontend could be built with a modern framework like
React or Angular.
o This would make the voting system accessible from any device with a web
browser (desktop, mobile, tablet) and completely remove the JRE
dependency for end-users.
5. Enhanced Security & Auditing º. t
o Implementing a more robust authentication system, such as requiring a unique
password for each Voter ID instead of just the ID itself.
o Adding an immutable audit log table to the database. This table would record
every single vote cast (and every failed attempt) with a voterId and timestamp,
creating a secure, unchangeable trail to verify the election's integrity.
6. Multilingual Support (Localization)
o Adding a feature (e.g., a dropdown menu on the LoginFrame) to change the
application's display language.

25
 CONCLUSION

The E-Voting System project demonstrates how core programming principles—

specifically Object-Oriented Programming (OOP), event-driven logic, Java Database
Connectivity (JDBC), and secure transaction management—can be leveraged to
create a highly practical and reliable desktop utility. It successfully bridges the gap
between theoretical computer science concepts and a tangible, real-world application.

• Data Integrity & Security: The project delivers a fast, secure, and offline tool that
provides a reliable voting process for small organizations, preventing double-voting
and guaranteeing 100% data integrity through atomic transactions.

• Modular Design: By strictly separating the database logic (DatabaseHelper) from

the user interface (...Frame classes), the application is exceptionally maintainable,
secure, and scalable. This Model-View design ensures that UI changes cannot break
database logic, and vice-versa.

• Trustworthy User Experience: The event-driven GUI transforms a complex,

sensitive manual process into a simple, intuitive, and secure digital workflow,
building user confidence with clear, instant feedback (e.g., "Vote Cast," "Already
Voted").

In essence, this project successfully implements a secure, standalone voting kiosk that
enforces the "one-voter-one-vote" rule, showcasing the power of robust, data-centric, and
well-structured software design.

26
 BIBLIOGRAPHY

1. Oracle. (2024). Java™ SE 8 Documentation. Retrieved from

[Link]
2. Oracle. (2024). [Link] (Java SE 8 API Documentation). Retrieved from
[Link]
3. Oracle. (2024). [Link] (Java SE 8 API Documentation). Retrieved from
[Link]
4. Schildt, H. (2018). Java: The Complete Reference, Eleventh Edition. McGraw-Hill
Education.
5. Bloch, J. (2018). Effective Java (3rd Edition). Addison-Wesley Professional.
6. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements
of Reusable Object-Oriented Software. Addison-Wesley Professional.
7. Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship.
Prentice Hall.
8. Eck, D. J. (2019). Introduction to Programming Using Java (8th Edition). Hobart and
William Smith Colleges.
9. Sommerville, I. (2015). Software Engineering (10th Edition). Pearson.

27