1

1. PROBLEM STATEMENT

An electronic voting system via the Internet must fulfill the following five basic
requirements:
• Only people eligible to vote should be able to vote.
• It should be possible to use one’s vote only once.
• Ballots should be absolutely secret.
• It should not be possible for a vote cast to be changed by anyone else.
• The system should ensure correct tallying of votes at all levels (voting district,
constituency and area).
Other circumstances that may need to be taken into account in such a system are
safeguards for the voter’s personal integrity and means of preventing the sale of votes.

Authentication:
At present, the election database contains the national civic registration number of
everyone who is included in the electoral register. In an Internet voting system, the electoral
register needs supplement with the voter’s personal password or code, to permit reliable
identification.

Only one vote:

The system has information on all those who are eligible to vote, and when they do so
their votes are just as in the present-day manual procedure checked against the electionic
electoral register.

Ballot secrecy:
The system must not be technically feasible for any one to access the Ballot
information and should transmit it to the counting system.

Trustworthiness and legitimacy:

The system should be perceived as trustworthy and should impart legitimacy to the
election results, imposes special requirements in terms of permitting a revision of the system to
be carried out where necessary.
 2

Analysis
Use case view
2. IDENTIFICATION OF ACTORS

Actors represent system users. They help delimit the system and give a clear picture
of what the system should do. It is important to note that an actor interacts with, but has no
control over the use cases.

An actor is someone or something that:

1. Interacts with or uses the system
2. Provides input to & receive information from the system
3. Is external to the system and has no control over the use cases
Graphical Depiction
An actor is a stereotype of a class and is depicted as a "stickman" on a use-case
diagram.

ACTOR

The following question should be answered to identify actors:

1. Who is interested in a certain requirement?
2. Where in the organization the system is used?
3. Who will benefit from the use of the system?
4. Who will supply the system with the information, use this information and remove this
information?
5. Who will support and maintain the system?
6. Does the system use the external resource?
7. Does one person play several different roles?
8. Do several people play same role?
9. Does the system interact with the legacy system?
 3

Actors identified are:

1. Voter: A member of the organization who participates in the election by casting his/her vote.

voter
(from Actors)

2. Candidate: A member of the organization who participates in election by contesting in it.

Candidate
(from Actors)

3. Administrator: The person who takes care of conducting the elections by declaring the
election details and declaring the results.

Administrator
(from Actors)

4. Election Database: External resource used by the system for voter Identification and profile
manipulation operation.

Election Database

(from Actors)

5. Election Commission: System that maintains the election database and get benefit form the
e-voting process.
 4

Election Commission

(from Actors)

3. IDENTIFICATION OF USECASES AND SUB USE CASES

In its simplest form a use case can be described as a specific way of using the system
from a user’s perspective.
A more detailed description might characterize a use case as:
• A pattern of behavior the system exhibits
• A sequence of related transactions performed by an actor and the system
• Delivering something of value to the actor.
Use case provides a mean to:
1. Capture system requirements
2. Communicate with the end users and domain experts
3. Test the system

Use cases are the best discovered by examining the actors and defining what the actor
will be able to do with the system. Since all needs of a system typically cannot be covered in
one use case, it is usual to have a collection of use cases. Together this use case collection
specifies all ways of using the system.

UML notation for the use case:

1. An ellipse containing the name of the use case inside it.
Error: Reference source not found
Voting

2. An ellipse containing the name of the use case below it

 5

voting
(from voti ng)

The following questions are to be answered to identify the use cases:

1. What are the tasks of each actor?
2. Will any actor create, store, change, remove, or read information in the system?
3. What use cases will store, change, remove or read this information?
4. Will any actor need to inform the system about sudden external changes?
5. Does any actor need to be perform about certain occurrences in the system?
6. What use cases will support and maintain the system?
7. Can all functional requirements be performed by the use cases?

Use cases identified are:

1. Authentication System: It verifies the voter’s authorization based on the voterID and
password.

2. View profile: It allows the Authorized voter to see the candidate/his profile and to get
know about this vote that is polled for selected candidate with a confirmation receipt to voter.

3. Voting System: It will process the voter’s ballot.

4. Profile Manipulation: It will process the profile of voters and the candidates that includes the
certain, modification and deletion process.

5. Ballot Secrecy: It makes the ballot information secured and passes the encrypted secured
ballot information to the results use case.

6. Results: Performs the counting of ballots polled for each candidate and announce the
Election results to the Election commission.
 6

7. Database Manipulation: Performs creation and manipulation of the database.

 7
4. FLOW OF EVENTS

A flow of events is a sequence of transactions (or events) performed by the system.

They atypically contain very detailed information, written in terms of what the system should
do, not how the system accomplishes the task. Flow of events are created as separate files or
documents in your favorite text editor and then attached or linked to a use case using the files
tab of a model element.

Flow of events should include:

• When and how the use case starts and ends
• Use case / actor interactions
• Data needed by the use case
• Normal sequence of events for the use case
• Alternate or exceptional flows

