Sie sind auf Seite 1von 67

ADAMA SCINCE AND TECHNOLOGY UNIVERSITY

DEPARTEMENT OF IT



INFORMATION SYSTEMS ENGINEERING STREAM


INFORMATION SYSTEM DEVELOPMENT ( #)
PROJECT TITLE: ON LINE-ELECTION/ONLINE VOTING
Group member ID
1, YARED ESHETU R/3592/01
2, YASIN YIMER R/3600/01
3, YILIKAL YESHEWAS R/3646/01
4, YIBELTAL AIMERO R/3633/01

SUBMITTED TO: TINSAE

MAY 26/2012
GINBOT 2004



Electronic Voting
1.Introduction

Voting is a process at the heart oI a democratic society. Voting schemes have evolved Iro
m counting hands in early days, to systems that include paper, punch card, mechanical lever, and
optical-scan machines. Internet census takes precautions to prevent people Irom stuIIing the ball
ot box; they generally do so at the expense oI voter privacy. Recent democratic elections using v
oting machines have shown that the winning margins could be less than the error margins oI the
voting systems themselves, making election an error prone task. Electronic voting systems provi
de some characteristic over traditional voting technique.

Formerly when elections were made traditionally, organizers determine who is eligible to vote.
This may involve a Iormal registration period or an announcement that anyone who is a member
oI a certain group as oI a certain time may vote. Once the election begins, administrators may val
idate the credentials oI those attempting to vote. This way could involve asking voters Ior identiIi
cation cards or passwords. Generally, this procedure also involves keeping track oI who has alrea
dy voted so that eligible voters may vote only once. Moreover, the traditional way oI voting gene
rates mores constraints; election Iraud could be prevented by using physical security measures, a
udit trails, and observers representing oI all parties involved. But the prevention oI election Iraud
is made more diIIicult by the Irequent requirement that votes remain private . Contrarily to the tr
aditional way oI voting, electronic voting is essential because it considers ways in which the polli
ng tasks can be perIormed electronically without sacriIicing voter privacy or introducing opportu
nities Ior Iraud. In order to determine whether a system perIorms these tasks well, it is useIul to d
evelop a set oI criteria Ior evaluating system perIormance. The criteria to be developed are such
as accuracy, democracy, convenience, Ilexibility, privacy, veriIiability and mobility .
The aim oI this paper is to develop a general prototype system that provides security and trusted
electronic voting system.
electronic voting (also known as e-voting) is a term encompassing several diIIerent types oI ,
voting,embracing both electronic means oI casting a vote and electronic means oI counting vote



Electronic voting technology can include punchedcards,opticalscanvotingsystems and specialize
d voting kiosks (including selI-contained direct-recordingelectronicvoting
systems or DRE). It can also involve transmission oI ballots and votes via telephones, private co
mputer networks, or the Internet.
An electronic voting system (on-line voting, internet voting) is an election system which uses
electronic ballot that would allow voters to transmit their secure and secret voted ballot to electi
on oIIicials over the internet . With the prosperity oI internet over the years, inventers start to ma
ke the use oI electronic voting in order to make the voting process more convenient and raise the
participation oI the civic. From now on, engineers have repeatedly created new technology to im
prove the Ieasibility oI electronic voting system
To some people, the use oI technology will solve all the problems, while others
realized that elections could only be improved with technology. Elections are unlike any
other transactional event. The result oI a national election can have so much at stake,
Irom money, power, to dreams or even lives. While technology can improve our election
process, there needs to also exist an improvement in election policy. The policy
improvements will help bridge the gap where technology will Iall short.
1.1 Statement of the Problem

Making the electronic voting system has a security and conIidence system by the user, usually
user can access to the electronic voting system and voting on the text without security system, th
at any user can access to the electronic
Voting system through the ID number Ior another user and he/she can vote more than one time a
t the same text, The Users could know the result oI voting during the process oI voting which ma
ke the system dicey and mistrust.

The user can dominate the result oI voting by the access that he or she has oI the result beIore the
end oI Election Day. As it stands no election are held electronically.This means that there is a gr
eat cost associated wit collecting and counting votes, since many people must be hired to



perIorm and check the tasks Manual election takes a long time to set up and occurrences such as
recounts can greatly delay the reporting oI results. All oI these time delays can be at least partiall
y eliminated by having computers run Elections.
There are also many problems related to the accuracy oI manual elections. The intentional inaccu
racies introduced by the corruption oI election oIIicials can be eliminated by having the election
handled by an entirely impartial computer.The unintentional inaccuracies oI manual elections, su
ch as improperly printed or Iilled out balloons, can also be eliminated by electronic elections whi
ch use clear and consistent interIaces.It should be noted that although electronic elections have a
great number oI advantages, they are largely untested and even the best systems may be prone to
the problems, at least initially.Although they can certainly be designed with Iull security and priv
acy Ieatures, corruptions oI the results can be very diIIicult to detect iI someone does manage to
break through the security oI the soItware .the privacy Ieature oI the soItware means that what th
e soItware is actually doing during an election cannot be transparent to election oIIicials. One mu
st also be very careIul that security holes are not built into the elections soItware by the develope
rs and that the oIIicials who run and maintain the election do not have the power to corrupt
results.



1.2 Objectives
1.2.1 Specific objective
Any organization running an electronic election will want soItware that is easy to design and th
ey must be Ilexible as to the number and types oI questions .the election server must run eIIicient
ly and securely. It must be impossible Ior any one to break into the system and corrupt the result
s oI the election ,vote when they are not authorized to do so or vote more than once. The results o
I the election must be clearly presented upon the completion oI the election.Voters need the ballo



ts to be clear and easy to Iill out and answer .it is important that it be impossible Ior anyone to as
sociate a voters name with his or her vote.
1.2.2 General Objective
To develop a general prototype system that provides security and trusted electronic voting.
This speciIication design document will detail the design oI an electronic voting system
Ior the state oI once country. This electronic voting system will enable an eligible voter to vote at
any polling site statewide during an election period

Scope of Study
The scope oI the project is that it will use the Password oI the user as the main security to the
votes system.Our project may have a limitation when we implement the system because the docu
mentation Iocuses on the proper system analysis steps.

SIGNIFICANT OF STUDY

The using oI electronic voting has the potential to reduce or remove unwanted human errors. In
addition to its reliability, e-voting can handle multiple modalities, and provide better scalability I
or large elections. E-Voting is also an excellent mechanism that does not require geographical pr
oximity oI the voters. For example, soldiers abroad can participate in elections by voting online.

1.3 , Project Title: E-election/E-voting

1.4, Feasibility Study

In order Ior this electronic voting scheme to be successIul, in addition to carrying out the
basic election tasks, it must also be as easy to use as the current voting schemes. II the
proposed scheme is a drastic change Irom what voters are used to, they may be deterred
and reIrain Irom voting. Keeping this in mind, this group chose to concentrate on the
systems usability rather than its eIIiciency. This is not to say that the system should be



considered ineIIicient, but there are some aspects that can be implemented in a manner
that may be considered more eIIicient. The reason that we chose our particular design is
that our system strives to provide a positive voting experience. Another issue that was encounted
was that oI receipt-Ireeness vs. veriIiability.
when trying to decide between the two, we originally Iocused on ensuring that the voter had
some way oI knowing that his vote counted. However, devising a secure scheme such
that this was possible was very diIIicult, so we Iocused on implementing the idea oI
receipt-Ireeness. It is important to note that although our system provides the voter with a
voter token once they have completed the voting process, this token does not invite
corruption as do receipts by introducing avenues Ior vote selling/buying, coercion, or Iraud.


1.5 METHODOLOGY

1.5.1 System Development

The Design is implemented in this phase. The techniques Ior implementation will oI course vary
depending on the artiIact to be constructed. This project is web based system which detailed requ
irements and suggestion are already looked into in the previous stages. At this stage the system w
ill be implemented based on the Rapid Application Development (RAD) liIe cycle neral Method
ology oI Design Research will be used because it emphasizes the knowledge generation inherent
in the method and because it originated in an analysis oI the processes inherent in any design eII
ort.
The methodology consists oI the Iollowing phases:
a) Awareness oI Problem
b) Suggestion








