RISHIK REDDY L

21BCE3626
USE CASE DIAGRAM FOR E-Voting System Using Block Chain

USE CASE DIAGRAM

Here the use case diagram is quite self explanatory. It is basically
collecting the input data from the user during the registration time
and further using that data for verifying the user during the voting
data. On successful verification the user will be permitted to the
voting module where they can cast a vote for their preferred
candidate. It also illustrates all the modules used in our proposed
project and connection done between them.

Actors
• User : This represents the person casting a vote in the

election. The system authenticates the user through a login

process.
Objects
• Registration : This object captures the user's registration

information. It's unclear from this diagram how this

information is submitted to the system.
• Store login data and images : This object stores the user's

login credentials and possibly some identity verification

images.
• Login : This object could represent a login screen or API that

verifies the user's identity.

• Authorization : This object authorizes the user to cast a vote

after their login credentials have been verified.

• { Ask images for verification } : This annotation suggests that

the system may prompt the user to capture images for

identity verification purposes. It's unclear from this diagram
how these images are captured or used.
 • { Compares images } : This annotation suggests that the
system may use facial recognition or other image
processing techniques to compare the captured images to a
reference image, possibly the one stored in "Store login data
and images".
• Create datasets : It's unclear from this diagram what kind of

datasets are created here or how they are used.

• Verification of image : This object likely verifies the user's

identity based on the captured images (if image verification

is applied).
Annotations
• <<extends>> : In the context of use case diagrams, the

extension inheritance arrow indicates that the "Create

datasets" use case inherits functionality from the "Login"
use case. This suggests that creating datasets might be an
optional step that can be performed after a successful login.
• <<includes>> : In the context of use case diagrams, the

include inheritance arrow indicates that the "Verification of

image" use case functionality is always included in the
"Login" use case. This suggests that image verification is a
mandatory step for user login.
Data Transfers

The data appears to flow throughout the system as follows:

1. The user interacts with the Registration object, likely

entering their registration information. (How this information
is submitted to the system is not shown in the diagram).
2. The user interacts with the Login object, likely entering their
login credentials.
3. The system authenticates the user through the Login object.
4. If image verification is included, the system prompts the
user to capture images through the { Ask images for
verification } annotation.
 5. The captured images are compared to reference images
stored in Store login data and images through the {
Compares images } annotation.
6. The user is authorized to cast a vote after successful login
and image verification (if applicable).
7. It's unclear from this diagram what data is used to Create
datasets.
8. The user casts their vote (the diagram doesn't show how this
interaction happens).
Note: Because this is a use case diagram, it focuses on the
functionalities of the system from the user's perspective and
omits technical details about data storage and blockchain
technology.
 . Sequence Diagram

Actors

Candidate: This likely represents someone who is running for

office in the election. It is unclear from this diagram how a
candidate interacts with the system.
Voter: This is the person casting a vote in the election.

Objects
Login: This could represent a login screen or API that verifies the
voter’s identity.
OTP Generator: This object generates a one-time password (OTP)
that is sent to the voter’s phone number.
OTP SMS: This represents an SMS message containing the one-
time password. It is unclear from this diagram if the system itself,
or a separate SMS service, delivers the OTP SMS.
OTP Verification: This object verifies that the OTP entered by the
voter matches the one that was sent.
Vote Storage: This object stores the cast vote. It is unclear from
this diagram if this refers to a local storage unit or a database on a
remote server.
Result Generation: This object generates the results of the
election after all the votes have been cast.

Annotations

Grant Access: This annotation signifies that the voter is granted

access to cast their vote after their OTP has been verified.
Cast Vote: This annotation signifies the act of the voter casting
their vote.
Acknowledgement & Logout: This annotation signifies that the
voter receives confirmation that their vote has been cast and is
then logged out of the system.

Data Transfers
The data appears to flow throughout the system as follows:

1. The voter interacts with the Login object, likely entering their
login credentials.
2. The system authenticates the voter through the Login object.
3. The OTP Generator object creates a one-time password.
4. The OTP is sent to the voter’s phone number via the OTP SMS
object.
5. The voter enters the OTP into the system.
6. The OTP Verification object verifies that the OTP entered by the
voter matches the one that was sent.
7. Upon successful verification, the system grants the voter
access to cast their vote.
8. The voter selects their candidate and casts their vote.
9. The cast vote is stored in the Vote Storage object.
10. After all the votes have been cast, the Result Generation
object generates the results of the election.