Flow of events in E-Voting system:

1. Use Case Specification for the Authentication system use case:

1.0 Use Case Name
Authentication System

1.1 Brief Description

The voter starts this use case. It provides the capability for the system to perform on-line
identification of the voters.

2.0 Flow of Events

2.1 Basic Flow
This Use Case begins when the voter logs into the identification system and enters his/her
password. The system verifies that the voter ID and the password is valid (if they are invalid
alternate flow 2.2.1 is executed). To perform this validation, this use case makes use of the
election database. After the Successful validation it will pass a report to the Administrator.
 8
2.2 Alternate Flows
2.2.1 Invalid Voter ID
An invalid Voter ID is entered. The user can re-enter his/her voter ID or terminate the use case.

2.2.2 Invalid Password

An invalid password is entered. The user can re-enter his/her Password or terminate the use
case.

3.0 Special Requirements

To perform voter identification this use case requires the external Election Database.

4.0 Preconditions
There are no preconditions.

5.0 Post Conditions

There are no Post Conditions.

6.0 Extension Points

There are no extension points.

2. Use Case Specification for the View Profile use case:

1.0 Use Case Name
View profile

1.1 Brief Description

This use case is started by the Authentication system use case and access by the voter. It allows
voter to see the candidate profile and also to get know about his vote is polled/counted for
selected candidate or not with some conformation receipt to voter.

2.0 Flow of Events

2.1 Basic Flow
This Use Case begins after the voter was authenticated and shows the profile of him/her self or
the candidate.
 9
2.2 Alternate Flows
2.2.1 Wrong profile selection:
When the voter selected wrong profile, the use case allows selecting correct profile again.

3.0 Special Requirements

There are no special requirements.

4.0 Preconditions
4.1. Authentication:
The voter must be identified as a valid voter before entering into this use case.

4.2. Correct profile/update profile:

The profile must be the updated one before it is going to access.

5.0 Post Conditions

There are no Post Conditions.

6.0 Extension Points

There are no extension points.

3. Use Case Specification for the Voting system use case:

1.0 Use Case Name
Voting System

1.1 Brief Description

This use case is started by the Authentication system use case. It provides the capability to the
system to process the voter’s ballot.

2.0 Flow of Events

2.1 Basic Flow
This Use Case begins when the voter is identified as the valid voter by the Authentication
system.
 10
2.2 Alternate Flows
2.2.1 Invalid Ballot:
An invalid ballot of voter is rejected and prompts the voter to perform correct ballot, i.e., when
the submit button is pressed without selecting the candidate’s vote/ballot, then the above said
operation will be taken place.

2.2.2 Cancellation of Ballot:

If voter selected the cancel operation at any time before the submit button is pressed, and then
this use case cancels the noted ballot.

3.0 Special Requirements

There are no special requirements.

4.0 Preconditions
4.1. Authentication:
The voter must be identified as a valid voter before entering into this use case.

5.0 Post Conditions

This use case must send the ballot report to the voter and the administrator.

6.0 Extension Points

There are no extension points.

4. Use Case Specification for the Report Use Case:

1.0 Use Case Name
Report

1.1 Brief Description

This use case is started by the Voting system use case, It provides the report of voter's ballot to
the administrator and voter.

2.0 Flow of Events

2.1 Basic Flow
This Use Case begins when the voting system noted the voter's ballot and other information
about the voter, and sends a report to both the voter and administrator.
 11
2.2 Alternate Flows
There are no alternate flows.

3.0 Special Requirements

There are no special requirements.

4.0 Pre-conditions
There are no pre-condition.

5.0 Post Conditions

There are no post conditions.

6.0 Extension Points

There are no extension points.

5. Use Case Specification for the Profile Manipulation Use Case:

1.0 Use Case Name
Profile Manipulation

1.1 Brief Description

The Administrator starts this use case. It provides the capability to the system to process the
profiles of voters and the candidates. The processing here includes creation, modification and
deletion process.

2.0 Flow of Events

2.1 Basic Flow
The Use Case begins when the administrator initiated the manipulation process of profile. It
makes use of the election database for its operation.

2.2 Alternate Flows

There are no alternate flows.

3.0 Special Requirements

This use case requires the external election database for its operation.
 12
4.0 Pre-conditions
The election database must be the updated one, before this use case is started.

5.0 Post Conditions

There are no post conditions.

6.0 Extension Points

There are no extension points.

6. Use Case Specification for the Ballot Secrecy system Use Case:
1.0 Use Case Name
Ballot Secrecy System

1.1 Brief Description

The Administrator starts this use case. It provides the capability for the system to process the
ballot information and make it secured. It passes the encrypted secured ballot information to
the results use case where counting will takes place.

2.0 Flow of Events

2.1 Basic Flow
This Use Case begins when the Administrator passed the ballot information to this use case.

2.2 Alternate Flows

There are no alternative flows.

3.0 Special Requirements

There are no special requirements.

4.0 Pre-conditions
There are no pre-conditions.