a) Awareness of Problem
The Iirst stage oI this method is the understanding oI the problem which needs to be solved, a
s well as the objective and the scope oI this study. This project is aimed at developing a secured e
lectronic voting system which will prevent casting oI votes twice and also disallow people who a
re not right persons to vote Irom casting votes.
ThereIore the awareness oI the problem in E-voting has been reviewed Irom sources like books,
proceedings, journals, white papers, reports, and news in order to gather and collect the inIormati
on related to this project. AIter the problems are identiIied, the objectives and signiIicance oI the
study are deIined clearly aIter that. In completing this phase, the output oI this phase is a proposa
l Ior a new research eIIort.

b) Suggestion
To oIIer a meaningIul suggestion on the approach to Iollow in the design oI this project, several
alternatives are examined and discussed. There are many approaches to the problem oI this proje
ct, which are discussed over a period oI months. During the alternating cycles oI discussion and i
ndividual cogitation that characterize many Design research eIIorts, several soItware engineering
concepts were brought together with a Iinal key insight to yield the ultimately successIul directi
on Ior the development. Accordingly design speciIication is used as a blueprint Ior the implemen
tation oI the system.

1.5.2 Data Collection
In our project we are seen diffrent documentation and litrature review and existing
sites that support on line voting.











1.5.3 DEVELOPEMENT ENVIROMENT AND PROGRAMMING TOOLS

Development Environment
a) User design
User design is also known as the Iunctional design stage, this stage uses workshops to model the
systems data and processes and to build a working prototype oI critical system components. Proj
ect planning involves deIining clear, discrete activities, and the work needed to complete each ac
tivity within a single project. There are various activities that must be perIormed during Iunction
al design stage.

b) Construction

Construction in RAD starts when the process oI designing the interIace and developing the syste
ms is implemented. In this process, the system is designed according to the requirement and the o
bjectives.

c) Implementation
The Iinal stage in this approach is the implementation phase. In this phase, user is encouraged to
use the system. The new system is transIer to a working environment. This experiment is importa
nt and crucial since the eIIiciency and the Iunctionality oI the system can be tested in this phase.
Any error with the system can be corrected once the system is being use by the user. Minimal ins
tructions oI the system also will be given to the
User so that the user can understand the system easily .It is also at this stage that documentation i
s done in order to put into writing all stages oI how the system works. User by reading such docu
ment should be able to use the system comIortably.
Programming Tools
Based on the design principles that have been suggested in the previous phase, a planning require
ment oI the system was built. The prototype oI the system is developed in a web-based environm
ent. BeIore developing the prototype oI the system, the Iollowing soItware had been chosen as th
e development tools:




a) Microsoft internet browser:
as a web browser to launch the prototype.
b) sql database:
To well design sql has been selected Ior prototype electronic voting .sql is an open source relatio
nal database management system that uses structured query language. InIormation is stored in "ta
bles" which can be thought oI as the equivalent oI excel spreadsheets. A single sql database can c
ontain many tables at once and store thousands oI individual records. Its Iast, reliable and Ilexi
ble. Php and sql work extremely well together.

C ), C#(Visual studio)

1.6 Work Break down Structure, Coordination and Deliverable

Work Break down Structure
The development team will provide operational activities to highlights the major Iunctionality to
be delivered in the system .These activities can be used to validate the Iunctionality oI the syste
m .it is expected that more activities will be added and that the detailed oI existing Iunctionalities
will be Iilled in as the projects scope is better realize.
Election oIIicer creates a new election, code reviews, Database, Development team, election edit
or, Authorize voter


WBS INDEX COORDINATION
ASSIGNMENT TABLE
(CAT)
PRODUCT DELIVERABLES
PROJECT# 1
TITLE: ON LINE VOTING SYSTEM
WBS#1 LEVEL TASK TITLE





1

1.1


1.1.2

1.2

1.2.1

1.2.2
1.2.3
1.2.4
1.2.5
2
2.1
2.2


0

1

2


3

2

3

3
3
3
3
2
2
2

ON LINE VOTING SYSTEM

Object oriented Analysis

Application requirement
definition

User requirement
definition
Application requirement
analysis
Use case modeling

Sequence diagramming
Class diagramming
Activity diagramming

User interface prototyping
Class type architecture
Design class diagramming
Component diagramming


Yared ,yilikal

yibeltal


Yasin
Yared,Yasin
Yasin


Yared,yilikal
Yasin
Yibeltal

Yared,yasin,yilikal,yibeltal
Yasin
Yasin,Yared
yilikal








Documentation of user
requirement


Use case diagram and
description
Sequence diagram
Class diagram
Activity diagram
User interface prototype


Class type architecture
Design class diagram
Component diagram










Deliverable of the System

