Beruflich Dokumente
Kultur Dokumente
Group Project
1. System Specifications...................................................................................2
2. System Design and Architecture...................................................................3
3. Component Mining........................................................................................4
4. Component Selection....................................................................................9
5. Component Adaptation...............................................................................11
6. Component Integration...............................................................................12
7. Testing........................................................................................................12
8. System Evaluation, advantages and drawbacks........................................13
1. Introduction
Electronic Voting (e-Voting) systems have been in use since the 1960’s. By
the term e-Voting systems we refer to the combination of electronic
equipment, software, firmware, and documentation required to program,
control and support a system created for voting and generating the vote
results without the necessity of the traditional paper and ballot box layout.
E-Voting systems can be divided in three broad categories
• Punch card systems
In a punch card system voters have to punch holes on a card that plays the
role of the ballot using a supplied device. Afterwards their vote is fed into a
counting machine in order to produce the results. The first major success for
the punch card e-voting system came in 1965 with Joseph`s P.Harris
Votomatic, a punch card system developed based on the Port-A-Punch
technology by IBM.
The main advantage of this kind of systems is the low cost. But they come
with a serious disadvantage, especially for a voting procedure where integrity
and accuracy are crucial: if we fold, spindle or mutilate the card then there is
chance of losing the data. The same can happen as a result of a partially
punched card.
Optical scan voting systems working principle is similar to the punch card
systems but instead of reading punched ballots, they use optical scanner to
read marked paper. Varieties of optical scan systems are:
• Marksense systems. These systems use optical mark recognition
scanners. Voters have to fill a rectangle, circle or oval box to vote for
their candidate. By that mark scanners can recognise the votes. In
early days various mark sense voting systems have used in a variety of
approaches to count the votes. An example of this category is Votronic
which was introduced in 1965 and had a single photo sensor per
column of marks on the ballot.
• Digital pen voting systems. In this digital pen system we have a digital
paper which is recognized by a small camera in the pen.
Optical scan voting systems are a form of document ballot voting systems,
thus they share the same risks such as the common ballot stuffing. The main
advantage of the optical scan voting systems is their simplicity of use. Voters
don’t need to learn how to use a voting machine since the voting procedure is
similar to the traditional. Another advantage is that these systems can also
allow manual counting of ballots. This feature has a dual positive impact.
Firstly it is a safety valve against electoral fraud. If suspicions occur about the
results electronically produced, the ballots can be recounted by hand to
confirm the outcome. Secondly they allow the voter in case of system
malfunction to cast his vote which will be recorded later, when the problem will
be resolved.
In a direct recording electronic voting system (DRE) the voter indicate his
choice using a computer interface. The input is then translated into data which
can be processed and stored in memory components either locally or at a
central location.
The main advantage of DRE systems is the easy and quick counting they can
provide. As there is no mechanical or human factor involved the tabulation is
immediate and error free. Another advantage is that using a DRE system
eliminates the possibility of undervoting, overvoting or unintentionally casted
blank votes. The system will not accept votes with the wrong choice number
and will inform the user for his error. DRE systems also give solution to the
loss of data due to physical imperfections of the ballot or the reader as can
happen with punch card systems and optical voting systems. Finally DRE
systems provide the most flexible platform to implement alternative voting
methods targeting people with disabilities.
Most of the disadvantages of DREs come from the distrust of the public
against a voting system that they cannot physically verify. Studies have
shown that significant percentage of people express disbelief that a fully
computerized system is totally trustable. This disbelief comes from fears that
the software can be intentionally or unintentionally -due to coding errors-,
produce inaccurate results. DRE systems are software dependent, and such
as, they are always vulnerable to malicious attacks which in the worst case
scenario are undetected. Another problem with DREs is that voters often
express the need to verify that their vote is actually casted and casted
correctly. Without the physical evidence to support this, people don’t know
what “happens” to their ballot after pressing the button. Giving solution to this
problem is not easy since one of the basic requirements of any voting system
is not to provide voting receipts that voters can use to prove to third parties
their choice. An approach to this catch-22 is the use of paper trails, a printout
of the vote that the voter can see and verify but cannot actually take.
The other popular approach and the one we are going to use for our
own application, is the authentication through login and password
combination. The user enters his login and password and the input is
then compared with the stored in a database values in order to
authenticate the person. For this approach there is no need of special
hardware, the authentication is easy, fast and secure. The
login/password schema can be differentiated depending on the time
that the registration is done. Our approach to this is that the voters will
have setup their accounts before the start of the voting procedure. We
assume here that the registration authorities have generated and
distributed the login details to the voters beforehand, in a way similar
to the one that banks use to send their clients the ATM card PINs. An
on-the-spot registration could lead to a number of different problems.
In case it was done by the voter himself at the time of voting there
would be the risk of someone impersonating the legal voter and
register in his place. In the case that registration officers were
responsible for this step, during the elections day, it would require an
excess manpower, as officers should deal with the registration at all
voting canters. Either way, an on-the-spot registration would lead to
last minute problems and disrupt the smooth course of the process.
2 System Specifications
• Only eligible voters can vote. The eligible voters will be registered.
• The voter must identify himself before the vote. Only if registered he
can proceed to casting his vote.
• The voter can choose any of the candidates.
• Any voter can vote one and only one time.
• The vote must be confidential. There must be no way to link a specific
ballot back to the voter.
• No one, including the system administrators, should be able to
influence the outcome in any way, except by properly voting.
• The results must be accurate and correspond to the casted votes.
• The voter should be able to review his choices and change his vote as
many times he like before casting it.
• No overvoting. The voter cannot vote more candidates than the voting
protocol allows.
• The voter must have the choice to cast a blank ballot if he desires.
• The tally of the votes will be done by the authorized administrator(s)
and by him only. The results must be secured from anyone else.
• The ballot check boxes must be empty when the user begins using the
system so there is no indirect grace of any candidate.
• The system should provide a paper trail on where the voter can verify
that his vote is cast properly but this trail will be discarded automatically
at a proper box and will not be given to the voter. This way he cannot
prove to third parties his choice. This is crucial so to avoid vote buy or
sell.
• The interface must be simple enough so it can be used by computer
illiterate.
• The system must allow the wider audience possible to use it, including
elders and people with disabilities.
With the requirements set, we can now proceed to designing the system in
order to meet these requirements.
For any system there is not a unique approach to the designing procedure.
Different requirements can be met by different implementations on different
levels of the design. From the general system architecture, to the class
hierarchy and the user interface. Aim of this stage is to create our system
specifications by taking decisions on all the aspects of the design.
The design diagrams were made using the Enterprise Architect v7.5 software
by Sparx Systems. The database structure diagram was made using the
Visual Studio 2008.
2.2.1 Architecture
The first step to the design is to set our system architecture. We must define
the general structure of the system, the components from which it is
composed and the interactions between them. The diagram of our
architecture is shown in figure 2.1.
Our system will be composed from three different sub-systems. The “e-Voting
application” will be the main component with which the end user can interact
in order to access the provided functionalities. The “Counting and Report
System” will be responsible for the ballot tally-up and the report generation
when the voting procedure ends. The “Verification System” realizes the user
authentication functionality.
There will be three databases that will hold the necessary data for our system.
The first, namely “Voters DB” will contain the details of all the eligible voters.
When a voter casts his vote, he will be removed from this database and will
be moved to the “Already Voted DB”. There is a dual purpose of this layout.
Firstly to ensure that each voter can vote only one time and secondly to keep
track of who has already voted so this data can be used in order to verify the
correctness of the results. It must be noted here that there will be no entry for
the specific choice of each individual. There will be no way to link a ballot to
his voter in order to meet the confidentiality requirement.
The third database will contain the candidate details. This database will be
used from the counting system in order to calculate the votes of each
candidate. Again there will be no link with specific voters voted for the
candidate but it will be held an entry for the vote total. More detailed
presentation of the database structure will be done in chapter 2.4.
2.2.2 Activity Diagram
Continuing to describe our system in more detail we draw the activity diagram
(figure 2.2). This diagram illustrates the steps that can be made during the
use of the application and show the flow of data and control according to the
decisions made.
By reading the above diagram we can have a good impression of the program
flow. At the beginning the user is asked to enter his login details. The details
inserted are compared against the stored values in the database and
according to the outcome the user is validated. In order to keep the interface
as simple as possible we will not have a separate login option for the
administrator. The administrator will enter his details in the same field as the
other users and if his login/password combination is recognized to be of an
administrator account he is moved to the admin menu from where he can
view the vote results and generate the reports.
If the login details are correct and belong to a voter that has not voted before,
the user is transferred to the choice menu from where he can vote for the
candidate he wants. At the same menu he will have the possibility to cast a
blank ballot if he desires so. The next screen will be a confirmation message
where the system informs the user about his choice and asks him to verify it.
At this step the user can cancel his vote and return to the selection step, or he
can confirm it. In the latter case the vote is actually cast and the databases
are updated. More specifically the voter is removed from the “Voters”
database, he is added to the “Already Voted database” and his vote is cast in
favor of his chosen candidate.
The final step is to print the paper trail and the systems returns to its initial
state and is ready for the next user.
As we can see we have different classes for the administrator and the voter
which both inherit from the parent class user. The reason for this is that while
administrator and voters have completely different functionalities, they share
some common attributes as well as the authentication procedure via the
LoginDetails class.
Another class will be the ballot which despite being simple is important since it
is the link between the voter and the candidate chosen.
The candidate class will realize the counting methods in order to add votes
casted in favor of specific candidate and calculate the results.
The interface class will provide the functionalities for the GUI.
The class design may change or enhanced during the actual development
procedure. Nevertheless, it is a good starting point for the programmer and
gives him the skeleton of the application allowing him to visualize the structure
of the program and the functionalities provided by each one of the different
components.
The “VotersAlreadyVoted” table will have the same structure as the registered
voters ones, since it will hold the same kind of data. The reason of having a
separate table is besides using it for recording reasons, to use it in order to
verify the correctness of the results by comparing the number of votes with
the container of this table at the end of the voting procedure.
Finally the table of candidates will hold data for the personal details of the
candidates, including a unique CandidateID which also acts as the primary
key, as well as the number of votes each candidate has. This table is used to
update the voting results each time the system is used and a vote is cast in
favor of someone, and also will be used for the tally up and report generation
at the end of the voting.
A diagram of the database structure as described above can be seen in the
figure 2.4.
The last step in designing our system is to design the user interface. With the
Enterprise Architect we draw two series of screens, one for the voter interface
(fig.2.5) and one for the administrator interface(fig.2.6), where we can get a
clear first idea of how the visual components will be positioned in our final
system and what interaction they will provide to the user.
Figure 2.5 Voter Interface
Testing can be broadly classified under two terms: verification and validation.
Verification is defined as whether the software implements the specific
function correctly or not. Validation is defined as whether the implemented
software meets the requirements of the customer (or) end user.
There are many kinds of testing types, we are using bottom-up approach and
Black-box testing techniques in our project.
First step into the testing process will be the Unit testing. Each component will
be tested individually for the correctness of the provided functionality. When
the lower level units are ensured to work properly we will proceed to the upper
level and test the system again for the added functionality. This approach
simplifies the testing procedure as it is easier to test individual components
with limited functionality than bigger more complex blocks of code.
Next stage of the testing will be the integration testing. The low level
components will be added together and the resulting sub-system will be
tested again. This procedure will continue until we reach the uppermost level
of the hierarchy. In this stage test will reveal any interface, data manipulation
or communication errors. When all the modules are connected and the
system is complete, we can proceed to the validation testing where we check
if the system meets all the functional requirements.
For each step we will be using black box testing. This involves the creation of
test cases where with a given input we test if the desired output is produced
according to the system specifications.
Methodology
Our approach during the system development will be to use the Rapid
Application Development model. There are many reasons that make RAD the
most fitting model for our purposes. Firstly the key objective of RAD is the fast
development. Given the short, fixed time to complete our project this is a very
desirable feature. Secondly and equally important, is the reduction of project
risk by breaking the project in smaller segments. This way it becomes easier
to manage the project and make any necessary adjustments to the project
plan as the development proceeds. The use of prototyping cycles will allow
the development team to recognize problems early and consider alternatives
if needed. Testing will follow each prototyping cycle to ensure that each of the
components created that far are working as indented, making the final system
testing easier and less likely to reveal problems. In the RAD model are
defined middle delivery time-boxes. If the project begins to lag, emphasis is
put on reducing the requirements rather than delay the submission time. This
is very suitable for our project since we will be facing a strict deadline and at
the same time our goals can be flexible enough to cut off some of our
application complexity.
References
[1] Barry C, Dacey P, Pickering T, Byrne D (n.d.). Electronic Voting and
Electronic Counting of Votes - A status report. available at
http://www.eca.gov.au
1. Group members
To create a system that will be used for voting electronically. The system will
have a user friendly interface so it can be used from computer-illiterate people
and host security features to ensure the procedure integrity in various fields
such as not to allow double-voting, keep the vote confidential and produce an
accurate, fraud-free result. After the elections are over the system calculates
the results and generate a report.
We presented to the supervisor our project idea and our initial thoughts about
it.
Discussing about our alternatives for developing such an application we
concluded that the best approach would be to make it a web application using
ASP.NET. Despite the fact that no one from the group has previous
experience on such applications we agreed that this would be a nice
opportunity to learn a new interesting technology.
We arranged to install the necessary environment and tools in our machine
and bring one of the group`s laptops to the next meeting and test the
installation.
Our next meeting was arranged for the Friday 09/10/2009 at 09.30.
The group has installed the essential tools for developing applications in
ASP.NET and we brought one of the machines to the meeting so the
supervisor could check if we had everything we need.
After running a demo application everything seemed correctly installed and
configured.
We set as plan of the following week to focus on the report writing for the first
part of the coursework.
The next meeting was arranged for the Friday 16/10 at 09.30.
We discussed our progress on the report with the supervisor. We agreed that
after the submission date we should focus on the application development.
Our next meeting was arranged for the Friday 23/10/2009 at 09.30.
Each one of the group members brought at the meeting the part of the
coursework he was working on during the previous days. We read each
other`s documents and proposed some changes that should be done. The
following day we would start integrating our parts together and form the final
report until the submission date.