5.0 Post Conditions

There are no Post Conditions.

6.0 Extension Points

There are no extension points.
 13
7. Use Case Specification for the Results Use Case:
1.0 Use Case Name
Results

1.1 Brief Description

This use case is started by the Ballot secrecy use case, it provides the capability to the system
to perform the counting of ballots polled for each candidate and announces the election results
to the election commission.

2.0 Flow of Events

2.1 Basic Flow
The Use Case begins when the ballot secrecy use case sends the secured ballot information to
this use case.

2.2 Alternate Flows

There are no alternate flows.

3.0 Special Requirements

There are no special requirements.

4.0 Pre-conditions
Ballot information should be secured before the counting.

5.0 Post Conditions

Must pass the results information to the election commission.

6.0 Extension Points

There are no extension points.
 14
8. Use Case Specification for the Database manipulation Use Case:
1.0 Use Case Name
Database Manipulation

1.1 Brief Description

The Administrator starts this use case. It provides the capability to the Administrator to create
and manipulate the election database in which the voter's profiles are stored.

2.0 Flow of Events

2.1 Basic Flow
The Use Case begins when the Administrator initiated it or try to manipulate the election
database.
2.2 Alternate Flows
There are no alternate flows.

3.0 Special Requirements

There are no special requirements.

4.0 Pre-conditions
There are no pre-conditions.

5.0 Post Conditions

There are no post conditions.

6.0 Extension Points

There are no extension points.
 15
5. CONSTRUCTION OF USE CASE DIAGRAMS

Use case diagrams depict system behavior (use cases). These diagrams present a high
level view of how the system is used as viewed from an outsider’s (actor’s) perspective. A use
case diagram may depict all or some of the use cases of a system.
A use-case diagram can contain:
• Actors (“things” outside the system)
• Use case (system boundaries identifying what the system should do)
• Interactions or relationships between actors and use case in the system including the
associations, dependencies, and generalizations.

Uses associations
The uses association occurs when we are describing our use cases and notice that
some of them have sub flows in common to avoid describing a sub flow more than once in
several use cases, you can extract the common sub flow and make it a use case of its own. This
new use case then can be used by other use cases. The relationships among the other use cases
and this new extracted use case are called uses association.

Extends association
An extends association is a stereo typed association that specifies how the
functionality of one use case can be inserted in to the functionality of another use case. Extend
relationships between use cases are modeled as dependency by using the extend stereotype.

Includes association
An include association is a stereo typed association that connects a base use case to
an inclusion use case.
 16
The main use case diagram of E-voting system:
 17
6. BUILD A BUSINESS PROCESS MODEL USING
ACTIVITY DIAGRAM

Activity diagrams provide a way to model the workflow of a business process. An

activity diagram is typically used for modeling the sequence of Activities in a process. Activity
diagrams can model many different types of workflows. A software company could use
activity diagrams to model a software development process. The following tools are used on
the activity diagram toolbox to model activity diagrams.

 Decisions: A decision represents a specific location on activity diagram when the

workflow may branch based upon guard conditions.
 Synchronization: Synchronization visually defines forks and joins representing
parallel workflow.
 Forks and Joins: A fork construct is used to model single flows. A join consists of two
or more flows of control that unite into a single flow of control.
 States: “A state represents a condition or situation during the life of an object during
which it satisfies some condition or waits for some event.
 Transitions: A state transition indicates that an object in the source state will perform
certain specified actions and enter the destination state when a specified event occurs or
when certain conditions are satisfied.
 Start States: A start state (also called an “initial state”) explicitly shows the beginning
of a workflow.
 End States: An end state represents a final or terminal state.
 SwimLane: A unique diagram feature that defines who or what is responsible for
carrying out activity or state.
 Work Flow: Each activity represents the performance of a group of actions in a
workflow.
18
 19

Logical View

7. IDENTIFICATION OF ANALYSIS CLASSES

Identification of classes can be done by the noun phrase approach, the common class
patterns approach, the use-case driven sequence/collaboration modeling approach and the
classes’ responsibilities and collaborators (CRC) approach.

NOUN PHRASE APPROACH

This approach was proposed by Rebecca Wirfs-Brock, Brain Wilker-son, and Luaren
Wiener. In this method, we read through the requirements or use-cases looking for noun
phrases. Nouns in the textual description are considered to be classes and verbs to be methods
of the classes then, the nouns are listed, and divided in to three categories: relevant classes,
fuzzy classes and the irrelevant classes.

COMMON CLASS PATTERN APPROACH

It is based on the knowledge base of common existing classes. The candidate classes
can be formulated using the following:

Concept Class: Concept is an understanding of our world.

Event Class: These are points in time that must be recorded.
OranisationClass: It is a collection of people, resources, facilities or groups to which the users
belong.
People class: The people class represents the different roles users play in interacting with the
application.
Places Class: These are the physical locations.
Tangible things and Devices Class: It includes physical objects or groups of objects that are
tangible.
 20