It is the development teams hope that this document will be the Iirst part oI continuing series oI
interchanges between the system and the voter. This will ensure that voters needs are met in a
cheap and timely Iashion. It will be important to involve potential Election OIIicers and Voters i
n this Ieedback process, as end users such as they oIten have many unique insights that might not
occur to soItware developers.
The advocate oI electronic voting claims that the convenience, mobility, tally speed, less cost, a
nd Ilexibility are the main advantages. Following are the descriptions oI the advantages.
Convenience: With the well-designed soItware and system, the voters can simply use his voting
equipment with the minimal time and skill to Iinish the voting process.

Mobility: Voters can cast their votes at a speciIic polling place, home, or any place in which the
y can get access to the internet. People can even use the mobile device such as cell phone or PD
A to vote. There is no restriction on the location
Tally Speed: Once the voting time is over, the computer can immediately calculate the result oI
the election. It is much Iaster than the traditional ballot counting method operated by people.
Less Cost: Compared to paper ballot voting, electronic voting saves money Irom reducing the p
ersonnel expense, expense Ior location management and administration Iee, etc. In the beginning,
the investment expense oI building up the electronic voting system would be very high. But aIte
r the system is built up, the total expense would be reduced to be much lower than paper ballot v
oting.
Flexibility: Electronic voting system can be designed to support a variety oI ballot question Ior
mats. It can be used to collect public opinions or election.
Voter participation: With convenience and mobility oI the system, it would motivate people wh
o are not interested in voting or unable to vote originally. It would increase the participation oI v
oters.







2. REQUIREMENT DEFINITION
The Requirement DeIinition must:
a provide a general description oI what the user wants to perIorm with the soItware syste
m ;
a contain all the known user requirements ;
a describe the operations the user wants to perIorm with the soItware system ;
a deIine all the constraints that the user wishes to impose on any solution;
the size and content oI the URD should reIlect the complexity oI the problem and the deg
ree oI expertise and understanding shared by the initiator, users, URD author and soItwar
e developer. The URD needs to state the problem as completely and accurately as possib
le. The cost oI changing the user requirements increases rapidly as the project proceeds
through the liIe cycle.The URD should be a balanced statement oI the problem and shoul
d avoid over-constraining the solution.
2.1 INTRODUCTION
The UR phase can be called the concept' or problem deIinition phase oI the liIe cycle. User req
uirements oIten Iollow directly Irom a spontaneous idea or thought. Even so, wide agreement an
understanding oI the user requirements is more likely iI these guidelines are applied.The deIiniti
on oI user requirements is an iterative process.User requirements are documented in the User Re
quirements Document . The URD gives the user's view oI the problem, not the
developer's. A URD may have to go through several revisions beIore it is
acceptable to every.
2.2 Essential Modeling
Essential modeling is intended to capture the essence oI problems through technology Iree, ideali
zed and abstract descriptions. They are more robust as they are more likely to remain valid in the
Iace oI both changing requirements and changes in the technology oI implementation. In short e
ssential models are ideal to capture the requirements Ior the new system (Ambler, 2001).
The artiIacts oI essential use case model are essential use case models, essential user



interIace prototype and domain models with Class Responsibility Collaborator (CRC).
2.2. 1. Essential Use case Modeling
Essential use case models reIlect the behavioral requirements oI the system to be d
eveloped (Ambler, 2001).
A. Actor Identification
An actor represents anything or anyone that interIaces with a system. This may include people, e
xternal systems, and other organizations and they are always external to the system being modele
d (Ambler, 2001)
Name: - Voter
Description: - who participate in the election by casting his/her vote.
Name:- Candidate .
Description: - who participate in election by contesting in it.
Name:Administrator
Description:The person who takes care oI conducting the election by declaring the election by de
claring the election details and declaring the results.
Name: -Election Database:
Description: External resource used by the system Ior voter identiIication and proIile manipul
ation operation.
Name: Election Commission:
Description: -system that maintains the election database and get beneIit Irom the e-voting proce
ss.





B. Use Case Identification.
A use case describes a sequence oI actions that provide a measurable value to an actor. In other
words, it shows a way in which a real world actor interacts with the system (Ambler, 2001).
An essential use case is a simpliIied, abstract, generalized use case that captures the intentions oI
the user in a technology and implementation independent manner (Constantine and Lockwood, 1
999).
In order to identiIy use cases the team examined the needs oI users , the main tasks oI users, the i
nIormation users needs to examine, create or change , what users inIorm the system and what the
system inIorms users .Here are those use cases identiIied.
C. Use Case Diagram











D. Descriptions of Use Cases.
1.Use Case SpeciIication Ior the Authentication system use case:
1.0 use Case Name
Authentication System
BrieI Description
The voter starts this use case .It provides the capablity Ior the system to perIorm on-line
identiIication oI the voters.
2.0 Flow oI Events
2.1 Basic Flow
This use case begins when the voter logs in to the identiIication system and enters his/her p
assword.The system verIies that the voter ID and the password is valid(iI they are invalid alterna
tive Ilow 2.2.1is executed).to perIormthis validation it will pass a report to the adminstrator
2.2 alternate Ilows
2.2.1 invalid voter ID
an invalid voter ID is entered.the user can re-enter his/her password 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 usec
ase.
3.0 Special Requirments
to perIorm voter identiIication 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:

Use Case Name

View profile

1.1 BrieI Description
This use case is started by the Authentication system use case and access by the voter. It allo
ws voter to see the candidate proIile and also to get know about his vote is polled/co
unted Ior selec-td candidate or not with some conIormation receipt to voter.
2.0 Flow oI Events
2.1 Basic Flow
This Use Case begins aIter the voter was authenticated and shows the proIile oI him/herse
lI orthe candidate
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 c
ase.
2.2.2 Invalid Password
An invalid password is entered. The user can re-enter his/her Password or termin
ate the use case.
3.0 Special Requirements
To perIorm voter identiIication 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.
There are no extension points.
4. Use Case Specification for the Report Use Case:
1.0 Use Case Name
Report
1.1 BrieI Description
This use case is started by the Voting system use case, It provides the report oI voter's ballot t
o the administrator and voter.
2.0 Flow oI Events
2.1 Basic Flow
This Use Case begins when the voting system noted the voter's ballot and other inIo
rmation about the voter, and sends a report to both the voter and administrator.
2.2 Alternate Flows
There are no alternate Ilows.
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
ProIile Manipulation
1.1 BrieI Description
The Administrator starts this use case.
It provides theCapabil ity to the system to process theproIiles oI voters and the
candidates.The processing here includes creation, modiIication anddeletion process.



2.0 Flow oI Events