USE-CASE DRIVEN APPROACH:
Here the scenarios are described in text or through a sequence of steps. It is a problem
driven approach to object oriented analysis in which the designer first considers the problem at
hand and not the relationship between objects.

CLASSES RESPONSIBILITIES AND COLLABORATORS

This technique is used to identify the classes, responsibilities and therefore their
attributes and methods. It is based on the idea that an object can either accomplish a certain
responsibility by itself or it may require the assistance of other objects in which case it
collaborates.

Out of these, the noun phrase is used to identify the classes to increase our understanding of the
subject.

1. The initial list of noun phrases:

Administrator
Authentication
Voter
Ballot
Ballot code
Ballot number
Ballot paper
Ballot information
Candidate
Election
Election date
Election Database Information
Election commission
Login id
Name
Online voting system
Password
Profile
View profile
Profile modification
 21
Results date
Results
Security question
Voting System
Voting server
Website

2. Reviewing the irrelevant classes:

It is safe to eliminate the irrelevant classes. The candidate classes must be selected from
relevant classes and fuzzy classes. The following irrelevant classes can be eliminated:
Administrator
Authentication
Voter
Ballot
Ballot code
Ballot number
Ballot paper
Ballot information
Candidate
Election
Election date
Election Database Information
Election commission
Login id
Name
Online voting system
Password
Profile
View profile
Profile modification
Results date
Results
Security question
Voting System
 22
Voting server
Website

3. Reviewing the redundant classes and building a common vocabulary:

Here the several classes appear more than once. Hence we eliminate the redundant classes
Ballot, Ballot paper = Ballot paper
Online voting system, Election = Online voting system
Ballot code, Ballot number, Password = Ballot number
Login id = login id

Administrator
Authentication
Voter
Ballot
Ballot code
Ballot number
Ballot paper
Candidate
Election
Election Database Information
Election commission
Login id
Name
Online voting system
Password
Profile
View profile
Profile modification
Results
Voting System
Voting server
 23
4. Reviewing the classes containing adjectives:
In this system we have no classes containing adjectives that we can eliminate.

5. Reviewing the possible attributes:

The noun phrases used only as values should be restated as attribute classes.
The following are attribute classes:
Ballot number, Ballot paper, election Information,
Login id, Name

Administrator
Authentication
Voter
Ballot
Ballot code
Ballot number
Ballot paper
Candidate
Election
Election Database Information
Election commission
Login id
Name
Online voting system
Password
Profile
View profile
Profile modification
Results
Voting System
Voting server
 24
6. The Final List of Classes is:
Administrator
Authentication
Voter
Candidate
Data base information
Election Commission
View profile
Voting information
Profile Modification
Ballot information
Results
Voting system
 25
8. IDENTIFY THE RESPOSIBILITIES OF CLASSES

CRC developed by Cunningham, Wilkerson, and Beck. Classes Responsibilities and

Collaborators is a technique used for identifying classes’ responsibilities and their attributes
and methods. They also help in identifying the classes. Classes Responsibilities and
Collaborators is based on the idea that an object either can accomplish a certain responsibility
itself or it may require the assistance of other objects .If it requires the assistance of other
objects, it must collaborate with those objects to fulfill its responsibility. By identifying an
object’s responsibilities and collaborators attributes and methods can be identified.

The Classes, Responsibilities, and Collaborators process consists of three steps:

1. Identify classes’ responsibilities (and identify classes)
2. Assign responsibilities
3. Identify collaborators

Class name Responsibilities

Administrator Manipulates database and submits ballots.
Authentication Checks the validity of a voter.
Voter Castes his vote and views candidate’s/his profile.
Candidate Creates nomination and submits it.
Database Creation of election database and profiles of voter and
information candidates participating in elections.
Election commission Declares the election result.
View profile Shows the required profile information.
Voting information Generates the ballot report.
Profile modification Updates the selected profile in the Election database.
Ballot information Secures the ballot information.
Results Counts the ballots.
 26
9. CONSTRUCTION OF USE CASE REALIZATIONS

A use case realization is a graphic sequence of events, also referred to as a scenario or

an instance of a use case. These realizations or scenarios are depicted in either a sequence or
collaboration diagrams.

The use case realizations for E-Voting system:

 27
10. CONSTRUCTION OF SEQUENCE DIAGRAM

A sequence diagram is a graphical view of a scenario that shows object interaction in

a time-based sequence-what happens first, what happens next. Sequence diagrams establish the
roles of objects and help provide essential information to determine class responsibilities and
interfaces. A sequence diagram has two dimensions: the vertical dimension represents time; the
horizontal dimension represents different objects. The vertical line is called the object’s
lifeline. The lifeline represents the object’s existence during the interaction. This form was first
popularized by Jacobson. An object is shown as a box at the top of a dashed vertical line. A
role is a slot for an object within a collaboration that describes the type of object that may play
the role and its relationships to other roles. However, a sequence diagram does not show the
relationships among the roles ort eh association among the objects. An object role is shown as
a vertical dashed line, the lifeline.

Each message is represented by an Arrow between the lifelines of two objects. The
order in which these messages occur is shown top to bottom on the page. Each message is
labeled with the message name. The label also can include the argument and some control
information and show self-delegation, a message the argument and some control information
and show self-delegation, a message that an object sends to itself, by sending the message
arrow back to the same lifeline. The horizontal ordering of the lifelines is arbitrary. Often, call
arrows are arranged to proceed in one direction across the page, but this is not always possible
and the order conveys no information.

The sequence diagram is very simple and has immediate visual appeal---this is its
great strength. A sequence diagram is an alternative way to understand the overall flow of the
control of a program, instead of looking at the code and trying to find out the overall sequence
of behavior.

The following tools located on the sequence diagram toolbox which enable to model sequence
diagrams:
 Object: An object has state, behavior, and identity. The structure and behavior of
similar objects are defined in their common class. Each object in a diagram indicates
some instance of a class. An object that is not named is referred to as a class instance.
 28
 Message Icons: A message icon represents the communication between objects
indicating that an action will follow. The message icon is a horizontal, solid arrow
connecting two lifelines together.
 Focus of Control: Focus of Control (FOC) is an advanced notational technique that
enhances sequence diagrams. It shows the period of time during which an object is
performing an action, either directly or through an underlying procedure.
 Message to Self: A Message to Self is a tool that sends a message from one object back
to the same object. It does not involve other objects because the message returns to the
same object. The sender of a message is the same as the receiver.
 Note: A note captures the assumptions and decisions applied during analysis and
design. Notes may contain any information, including plain text, fragments of code, or
references to other documents.
 Note Anchor: A note anchor connects a note to the element that it affects.

Sequence diagrams for each uses case of E-Voting system are as follows:

Authentication system use case realization:

: voter C-Verify : C-VProf : C-vinf :

C_Authenticate C_View_Profile C_Voting_info

1: Enter loginID

2: Not Valid

3: Valid

4: Caste Vote
 29

Ballot Secrecy use case realization:

: administrator C-Binf : C_Ballot_info B-Vote : B_Voting

1: Ballot Report

2: Secure

3: Send Sucured Ballot

View Profile use case realization:

 30

: voter C-Verify : C-Vprof :

C_Authenticate C_View_Profile

1: Enter LoginID

2: Not Valid

3: Valid

Profile manipulation use case realization:

 31

: administrator E-D Binf : C-PModfy :

E_Database_info C_Profile_Modify

1: Voter Information

2: Create Profile

3: Report

4: Send Profile

5: Modify Profile

6: Report Update

Database Manipulation use case realization:

 32

: administrator E-DBinf : B-UseDB : B_Use_Database

E_Database_info

1: Voter information

2: Create Database

3: Report

4: Voter Information

5: Get Database

6: Update

7: Save updates
 33
Results use case realization:

: administrator B-Vote : B _Vo ting c-Res : C_Results C-ecm :

C_ECommissi on
1: Ballot report

2: Send Ballot Report

3: Count Results

4: Send Report

5: Declare Results

Voting System use case realization:

: voter C-Verify : C-Vinf : : administrator

C_Authenticate C_Voting_info

1: Enter LoginID

2: Not Valid

3: Caste Vote

4: Send Ballot Report

 34
11. CONSTRUCTION OF COLLABORATION DIAGRAM

Collaboration diagram is an interaction diagram that shows the order of messages that
implement an operation or a transaction. Another type of interaction diagram is the
collaboration diagram. A collaboration diagram is a set of objects related in a particular
context, and interaction, which is a set of messages exchanged among the objects within the
collaboration to achieve a desired outcome. In a collaboration diagram, objects are shown in
figures. As in a sequence diagram, arrows indicate the message sent within the given use case.
In a collaboration diagram, the sequence is indicated by numbering the messages. Some people
argue that numbering the messages makes it more difficult to see the sequence than drawing
the lines on the page. However, since the collaboration diagram is more compressed, other
things can be shown more easily. A collaboration diagram provides several numbering
schemes.

Two types of Numbering Sequences are:

1. Flat Sequence.
2. Decimal Sequence
The disadvantage of interaction diagrams is that they are great only for representing a
single sequential process; they begin to break down when you want to represent conditional
looping behavior. However, conditional behavior can be represented in sequence or
collaboration diagrams for each scenario.
Differences between sequence and collaboration diagrams:
 Sequence diagrams show time-based object interaction while Collaboration diagrams
show how objects associate with each other.
 The Create Collaboration Diagram Command creates a collaboration diagram from
information contained in the sequence diagram. The Create Sequence Diagram
Command creates a sequence diagram from information contained in the interaction's
collaboration diagram.
 Sequence diagrams are closely related to collaboration diagrams and both are alternate
representations of an interaction. Sequence diagram is easier to read where as
collaboration diagram shows how objects are statically connected.
 35
Collaboration diagrams for E-Voting system are as follows:
Authentication system Use Case:

1: Enter loginID

2: Not Valid
: voter C-Verify :
C_Authenticate 4: Caste Vote

3: Valid

C-VProf : C-vinf :
C_View_Profile C_Voting_info

Ballot Secrecy Use Case:

2: Secure

1: Ballot Report

: administrator C-Binf : C_Ballot_info

3: Send Sucured Ballot

B-Vote : B_Voting
 36
Database Manipulation Use Case:

6: Update 2: Create Database

1: Voter information

3: Report
: administrator E-DBinf :
E_Database_info

4: Voter Information
5: Get Database 7: Save updates

B-UseDB : B_Use_Database

Profile Manipulation Use Case:

2: Create Profile

1: Voter Information

3: Report
: administrator E-DBinf :
E_Database_info

6: Report Update 5: Modify Profile

4: Send Profile

C-PModfy :
C_Profile_Modify
 37
Results Use Case:

View Profile Use case:

1: Enter LoginID

2: Not Valid
: voter C-Verify:
C_Authenticate

3: Valid

C-Vprof :
C_View_Profile
 38
Voting System Use case:

1: Enter LoginID

2: Not Valid
: voter C-Verify :
C_Authenticate

3: Caste Vote

4: Send Ballot Report

C-Vinf : : administrator
C_Voting_info
 39
12. IDENTIFICATION OF ATTRIBUTES
AND METHODS OF CLASSES

Guidelines for identifying attributes of classes are as follows:

 Attributes usually correspond to nouns followed by prepositional phrases. Attributes

also may correspond to adjectives or adverbs.
 Keep the class simple; State only enough attributes to define the object state.
 Attributes are less likely to be fully described in the problem statement.
 Omit derived attributes.
 Do not carry discovery attributes to excess.

The following questions help in identifying the responsibilities of classes and deciding what
data elements to keep track

 What information about an object should we keep track of?

 What services must a class provide?

Answering the first question help we to identify the attributes of a class. Answering the second
question help us to identify class methods.

The attributes identified in E-Voting system are:

Attributes for Administrator class: VoterID, Ballot info.
Attributes for Authentication class: VoterID, Voter Password.
Attributes for Voter class: VoterID, Voter Password, and Voter Name.
Attributes for Candidate class: Party symbol, Constituency.
Attributes for Data base information class: VoterID, Voter Name.
Attributes for Election Commission class: Ballot info.
Attributes for View profile class: VoterID, Voter Name.
Attributes for Voting information class: VoterID, Ballot Number, Vote polled.
Attributes for Profile Modification class: VoterID, Voter Name, Address.
Attributes for Ballot information class: Votes polled, Status of votes.
Attributes for Results class: Votes polled, Party symbol, Constituency.
Attributes for Voting system class: VoterID, Voter Name, Ballot Number
 40

The responsibilities identified in E-Voting system are:

Methods for Administrator class: Manip_databse, submit_report.
Methods for Authentication class: Check_Validty.
Methods for Voter class: caste_vote, view_result.
Methods for Candidate class: Create_nomination, Submit_nomination.
Methods for Data base information class: Create_DB, Create_Profile.
Methods for Election Commission class: Declare_results.
Methods for View profile class: Show_ profile.
Methods for Voting information class: Generate_report_ballot.
Methods for Profile Modification class: Update_ profile.
Methods for Ballot information class: Secure ballot.
Methods for Results class: Count votes.
Methods for Voting system class: Send_report.
 41

13. IDENTIFICATION OF RELATIONSHIPS

AMONG CLASSES

There are three types of relationships between classes. They are:

 Association: This relationship represents a physical or conceptual connection between

two or more objects.

 Super-sub structure (Generalization hierarchy): These allow objects to be build from

other objects. The super-sub class hierarchy is a relationship between classes, where
one class is the parent class of another class

 A-part-of relationship (Aggregation): This represents the situation where a class

consists of several component classes.

The class relationships identified in E-Voting system:

 42

14. CONSTRUCTION OF UML STATE CHART DIAGRAM

State chart diagrams model the dynamic behavior of individual classes or any other
kind of object. They show the sequences of states that an object goes through, the events that
cause a transition from one state to another and the actions that result from a state change.

State chart diagrams are closely related to activity diagrams. The main difference
between the two diagrams is state chart diagrams are state centric, while activity diagrams are
activity centric. A state chart diagram is typically used to model the discrete stages of an
object’s lifetime, whereas an activity diagram is better suited to model the sequence of
activities in a process. Each state represents a named condition during the life of an object
during which it satisfies some condition or waits for some event. A state chart diagram
typically contains one start state and multiple end states. Transitions connect the various
states on the diagram.

The following tools are used on the state chart diagram toolbox to model state chart
diagrams:
 Decisions: A decision represents a specific location on state chart diagram where the
workflow may branch based upon guard conditions.
 Synchronizations: Synchronizations visually define forks and joins representing parallel