2.1 Basic Flow
The Use Case begins when the administrator initiated the manipulation process oI proIile. Itmake
s use oI the election database Ior its operation.
2.2 Alternate Flows
There are no alternate Ilows.
3.0 Special Requirements
This use case requires the external election database Ior its operation.11
4.0 Pre-conditions
The election database must be the updated one, beIore 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 BrieI Description
The Administrator starts this use case. It provides the capability Ior the system
to process theballot inIormation and make i t secured. It passes the encrypted
secured ballot inIormation tothe results use case where counting will takes place.
2.0 Flow oI Events2.1 Basic Flow
This Use Case begins when the Administrator passed the ballot inIormation to this use case.
2.2 Alternate Flows
There are no alternative Ilows.
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.
7. Use Case Specification for the Results Use Case:
1.0 Use Case Name
Results
1.1 BrieI Description
This use case is started by the Ballot secrecy use case, it provides the capability to the syste
m to perIorm the counting oI ballots polled Ior each candidate and announces the electio
n results to the election commission.
2.0 Flow oI Events


2.1 Basic Flow
The Use Case begins when the ballot secrecy use case sends the secured ballot inIormatio
n to this use case.
2.2 Alternate Flows
There are no alternate Ilows.
3.0 Special Requirements
There are no special requirements.
4.0 Pre-conditions
Ballot inIormation should be secured beIore the counting.
5.0 Post Conditions
Must pass the results inIormation to the election commission
6.0 Extension Points
There are no extension points

8. Use Case Specification for the Database manipulation Use Case:
1.0 Use Case Name
Database Manipulation
1.1 BrieI Description



The Administrator starts this use case. It provides the capability to the Administrator to cr
eate and manipulate the election database in which the voter's proIiles are stored.
2.0 Flow oI Events
2.1 Basic Flow
The Us e Cas e begi ns when t he Admi ni s t r at or i ni t i at ed i t or t r i es t o
mani pul at e t he el ect i on database.
2.2 Alternate Flows
There are no alternate Ilows.
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.















2.2.1. FUNCTIONAL REQUIREMENTS:
Following are some oI the Iunctional requirements oI the Proposed Online Voting System
System will take as input Parties inIormation that is names oI parties, there symbol, etc.
System will take as input Candidate inIormation i.e. name, province, his qualiIication e
System will take as input Seats inIormation that is region voice seats allocations.
System will take as input Voters inIormation that is permanent address, all other inIorm
ation along with their thumb print etc.
System will take as input union council details i.e. Region, district and province in which
it lies.
System will do online vote polling.
System will take as input Candidates inIormation that is password, qualiIication, age .gen
der, permanent address, etc. System will generates result oI each polling station.
System will do voter registration.
Result compilation i.e. correct result will be generated.
Vote ineligibility i.e. not more than one time a voter can poll vote.
Vote counting i.e. polling stations voice result calculation and overall result calculation.
Symbol assignment process every party should have a symbol.
Correct Iilling oI Iorms.
System must authenticate user
Election results region voice.
Election results party voice.
Trend analysis oI polling.
Overall results.
List oI candidates.
ELECTION COMMISION can change the inIormation any time iI required.
Registration oI the Voter depends upon the inIormation Iilled by the user.
Voter is given a unique ID and PASSWORD.
Voter can give vote aIter login and entering the ID and PASSWORD.
In the DATABASE inIormation oI every voter is stored.
Database shows the inIormation oI every user.



2.2.1 NON-FUNCTIONAL REQUIREMENTS:
The non Iunctional requirement oI the proposed system will
be:
The soItware will be user Iriendly.
It will have the standard graphical user interIace.
Security oI data.
Ensure system development and coding is well documented Ior Iuture use
Performance Requirements
The system is expected to have reasonable short time response. The voter should be
able to login and should be able to get response Ior his requests.
Security Requirements
The data transaction between client and server must be encrypted using SSL technolo
gy.
All the passwords that are generated or accepted must be stored in database in an enc
rypted Iorm.
Safety Requirements
To prevent data loss in case oI system Iailure, the result oI votes that are polled til
l then have to be saved in database.
Reliability
2.3 Essential User Interface prototyping
The user interIace (UI) is a portion oI soItware with which the user directly interacts.
An essential user interIace prototype is a low Iidelity model, or prototype oI the UI Ior the syste
m. It represents the general idea behind the UI requirements in a technology independent manner
(Ambler, 2001).
An essential user interIace helps the team to model the major UI elements like screens, reports
and minor UI elements such as, input Iields and lists







3,Object Oriented Analysis:
3.1. Introduction
Object-oriented analysis (OOA) is the process oI analyzing a task (also known as a problem dom
ain), to develop a conceptual model that can then be used to complete the task. A typical OOA m
odel would describe computer soItware that could be used to satisIy a set oI customer-deIined re
quirements. During the analysis phase oI problem-solving, a programmer might consider a writte
n requirements statement, a Iormal vision document, or interviews with stakeholders or other inte
rested parties. The task to be addressed might be divided into several subtasks (or domains), each
representing a diIIerent business, technological, or other areas oI interest. Each subtask would b
e analyzed separately. Implementation constraints, (e.g., concurrency, distribution, persistence, o
r how the system is to be built) are not considered during the analysis phase; rather, they are addr
essed during object-oriented design (OOD).
The conceptual model that results Irom OOA will typically consist oI a set oI use cases, one or m
ore UML class diagrams, and a number oI interaction diagrams. It may also include some kind oI
user interIace mock-up

3.2. System Use Case
A system use case model constitutes a sequence oI actions that provide a measure to an actor. Th
e main diIIerence between an essential use case and a system use case is a high level oI impleme
ntation decision is included in the system use case (Ambler, 2001).








3.2.1. UI Identification
1.UI1 System Login Screen.
2. UI2 Invalid Login Screen.
3. UI3 Main Menu Screen.
4. UI4 Candidate Login Screen.
5. UI5 Voting Candidate Screen.
6. UI6 Invalid Voting Candidate screen.
7. UI7 Create Candidate ProIile Screen.
8. UI8 View Candidate ProIile Screen.
9. UI9 Administrator Login screen.
10. UI10 Result View Screen
11. UI11 Update database Screen.
3.2.2. Actors IdentiIication
Identification of Actors
1.Voter:A member oI the country who participate in the election by casting his/her vote.

2.Candidate:A member oI the country who participate in election by contesting in it.




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

4. Election Database: External resource used by the system Ior voter identiIication and
proIile manipulation operation.



5.Election Commission: system that maintains the election database and get beneIit Irom the
e-voting process.


3.2.3 Identification of use Cases
In its simplest Iorm a use case can be described as a speciIic way oI using the system Irom
a user`s perspective .
A more detailed description might characterized a use case as:
A pattern oI behaviour the system exhibits
A sequence oI related transaction perIormed by an actor and the system
Delivering something oI value to the actor.




Use case provided a mean to:
1. Capture system requirement
2. Communicate with the end users and domain experts
3. Test the systems
Use cases are the best discovered examining the actors and deIining what the actor will be
able to do with the system. Since all need oI the system typically can not be covered in one u
se case,it is usual to have a collection oI use cases .together this use case collection speciIies
all ways oI the system.
Use cases identified are:
1. Authentication system: It veriIies the voter s authorization based on the voterID and
password.
2. View profile: It allows the Authorized voter to see the candidate his/her proIile and get know
about this vote that is polled Ior selected candidate with a conIirmation receipt to voter.
3. Voting system : It will process the voter`s ballot.
4. Profile Manipulation: It will process the proIile oI voters and candidates that includes the
certain,modiIication and deletion process.
5. Ballot Secrecy: It Makes the ballot inIormation secured and passes the encrypted secured
ballot inIormation to the results use case.
6. Results: perIorms the counting oI ballots polled Ior each candidate and announce the Election
results to the Election Commission.
7. Database manipulation: perIorms creation and manipulation oI the database







3.2.4.DESIGNING THE SYSTEM USE CASE DIAGRAMS
Use case diagrams depict system behavior (use cases). These diagrams present a highlevel
view oI how the system is used as viewed Irom an outsider`s (actor`s) perspective. A usecase dia
gram may depict all or some oI the use cases oI a system. A use-case diagram can contain:
Actors (things outside the system)
Use case (system boundaries identiIying what the system should do)
I nt er act i ons or r el at i ons hi ps bet ween act or s and us e c as e i n t he s ys t em
i ncl udi ng t he associations, dependencies, and generalizations.
Uses associations
The uses association occurs when we are describing our use cases and notice that so
me oI them have sub Ilows in common to avoid describing a sub Il ow more than onc
e in several use cases, you can extract the common sub Ilow and make it a use case oI its own. T
his new use case then can be used by other use cases. The relationships among the other use case
s and this new extracted use case are called uses association.
Extends association
An extends t h e Iunctionality oI one use case can be inserted in to the Iunctionality oI another u
se case. Extend relationships between use cases are modeled as dependency by using the extend s
tereotype.
Includes association
An association is a stereo typed association that connects a base use case toan inclusion use c
ase.
















The main use case Diagram oI E-Voting












3.2.5 USE CASE DESCRIPTION
FLOW OF EJEA1S
A Ilow oI events is a sequence oI transaction perIormed by the system .They typically c
ontain very detailed inIormation ,written in terms oI what the system should do not how the
system accompl-ishes the task. Flow oI events are created as separate Iiles or documents in y
our Iavourite text editor and then attached or linked to a use case using the Iiles tab oI a mo
del 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 oI events Ior the use case
Alternate or exceptional Ilows
Flow of Events in E-Voting system:
1.Use Case SpeciIication Ior the Authentication system use case:
1.0 use Case Name
Authentication System
BrieI Description
The voter starts this use case .It provides the capablity Ior the system to perIorm on-line
identiIication oI the voters.
2.0 Flow oI Events
2.1 Basic Flow



This use case begins when the voter logs in to the identiIication system and enters his/her p
assword.The system verIies that the voter ID and the password is valid(iI they are invalid alterna
tive Ilow 2.2.1is executed).to perIormthis validation it will pass a report to the adminstrator
2.2 alternate Ilows
2.2.1 invalid voter ID
an invalid voter ID is entered.the user can re-enter his/her password 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 usec
ase.
3.0 Special Requirments
to perIorm voter identiIication 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:

Use Case Name

View proIile




1.1 BrieI Description
This use case is started by the Authentication system use case and access by the voter. It allo
ws voter to see the candidate proIile and also to get know about his vote is polled/co
unted Ior selec-td candidate or not with some conIormation receipt to voter.
2.0 Flow oI Events
2.1 Basic Flow
This Use Case begins aIter the voter was authenticated and shows the proIile oI him/herse
lI orthe candidate
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 termin
ate the use case.
3.0 Special Requirements
To perIorm voter identiIication 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.
There are no extension points.
4. Use Case Specification for the Report Use Case:
1.0 Use Case Name
Report
1.1 BrieI Description
This use case is started by the Voting system use case, It provides the report oI voter's ballot to
the administrator and voter.
2.0 Flow oI Events



2.1 Basic Flow
This Use Case begins when the voting system noted the voter's ballot and other inIo
rmation about the voter, and sends a report to both the voter and administrator.
2.2 Alternate Flows
There are no alternate Ilows.
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
ProIile Manipulation
1.1 BrieI Description
The Administrator starts this use case.
It provides theCapability to the system to pr ocess theproIiles oI voters and the
candidates.The processing here includes creation, modiIication anddeletion process.
2.0 Flow oI Events

2.1 Basic Flow
The Use Case begins when the administrator initiated the manipulation process oI proIile. Itmake
s use oI the election database Ior its operation.
2.2 Alternate Flows
There are no alternate Ilows.
3.0 Special Requirements
This use case requires the external election database Ior its operation.11
4.0 Pre-conditions



The election database must be the updated one, beIore 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 BrieI Description
The Administrator starts this use case. It provides the capability Ior the system
to process theballot inIormation and make it secured. It passes the encrypted
secured ballot inIormation tothe results use case where counting will takes place.
2.0 Flow oI Events2.1 Basic Flow
This Use Case begins when the Administrator passed the ballot inIormation to this use case.
2.2 Alternate Flows
There are no alternative Ilows.
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.
7. Use Case Specification for the Results Use Case:
1.0 Use Case Name
Results
1.1 BrieI Description



This use case is started by the Ballot secrecy use case, it provides the capability to the system
to perIorm the counting oI ballots polled Ior each candidate and announces the election results to
the election commission.
2.0 Flow oI Events


2.1 Basic Flow
The Use Case begins when the ballot secrecy use case sends the secured ballot inIormatio
n to this use case.
2.2 Alternate Flows
There are no alternate Ilows.
3.0 Special Requirements
There are no special requirements.
4.0 Pre-conditions
Ballot inIormation should be secured beIore the counting.
5.0 Post Conditions
Must pass the results inIormation to the election commission
6.0 Extension Points
There are no extension points
8. Use Case Specification for the Database manipulation Use Case:
1.0 Use Case Name
Database Manipulation
1.1 BrieI 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 proIiles are stored.
2.0 Flow oI Events
2.1 Basic Flow
The Us e Cas e begi ns when t he Admi ni s t r at or i ni t i at ed i t or t r i es t o
mani pul at e t he el ect i on database.
2.2 Alternate Flows



There are no alternate Ilows.
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.

3.3 CONSTRUCTION OF SEQUENCE DIAGRAM
A sequence diagram is a graphical view oI a scenario that shows object interaction ina time
-based sequence-what happens Iirst, what happens next. Sequence diagrams establish theroles
oI objects and help provide essential inIormation to determine class responsibilities andinterIaces
. A sequence diagram has two dimensions:the vertical dimension represents time; thehorizontal
dimension represents diIIerent objects. The vertical line is called the object`sliIeline. The liIeline
represents the object`s existence during the interaction. An object is shown as a box at the top oI
a dashed vertical line. Arole is a slot Ior an object within a collaboration that describes the type
oI object that may playthe role and its relationships to other roles.However, a sequence diagram
does not show therelationships among the roles or the association among the objects. An object r
ole is shown asa vertical dashed line, the liIeline.
Sequence diagrams Ior each uses case oI E-Voting system are as Iollows:









fig1 Sequence Diagram Ior Authentication system use Case Realization









2.fig2.Sequence Diagram Ior Ballot secrecy Use Case realization




















3.fig3,Sequence Diagram Ior View ProIile Use Case realization











4.Fig4 Sequence diagram for Profile Manipulation











5.,fig5,Sequence Diagram Ior Database manipulation(the above picture)
6. fig6,Sequence Diagram Ior Result Use Case realization





7-fig7 Sequence diagram Ior voting system Use case realization















3.4 ACTIVITY DIAGRAM
Activity diagrams provide a way to model the workIlow oI a business process. An
activity diagram is typically used Ior modeling the sequence oI Activities in a process. Activity
di agr ams can model many di I I er ent t ypes oI wor kI l ows . The Iollowing tools
are used onthe activity diagram toolbox to model activity diagrams.
Decisions: A deci s i on r epr es ent s a s peci I i c l ocat i on on act i vi t y di agr a
m when t he workIlow may branch based upon guard conditions.
Synchronization:Synchr oni zat i on vi s ual l y deI i nes I or ks and j oi ns r epr es en
t i on parallel workIlow.
States:A state represents a condition or situation during the liIe oI an object duri
ng which it satisIies some condition or waits Ior some event.
Transitions:A state transition indicates that an object in the source state will perIormcertain
speciIied actions and enter the destination state when a speciIied event occurs or when certai
n conditions are satisIied.
Start States:A start state (also called an initial state) explicitly shows the beginningoI a work
Ilow.
End States:An end state represents a Iinal or terminal state.
Swim Lane:A uni que di agr am I eat u r e t hat deI i nes who or what i s r es pons
i bl e I or carrying out activity or state.
Work Flow:Each act i vi t y r epr es ent s t he per I or mance oI a gr oup oI
act i ons i n a workIlow.









3.5. Class Diagram
IDENTIFICATION OF ANALYSIS CLASSES
IdentiIication oI classes can be done by the noun phrase approach, the common class patterns ap
proach, the use-case driven sequence/collaboration modeling approach and the classes` respons
ibilities and collaborators (CRC) approach.
CLASSES RESPONSIBILITIES
This technique is used to identiIy the classes, responsibilities and thereIore their attributes and m
ethods. It is based on the idea that an object can either accomplish a certain responsibility by itsel
I or it may require the assistance oI other objects in which case it collaborates.Out oI these, the n
oun phrase is used to identiIy the classes to increase our understanding oI the subject.
The Final List oI Classes is:
Administrator
Authentication
Voter
Candidate
Data base inIormation
Election Commission
View proIile
Voting inIormation
ProIile ModiIication
Ballot inIormation
ResultsVoting system









3.6.1 Description of class diagram
IDENTIFY THE RESPOSIBILITIES OF CLASSES
Classes Responsibilities and Collaborators is a technique used Ior identiIying classes` responsibi
lities and their attributesand methods. They also help in identiIying the classes. Classes Resp
onsibilities and Collaborators is based on the idea that an object either can accomplish a certain r
esponsibility itselI or it may require the assistance oI other objects .II it requires the assistance oI
other objects, it must collaborate with those objects to IulIill its responsibility. By identiIying ano
bject`s responsibilities and collaborators attributes and methods can be identiIied.
The Classes, Responsibilities, and Collaborators process consists oI three steps:
1.IdentiIy classes` responsibilities (and identiIy classes)
2.Assign responsibilities
3.IdentiIy collaborators








Class Name And their Responsibilities
Class Name Responsiblity
Administrator Manipulates database and submits ballots
Authentication Checks the validity oI a voter
Voter Castes his vote and views candidate`s/his proIile
Candidate Creates nomination and submits it
DatabaseinIormation
Creation oI election database and proIiles oI voter andcandidates participat
ing in elections
Election commission
Declares the election result
View proIile
Shows the required proIile inIormation
Voting inIormation
Generates the ballot report
ProIile modiIication
Updates the selected proIile in the Election database
Ballot inIormation
Secures the ballot inIormation.
Results
.Counts the ballots

IDENTIFICATION OF ATTRIBUTESAND METHODS OF CLASSES
Guidelines Ior identiIying attributes oI classes are as Iollows:
Attributes usually correspond to nouns Iollowed by prepositional phrases. Attributesalso may
correspond to adjectives or adverbs.
Keep the class simple; State only enough attributes to deIine the object state.
Attributes are less likely to be Iully described in the problem statement.
Omit derived attributes.
do not carry discovery attributes to excess.
The attributes identiIied in E-Voting system are:



Attributes Ior Administrator class: VoterID, Ballot inIo.
Attributes Ior Authentication class: VoterID, Voter Password.
Attributes Ior Voter class: VoterID, Voter Password, and Voter Name.
Attributes Ior Candidate class: Party symbol, Constituency.
Attributes Ior Data base inIormation class: VoterID, Voter Name.
Attributes Ior Election Commission class: Ballot inIo.
Attributes Ior View proIile class: VoterID, Voter Name.
Attributes Ior Voting inIormation class: VoterID, Ballot Number, Vote polled.
Attributes Ior ProIile ModiIication class: VoterID, Voter Name, Address.
Attributes Ior Ballot inIormation class: Votes polled, Status oI votes.
Attributes Ior Results class: Votes polled, Party symbol, Constituency.
Attributes Ior Voting system class: VoterID, Voter Name, Ballot Number 39
The responsibilities identified in E-Voting system are:
Methods Ior Administrator class: Manipdatabse, submitreport.
Methods Ior Authentication class: CheckValidty.
Methods Ior Voter class: castevote, viewresult.
Methods Ior Candidate class: Createnomination, Submitnomination.
Methods Ior Data base inIormation class: CreateDB, CreateProIile.
Methods Ior Election Commission class: Declareresults.
Methods Ior View proIile class: Show proIile.
Methods Ior Voting inIormation class: Generatereportballot.



Methods Ior ProIile ModiIication class: Update proIile.
Methods Ior Ballot inIormation class: Secure ballot.
Methods Ior Results class: Count votes.
Methods Ior Voting system class: Sendreport.40






















4.OB1EC1 ORIEA1ED DESICA
4.1 Introduction
The purpose oI design is to determine how to build the system and to obtain inIormation needed t
o drive the actual implementation oI the system. The Iocus is particularly on the solution domain
rather than on the problem domain (Ambler, 2001).
Object oriented design consists oI transIorming the analysis model into the design model. It desc
ribes the system in terms oI its architecture, such as its subsystem decomposition, global control
Ilow and persistency management.
4.2. Class Type Architecture
Class type architecture provides a strategy Ior layering the classes oI the soItware to distribute th
e Iunctionality oI the soItware among classes. It provides guidance as to what other types oI class
es a given type oI class will interact with and how the interIace will occur .This increases the ext
ensibility, maintainability, and portability oI the system
(Ambler, 2001).
4.3 Class Modeling
4.3.1 Class diagram
IDENTIFICATION OF ANALYSIS CLASSES
IdentiIication oI classes can be done by the noun phrase approach, the common class patterns ap
proach, the use-case driven sequence/collaboration modeling approach and the classes` respons
ibilities and collaborators (CRC) approach.
CLASSES RESPONSIBILITIES
This technique is used to identiIy the classes, responsibilities and thereIore their attributes and m
ethods. It is based on the idea that an object can either accomplish a certain responsibility by itsel



I or it may require the assistance oI other objects in which case it collaborates.Out oI these, the n
oun phrase is used to identiIy the classes to increase our understanding oI the subject.
The Final List oI Classes is:
Administrator
Authentication
Voter
Candidate
Data base inIormation
Election Commission
View proIile
Voting inIormation
ProIile ModiIication
Ballot inIormation
ResultsVoting system






3.6.1 Description of class diagram



IDENTIFY THE RESPOSIBILITIES OF CLASSES
Classes Responsibilities and Collaborators is a technique used Ior identiIying classes` responsibi
lities and their attributesand methods. They also help in identiIying the classes. Classes Resp
onsibilities and Collaborators is based on the idea that an object either can accomplish a certain r
esponsibility itselI or it may require the assistance oI other objects .II it requires the assistance oI
other objects, it must collaborate with those objects to IulIill its responsibility. By identiIying ano
bject`s responsibilities and collaborators attributes and methods can be identiIied.
The Classes, Responsibilities, and Collaborators process consists oI three steps:
1.IdentiIy classes` responsibilities (and identiIy classes)
2.Assign responsibilities
3.IdentiIy collaborators

Class Name And their Responsibilities
Class Name Responsiblity
Administrator Manipulates database and submits ballots
Authentication Checks the validity oI a voter
Voter Castes his vote and views candidate`s/his proIile
Candidate Creates nomination and submits it
DatabaseinIormation
Creation oI election database and proIiles oI voter andcandidates participat
ing in elections
Election commission
Declares the election result
View proIile
Shows the required proIile inIormation
Voting inIormation
Generates the ballot report
ProIile modiIication
Updates the selected proIile in the Election database
Ballot inIormation
Secures the ballot inIormation.
Results
.Counts the ballots



4.3.2 Class Diagram Description
IDENTIFICATION OF ATTRIBUTESAND METHODS OF CLASSES
Guidelines Ior identiIying attributes oI classes are as Iollows:
Attributes usually correspond to nouns Iollowed by prepositional phrases. Attributesalso may
correspond to adjectives or adverbs.
Keep the class simple; State only enough attributes to deIine the object state.
Attributes are less likely to be Iully described in the problem statement.
Omit derived attributes.
do not carry discovery attributes to excess.
The attributes identiIied in E-Voting system are:
Attributes Ior Administrator class: VoterID, Ballot inIo.
Attributes Ior Authentication class: VoterID, Voter Password.
Attributes Ior Voter class: VoterID, Voter Password, and Voter Name.
Attributes Ior Candidate class: Party symbol, Constituency.
Attributes Ior Data base inIormation class: VoterID, Voter Name.
Attributes Ior Election Commission class: Ballot inIo.
Attributes Ior View proIile class: VoterID, Voter Name.
Attributes Ior Voting inIormation class: VoterID, Ballot Number, Vote polled.
Attributes Ior ProIile ModiIication class: VoterID, Voter Name, Address.
Attributes Ior Ballot inIormation class: Votes polled, Status oI votes.
Attributes Ior Results class: Votes polled, Party symbol, Constituency.



Attributes Ior Voting system class: VoterID, Voter Name, Ballot Number 39
The responsibilities identified in E-Voting system are:
Methods Ior Administrator class: Manipdatabse, submitreport.
Methods Ior Authentication class: CheckValidty.
Methods Ior Voter class: castevote, viewresult.
Methods Ior Candidate class: Createnomination, Submitnomination.
Methods Ior Data base inIormation class: CreateDB, CreateProIile.
Methods Ior Election Commission class: Declareresults.
Methods Ior View proIile class: Show proIile.
Methods Ior Voting inIormation class: Generatereportballot.
Methods Ior ProIile ModiIication class: Update proIile.
Methods Ior Ballot inIormation class: Secure ballot.
Methods Ior Results class: Count votes.
Methods Ior Voting system class: Sendreport.40









AN OVERALL REFINED CLASS DIAGRAM
ReIining oI class diagram involves the Iollowing steps:Apply design axioms to design classes, th
eir Methods, methods, associations, structures, and protocols.1. ReIine and complete the static U
ML class diagram by adding details to that diagram.
ReIine Methods.
Design methods and the protocols by utilizing a UML activity diagram to represent them
ethod`s algoritm.
ReIine the associations between classes (iI required).
ReIine the class hierarchy and design with inheritance (iI required).2. Iterate and reIine.












The overall reIined class diagram oI our system .(the above picture)





4.4. CONSTRUCTION OF UML STATE CHART DIAGRAM
State chart diagrams model the dynamic behavior oI individual classes or any other kind oI objec
t. They show the sequences oI states that an object goes through, the events that cause a transitio
n Irom one state to another and the actions that result Irom a state change. State chart diagrams ar
e closely related to activity diagrams
The main diIIerence between the two diagrams is state chart diagrams are state centric, wh
ile activity diagrams are activity centric. A state chart diagram is typically used to model the disc
rete stages oI an objects liIetime, whereas an activity diagram is better suited to model the sequ
ence oI activities in a process. Each state represents a named condition during the liIe oI an objec
t during which it satisIies some condition or waits Ior some event. A state chart diagram typically
contains one start state and multiple end states
Transitions connect the various states on the diagram. The Iollowing tools are used on the sta
te chart diagram toolbox to model state chart diagrams:
Decisions: A decision represents a speciIic location on state chart diagram where the workIlo
w may branch based upon guard conditions.
Synchronizations: Synchronizations visually deIine Iorks and joins representing parallel wor
kIlow.
Forks and Joins: A Iork construct is used to model a single Ilow oI control that divides into t
wo or more separate, but simultaneous Ilows. A join consists oI two oI more Ilows oI control
that unite into a single Ilow oI control.
States: A state represents a condition or situation during the liIe oI an object during which it s
atisIies some condition or waits Ior some event.
Transitions: A state transition indicates that an object in the source state will perIorm certain
speciIied actions and enter the destination state when a speciIied event occurs or when certai
n conditions are satisIied.
Start states: A start state (also called an "initial state") explicitly shows the beginning oI a wo
rkIlow
End States: An end state represents a Iinal or terminal state.



The state chart diagram Ior E-Voting system is as Iollows:






4.5. CONSTRUCTION OF COLLABORATION DIAGRAM
Collaboration diagram is an interaction diagram that shows the order oI messages that i mp l e m
e n t a n o p e r a t i o n o r a t r a n s a c t i o n . An o t h e r t y p e o I i n t e r a c t i o n d i a g
r a m i s t h e collaboration diagram. A collaboration diagram i s a s et oI obj e ct s r el a
t ed i n a par t i cul ar context, and interaction, which is a set oI messages exchanged
among the objects within the collaboration to achieve a desired outcome.







4.6.THE COMPONENT DIAGRAM
Component diagrams are created to show components that are the physical implementation oI the system.
The component diagram shows the organization and dependencies among a set oI components oI
the system. The UML notation Ior a component is as shown bellow:
The Component diagrams are essentially class diagrams that Iocus on systems components. The
se are not only important Ior visualizing, speciIying and documenting component based systems
but also Ior constructing executable systems through Iorward and reverse engineering. The comp
onents identiIied in the e-voting system are:
1) .Authenticate: Represents the source code component Ior soItware Iiles cauthenticate and pro
IilemodiIy.
2) ProIilemanip: Represents the source code component Ior soItware Iile CProIilemodiIy.
3) .DatabaseinIo: Represents the source code component Ior soItware Iiles E-databaseinIo and
buse database.



4) VotinginIo: Represents the source code component Ior soItware Iiles E-candidate, E-Admini
strator, cview proIile, cvotinginIo, cballotinIo, Bshow proIile, Evoter.
5) Ecommission: represents the source code component Ior soItware Iiles Bvoting, Cresults,
CEcommission.
6) Secureballot: Represents the source code component Ior soItware Iile CBallotinIo.


The component Diagram of E-Voting is as follows



4.7.THE DEPOLYMENT DIAGRAM
Deployment diagrams are created to show the hardware conIiguration that is used Ior the system under th
e deployment view. The deployment view oI architecture involves mapping soItware to processing nodes.
It shows the conIiguration oI run-time processing elements and the soItware processes living on them.



Deployment diagrams shows diIIerent nodes along with their connection in the system and visualizes the
distribution oI components across the enterprise. Run-time processing elements are represented as nodes,
which are connected by associations indicating communication paths between them. SoItware processes a
re illustrated as text attached to anode or group oI nodes.
This diagram allows the architecture team to understand the system topology and aids in mapping compo
nents to executable processes.


The Processor Nodes identified in E-Voting system are:
1) Authentication and security server: Check the authorization oI the Voter and secures theVote c
asted 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 proIile oI the candidate.
2) Printing Device: Prints the acknowledgement receipt to the voter Ior his/her vote.
3) Counting Device: Counts the ballots polled.
4) Display Device: Displays the result

The Deployment Diagram for E-Voting system are as follows :





CONSTRUCTION OF UML STATIC CLASS DIAGRAM
A class diagram is a picture Ior describing generic descriptions oI possible systems Class diagra
ms and collaboration diagrams are alternate representations oI object models. Class diagrams con
tain classes and object diagrams contain objects, but it is possible to mix classes and objects whe
n dealing with various kinds oI metadata, so the separation is not rigid. Class diagrams are more
prevalent than object diagrams. Normally you will build class diagrams plus occasional object di
agrams illustrating complicated data structures or message-passing structures. Class diagrams co
ntain icons representing classes, interIaces, and their relationships. We can create one or more cl
ass diagrams to depict the classes at the top level oI the current model; such class diagrams are th
emselves contained by the top level oI the current model. We can also create one or more class di
agrams to depict classes contained by each package in your model; such class diagrams are them
selves 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



speciIication or modiIying the icon on the diagram. The associated diagrams or speciIications are
automatically updated.
Classes may be oI 3 types. They are:
1. Entity class
2.Boundary class
3. Control class

Entity class: An entity class models inIormation and associated behavior that is generally long liv
e.
Boundary Class: They handle the communication between the systems. They can provide the inte
rIace to the user or another system. Ex: Registration Iorm.
Control Class: Control class model sequencing behavior speciIic to one or more use-cases. You c
an think oI control class as running or executing the use-case i.e., they represent the dynamics oI t
he use-case. Ex: Registration Manager
STEREOTYPES AND CLASSES:A Stereotype provides the capability to create a new kind o
I modeling element. Some common stereotypes Ior a class are Entity, Boundary, Control, Utility and Exc
eption. The stereotype Ior a class shown below the class name enclosed in guillemets . II desired, a grap
hic icon or a speciIic color may be associated with a stereotype.


















4.8 Persistence Modeling
4.9 User Interface Design
4.10 User Interface Flow Diagramming