workflow.
Forks and Joins: A fork construct is used to model a single flow of control that divides
into two or more separate, but simultaneous flows. A join consists of two of more flows of
control that unite into a single flow of control.
 States: A state represents a condition or situation during the life of an object during which
it satisfies some condition or waits for some event.
 Transitions: A state transition indicates that an object in the source state will perform
certain specified actions and enter the destination state when a specified event occurs or
when certain conditions are satisfied.
 Start states: A start state (also called an "initial state") explicitly shows the beginning of a
workflow
 End States: An end state represents a final or terminal state
 43

The state chart diagram for E-Voting system is as follows:

 44
15. CONSTRUCTION OF UML STATIC CLASS DIAGRAM

A class diagram is a picture for describing generic descriptions of possible systems.

Class diagrams and collaboration diagrams are alternate representations of object models.
Class diagrams contain classes and object diagrams contain objects, but it is possible to mix
classes and objects when dealing with various kinds of metadata, so the separation is not rigid.

Class diagrams are more prevalent than object diagrams. Normally you will build
class diagrams plus occasional object diagrams illustrating complicated data structures or
message-passing structures.

Class diagrams contain icons representing classes, interfaces, and their relationships.
We can create one or more class diagrams to depict the classes at the top level of the current
model; such class diagrams are themselves contained by the top level of the current model. We
can also create one or more class diagrams to depict classes contained by each package in your
model; such class diagrams are themselves contained by the package enclosing the classes they
depict; the icons representing logical packages and classes in class diagrams.

We can change properties or relationships by editing the specification or modifying

the icon on the diagram. The associated diagrams or specifications are automatically updated.

Classes may be of 3 types. They are:

1. Entity class
2. Boundary class
3. Control class

 Entity class: An entity class models information and associated behavior that is
generally long live.
 Boundary Class: They handle the communication between the systems. They can
provide the interface to the user or another system. Ex: Registration form.
 Control Class: Control class model sequencing behavior specific to one or more use-
cases. You can think of control class as running or executing the use-case i.e., they
represent the dynamics of the use-case. Ex: Registration Manager.
 45
STEREOTYPES AND CLASSES:
A Stereotype provides the capability to create a new kind of modeling element. Some
common stereotypes for a class are Entity, Boundary, Control, Utility and Exception. The
stereotype for a class shown below the class name enclosed in guillemets (<< >>). If desired, a
graphic icon or a specific color may be associated with a stereotype.

A Stereotyped UML class diagram of the E-Voting System

 46

DESIGN

16. DESIGN CLASSES BY APPLYING DESIGN AXIOMS

An axiom is a fundamental truth that always is observed to be valid and for which
there is no counter example or exception. Suh explains that axioms may be hypothesized from
a large number of observations by noting the common phenomena shared by all cases; they can
not be proven or derived, but they can be invalidated by counter examples or exceptions.

The author has applied Suh’s design axioms to object-oriented design. Axiom 1 deals
with relationships between system components (such as classes, requirements, and software
components), and Axiom 2 deals with complexity of design.
Axiom 1: The independence axiom. Maintain the independence of components.
Axiom 2: The information axiom. Minimize the information content of the design.

Axiom 1 states that, during the design process, as we go from requirements and use
case to a system component, each component must satisfy that requirement without affecting
other requirements.

Axiom 2 is concerned with simplicity. Scientific theoreticians often rely on a general

rule known as Occam’s razor, after William of Occam, a 14th century scholastic philosopher.
Briefly put, Occam’s razor says that,”The best theory explains the known facts with a
minimum amount of complexity and maximum simplicity and straight forwardness”.
 47
17. REFINE ATTRIBUTES, METHODS & RELATIONSHIPS

The following is the attribute presentation suggested by UML:

visibility name: type-expression=initial-value
where visibility is one of the following:
+ public visibility (accessibility to all classes)
# protected visibility (accessibility to sub classes and operations of the class).
- private visibility (accessibility only to operations of the class).
Type-expression is a language-dependent specification of the implementation type of an
attribute.
Initial-value is a language-dependent expression for the initial value of a newly created object.
The initial value is optimal.

The UML style guidelines recommend beginning attribute names with a lower-case
letter. In the absence of a multiplicity indicator (array), an attribute holds exactly one value.
Multiplicity may be indicated by placing a multiplicity indicator in brackets after attribute
name. At this stage, we need to add more information to these Methods, such as visibility and
implementation type.
Refining Attributes for the Administrator class:
+ VoterID: Number
+ Ballot info: String

Refining Attributes for the Candidate class:

+ Party symbol: Symbol
+ Constituency: String

Refining Attributes for the View_Profile class:

# VoterName: String

Refining Attributes for the Voter class:

- Password: String

Refining Attributes for the Voting_ info class:

# Ballot Number: String
- VotePolled: Number

Refining Attributes for the Profile_modify class:

# Address: String
 48
Refining Attributes for the Ballot_info class:
# Status of vote: Number

A class can provide several types of methods:

• Constructor: Method that creates instances (objects) of the class
• Destructor: The method that destroys instances.
• Conversion method: The method that converts a value from one unit of measure to another.
• Copy method: The method that copies the contents of one instance to another instance.
• Attribute set: The method that sets the values of one or more Methods.
• Attribute get: The method that returns the values of one or more Methods.
• I/O methods: The methods that provide or receive data to or from a device.
• Domain specific: The method specific to the application.

The following operation presentation has been suggested by the UML. The operation syntax is
this:
visibility name: (parameter-list) : return-type-expression
where visibility is one of:
+ public visibility(visibility to all classes)
# protected visibility(accessibility to sub classes and operations of the class).
- private visibility (accessibility only to operations of the class).
Here, name is the name of the operation.
Parameter-list: is a list of parameters, seperated by commas, each specified by name: type-
expression = default value.
Return-type-expression: is a language-dependent specification of the implementation of the
value returned by the method? If return-type is omitted, the operation does not return a value.

Refinement of relationships:
A package groups and manages the modeling elements, such as classes, their
associations and their structures. Packages may be within other packages. A package may
contain both packages and ordinary model elements. The entire system description can be
thought of as a single high-level sub-system package with every thing else in it. All kinds of
UML model elements and diagrams can be organized into packages. Some packages may
contain groups of classes and their relationships, subsystems, or models. A package provides a
hierarchy of different system components and can reference other packages.

Relationships may be drawn between package symbols to show relationships between

at least some of the elements in the packages. In particular, dependency between packages
implies one or more dependencies among the elements.
 49
Packages Identified in E-Voting system are:

1) Database-info:

Classes grouped into this package:

E_Database_info, B_Use_Database

2) Check-database:

Classes grouped into this package:

C_Authenticate, C_Profile_modify

3) Election Process:

Classes grouped into this package:

E_Candidate, E_Administrator, C_View_Profile, C_Voting_info, C_Ballot_info,
B_Show_Profile, E_Voter

4) Election Report:

Classes grouped into this package:

B_Voting, C_Results, C_Ecommission

Package Relationships Identified in E-Voting system:

 50
18. AN OVERALL REFINED CLASS DIAGRAM

Refining of class diagram involves the following steps:

Apply design axioms to design classes, their Methods, methods, associations, structures, and
protocols.
1. Refine and complete the static UML class diagram by adding details to that diagram.
 Refine Methods.
 Design methods and the protocols by utilizing a UML activity diagram to represent the
method’s algorithm.
 Refine the associations between classes (if required).
 Refine the class hierarchy and design with inheritance (if required).
2. Iterate and refine.

The overall refined class diagram of our system is as follows:

 51
19. THE COMPONENT DIAGRAM

Component diagrams are created to show components that are the physical
implementation of the system. The component diagram shows the organization and
dependencies among a set of components of the system. The UML notation for a component is
as shown bellow:

Component
Name

Fig: UML notation for a Component

The Component diagrams are essentially class diagrams that focus on system’s
components. These are not only important for visualizing, specifying and documenting
component based systems but also for constructing executable systems through forward and
reverse engineering.

The components identified in the e-voting system are:

1) Authenticate: Represents the source code component for software files c_authenticate and
profile_modify.

2) Profile_manip: Represents the source code component for software file C_Profile_modify.

3) Databse_info: Represents the source code component for software files E-database_info and
b_use _database.

4) Voting_info: Represents the source code component for software files E-candidate, E-
Administrator, c_view_ profile, c_voting_info, c_ballot_info, B_show_
profile, E_voter.

5) Ecommission: represents the source code component for software files B_voting, C_results,
C_Ecommission.

6) Secure_ballot: Represents the source code component for software file C_Ballot_info.
Results
 52
The Component diagram of E-Voting system is as follows:
 53
20. THE DEPOLYMENT DIAGRAM

Deployment diagrams are created to show the hardware configuration that is used for
the system under the deployment view. The deployment view of architecture involves mapping
software to processing nodes. It shows the configuration of run-time processing elements and
the software processes living on them.

Deployment diagrams shows different nodes along with their connection in the
system and visualizes the distribution of components across the enterprise. Run-time
processing elements are represented as nodes, which are connected by associations indicating
communication paths between them. Software processes are illustrated as text attached to a
node or group of nodes.

This diagram allows the architecture team to understand the system topology and aids
in mapping components to executable processes.

The UML notation for the Processor and the Device is as follows:

Processor Device

The Processor Nodes identified in E-Voting system are:

1) Authentication and security server: Check the authorization of the Voter and secures the
Vote casted by the voter.
2) Database server: Maintains all updated Data regarding to the Voting System.
3) Voting Server: Counts the votes, generate the Results and sends to output devices.

The Device nodes identified in the E-Voting system are:

1) Voting Device: Allows the voter to cast the vote and view the profile of the candidate.
2) Printing Device: Prints the acknowledgement receipt to the voter for his/her vote.
3) Counting Device: Counts the ballots polled.
4) Display Device: Displays the results.
 54

The Deployment diagram of E-Voting system is as follows: