The project that was assigned to this group was the Transferable Voting System. It was explained that the current system of elections within the University of Cambridge is quite complicated, and requires a human Returning Officer to do a vast amount of work. It was suggested that elections could be simplified with a computer system that recorded votes at a set of workstations. It was this suggestion that forms the basis of this project.
The first task undertaken by the group was to investigate the background to this problem. The first investigative task taken was to research the Single Transferable Voting system itself. This was accomplished by gaining access to copies of the University Statutes and Ordinances through college libraries.
The first small obstacle encountered by the group was that the reference supplied in the Group Projects briefing booklet was incorrect, but the correct information was obtained quickly. On inspection of the regulations it became apparent that the complexity of the regulations had not been exaggerated. It was decided that it would be undesirable to work directly from the regulations in their currently phrased form, a clearer specification of how to conduct the count would be required.
In particular the following two webpages were found on the world wide web (through a search using the Altavista search engine):
http://www.cix.co.uk/~rosenstiel/stvrules/model.htm
http://www.cix.co.uk/~rosenstiel/stvrules/details.htm
These did not exactly conform to the rules that we were required to implement, but were still useful sources. The website http://www.princeton.edu/~usgvote/technical/paper/ was another useful source on implementing a secure election protocol.
It was realised that implementing a voting system on computer would have security implications that would have to be understood. An investigation into this area was also conducted. The book Applied Cryptography by Bruce Schneier was one of the more useful texts.
From our investigations of the problem and its background we were able to identify the main requirements of our project.
The first two requirements are:
Each user must be able to run a voting program that will present an 'electronic ballot paper' on the screen and record preferences.
The system must record the votes and then process them to give a result
These requirements are partly a restatement of the aim of the project, and partly a result from our investigation of the Single Transferable Voting System.
The remaining requirements are several security related requirements:
The programming language that will be used for this project is Java. This language has been chosen because it is the primary programming language taught by Cambridge University's Computer Laboratory and will thus be familiar to all members of the group
We have decided not to use any particular development environment such as Microsoft's Visual Studio or Sun's Java Workshop. Instead we will utilise programs such as Emacs and Windows Notepad to write the code. The exact choice of program will be left up to the individual programmer. We will be using the revision control system CVS.
The version of Java that we will be using is Java 2, but we will not use any of the new features that are exclusive to Java 2, it is our intention that our programs and applets will be able to run correctly on a system that has Java 1.1x.
We will assume that the people running the election program will be able to take the printouts of Voter IDs and PassKeys and envelope and mail them in a secure fashion. This assumption is reasonable since the University already has the capability of distributing similar sensitive information such as voting cards, passwords for computer systems, etc.
We will assume that all voters will have access to a computer that has installed upon it a World Wide Web Browser, and that this browser has Java enabled. This assumption is reasonable. All members of the University have access to networked computer systems, either in their own rooms, or college computer rooms, or departments. The University Computing Service also offers a Personal Workstation Facility (PWF) and this is also available to all voters.
The fifth principle of the Data Protection Act(1998) says that:
"Personal data processed for any purpose or purposes shall not be kept for longer than is necessary for that purpose or those purposes."
Our system will not address this principle of the Data Protection Act, we will expect those operating the system on the server end to destroy personal data after the election.
The seventh principle of the Data Protection Act(1998) says that:
Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.
Our system will not be encrypting the personal data of voters (such as their addresses), or taking any other special measures to support this principle. We will only advise system operators to set file permissions with this principle in mind.
The use of a Java Applet as the voting form is important. Because it can be accessed from anywhere on the internet it should dispense with the need for special postal or email voting
The overall system has been broken down into the modules/components shown by the diagram below. The dashed lines are a representation of major communication between system components.
There are four main modules involved in an election
Files:
An election will be represented by a set of files stored in a directory. Each election in progress will use it's own directory. Under this directory at least a basic hierarchy will be expected. Care should be taken to ensure that only authorized persons may read the files contained within these directories.
Election-Base | +-- public_html All generated HTML files are stored here. | It might also be a good place to store | other HTML files. | +-- votes This subdirectory contains a file for each | position in the election. | +-- signed_votes This subdirectory contains a file for each | voter containing any votes signed by the AS. | +--Files:
Election-Base/election |
A serialized version of the Election object which
contains the parameters for this election. |
Election-Base/as_privatekey,
ss_privatekey |
Serialized objects representing the private key used by each of
the servers. The PublicKey objects are stored in the
Election class. |
Election-Base/voters |
The list of all voters in the election. |
There will be a suite of programs which are used for setting up an election. These programs are:
Configuration - GUI
The GUI is provided by the class
CST1b.juliet.Setup. The GUI should provide methods for
editing the lists of:
The GUI should allow for editing all fields in the
Election, Candidate, Voter,
Position classes.
When creating a list of voters (which may be long) the application should offer the option of reading a global list of all possible voters and selecting those which are to be included in the election.
These settings should be saved by serializing the
Election into
Election-Base/election. The list of voters should
be serialized into Election-Base/voters.
Election Setup
Once the election has been setup, a program
CST1b.juliet.GenerateElectionData will be run which
generates the static data used by the election process:
This application should also setup all of the necessary sub-directories of the election directory.
Printing Subsystem
Prior to the beginning of the election, each voter must be informed of their right to vote and the rules of the election, the list of candidates/posts available, how to vote and their secret PAK. An application will be provided which will produce a form letter containing the parts of this information which are individual to each voter. It is expected that the election administration would also produce a form letter containing information about the election in general.
The application will consist of a command line utility
CST1b.juliet.PrintPollCards which will read the necessary
Election configuration data and produce a form letter containing the
voters name, id and PAK, as well as the URL at which they may
vote. Below is a sample of the letter which might be produced.
Notice of Election ------------------ Dear Randy Dangle, You are entitled to vote in the following election: Election of Part IB Student Committee. The following are your details, you will need these in order to vote, and should not disclose them to anybody. * User-ID: xyz27 * Personal Authorization Code (PAK): A4F925ED To vote, visit http://www.cam.ac.uk/election/part1b-rep.html Thank you, Election Sub-Committee
The application will take on the command line the name of the election configuration directory and a directory into which it will place the letters for printing. Each letter will be placed in a separate file in this directory, named by the users ID. Optionally the program will take a list of voter ID's on the command line and only produce letters for that subset of voters.
The letters will be printed using the standard system
facilities. eg 'lpr *' on a unix system.
Opening the Polls
Once the election is configured, the servers may be started at any
time before the designated polling time. Servers will not accept votes
until after the polls have officially opened, as shown by
Election.pollOpen. An HTML file embedding the client
applet should be made available at the correct address.
This module is the main interface to the voter. It takes the form of a web-based Java applet.
The applet will be contained within a web page containing instructions on how to vote, as well as the regulations for the election. In particular this web page should contain the text specified by point 4 of STV Regulations in the University Ordinances.
At startup the client will download via http a serialized
Election object which contains all the parameters of the
election. The URL of this object will be made available in a parameter
specified using <param> tags in the embedding HTML
document.
Once the client has initialised it will present the voter with an initial greeting window, requesting the voter's id and PAK.
The client will then present the voter with an interface which will allow them to fill in a form specifying the candidates they wish to vote for. This interface will consist of a window broken into 2 panes. The left hand pane will contain a list of all positions available in the election. The right-hand pane will present a voting form for the currently selected position. Along the bottom of the window there should be a status bar. This should be used at each stage of the protocols documented below to inform the user of the stage of the transaction.
The voting pane will consist of a list of candidates, with a set of radio-buttons next to their name. The number of check buttons next to each candidate will be equal to the number of candidates, plus an additional 'do not rank this candidate' check-box. There will also be buttons providing links to the (optional) homepage of each candidate. The interface will allow one check to be placed next to each candidate, in the column representing the voters vote. In the example below the voter has chosen 'Mary Queen of Scots' as their first choice and 'Johnathon Doe' as the second. They have elected not to place 'Phil'.
The image below is a mock-up of the voting interface, it is intended to show the location and layout of the major components.
The bottom of the voting pane will contain two buttons. One of these will reset the votes, the other will cast the votes as currently selected.
Once the voter has made their choices and committed to them, then they will not be allowed to change their mind. Then the client will now begin the Authorization and Submission Protocol. It will perform this protocol once for each position that is being voted for.
Since each vote has a separate random id, and it is inefficient to ask the voter to write down all of them, the client will generate a random number, this number will be sent to the submission server along with the vote, this number will be printed in the election results next to each vote this client makes, allowing the voter to check if their vote was properly counted.
In order to cast a vote, the client software must interact with 2 server systems. These are:
CST1b.juliet.AuthorizationServerCST1b.juliet.SubmissionServerThe Authorization server takes part in stages 1 through 4 of the Authorization Protocol with the client applet. All Communication with the AS must be encrypted.
The AS must be able to deal with multiple connections at a time.
Once a client has retrieved a set of signed votes then the AS should refuse to sign anymore.
The AS must not accept connections outside of the configured polling period.
The AS must maintain on disk all blind-signed votes, and should also maintain a cache of recently signed votes.
Communication Protocol
Initially the client and AS must obey the following protocol when opening a connection.
If at any stage the server receives an invalid string it should
send the string "ABORT:" followed by a one line error
message and a newline character then drop the connection.
"JULIET
AUTHENTICATION SERVER Vx.x", followed by a new line."USER:" followed by the
voters identification string and a newline character."PASS:" followed by the
voters private authentication key (PAK) in hexadecimal format."ACCEPT" followed by a newline. If the
identification string and PAK do not match up then the server will
send the string "REJECT" followed by a one line error
message age and a newline character and then drop the connection.The second stage of communication allows the client to enter one of several sub-protocols with the server.
If at any stage in the following protocols the server receives an
unexpected or invalid string it should send the string
"ERROR:" followed by a one line explanatory error message
and a newline character. It should then return to the start of the
second stage of communication.
Sub-protocol - SIGN
This sub-protocol allows the user to submit blinded votes to the server and have them authenticated, and corresponds to stages 1-3 of the Authorization and Submission Protocol (excluding returning the signed votes to the client).
"SIGN" to the AS."ERROR: ALREADY RETRIEVED", and return to the start of
the second stage of the protocol. If the client has not
RETRIEVED any votes then the server reports
"OK", followed by a newline."ERROR: VOTE SET NOT VALID" followed by a newline and
then return to the start of the second stage of communication./signed_votes. These new signed votes
will replace any previously signed votes.Sub-protocol - RETRIEVE
This sub-protocol allows the client to retrieve signed votes from the AS.
"RETRIEVE" to the server,
followed by a newline."ERROR: VOTE SET NOT SIGNED" to the client. If
the server finds a valid signed set of votes then it Serializes these
votes and sends them to the client.The Submission Server will take part in stages 5 through 8 of the Submission Protocol with the client applet. All communication with the SS is required to be encrypted.
The submission server will not accept connections outside of the configured poll times.
The following protocol must be followed by the client and server when a vote is submitted.
If at any stage the server receives an unexpected or invalid string
it should send the string "ABORT:" followed by a one line
error message and a newline character then drop the connection.
"JULIET SUBMISSION SERVER Vx.x", followed by a newline.BigInteger containing the
voters random identifier across the line, followed by a
SignedObject containing a signed vote."ACCEPT" to indicate the vote has been accepted or
"REJECT" to indicate if the vote was rejected. In both
cases a newline will follow.The submission server will serialize all accepted votes into files
under Election-Base/votes. The name of the file
will be the same as the unique position id, Position.id
java STV < path to Serialized Election Object >
The Module will then calculate the candidates that have been elected for each Position specified by the Election Object (according to our Computer Related STV Counting Regulations). Each instance of the STVModule object will calculate who is elected for one position. Hence there will be one instance of STVModule for every position being contested.
The STVModule will perform its calculations using the CandVoteRec and CountControlForm classes. It will fill in each "row of the forms" by completing information to those Objects. The methods to add information to a CandVoteRec and CountControlForm object are
CandVoteRec.addStageInfo()
CountControlForm.addElectedInfo()
respectively. (See below for full explanation of methods)
When the tallying is complete, the tally module will have:2. An Output Results Module will read in the Serialized Information Objects (CandVoteRec and CountControlForm Objects) and produce an HTML file containing all information for the Election.
The Output Results Module is also started from the command line:
java OutputResults < Election Name >
In cases where a Class is shown to implement a particular interface, the methods of this interface may not be included in the description of the object.
Classes used for Security
The following diagram shows how the following classes are used to authenticate the voter with the Authentication Server and receive a signed vote.
Class: CST1b.juliet.security.SecureRandom
The class SecureRandom encapsulates a random number
generator. This class should be instantiated at the very start of
initialisation by any application that wishes to use it, so that it
may begin to gather entropy from the system.
For the purposes of this project a pseudo-random number generator will be used.
public class SecureRandom {
// Constructors
SecureRandom();
// Methods
public int getInt();
public byte[] getBytes(int length);
}
SecureRandom() - Creates a new Random number
generator.
int getInt() - Returns a new random integer.
byte[] getBytes(int length) - Returns an array of
length length containing random bytes.
Class: CST1b.juliet.security.Key
The class Key is the abstract base class representing
all cryptographic keys.
public abstract class Key implements Serializable {
// Constructors
public Key(BigInteger key);
protected Key();
// Methods
public BigInteger getValue();
}
Key(BigInteger key) - Create a new key with a value of
key
Key() - Create an empty Key object.
BigInteger getValue() - Returns the value of the key.
Class: CST1b.juliet.security.PublicKey
Class: CST1b.juliet.security.PrivateKey
The classes PublicKey and PrivateKey are
concrete extensions of Key and are used to represent a
key pair.
These classes implement no new methods.
Class: CST1b.juliet.security.KeyPair
The class KeyPair is a factory for generating
PublicKey and PrivateKey pairs.
For the purposes of this project both keys will be identical 4 byte random integers.
public class KeyPair {
// Constructors
public KeyPair();
// Methods
public PublicKey getPublicKey();
public PrivateKey getPrivateKey();
}
KeyPair() - Construct a new KeyPair.
PublicKey getPublicKey() - Return the public key.
PrivateKey getPrivateKey() - Return the private key.
Class: CST1b.juliet.security.SignedObject
The class SignedObject encapsulates a digital
signature and an object. Any Serializable object can be encapsulated.
For the purposes of this project the signature algorithm will be a simple insecure XOR algorithm. The data to be signed will be XOR'd together in 4 byte blocks, before being XOR'd with the PrivateKey.
To verify - do the same thing with the PublicKey - since the Public and Private keys are the same.
public class SignedObject implements Serializable {
// Constructors
public SignedObject(Serializable s, PrivateKey key);
public SignedObject(Serializable s, BigInteger sig);
protected SignedObject()
// Methods
public boolean verify(PublicKey key);
public Object getObject();
public BigInteger getSignature()
}
SignedObject(Serializable s, PrivateKey key) - Create a
new Signature of the object s using the
Private Key key
SignedObject(Serializable s, BigInteger sig) -
Construct a Signature object of s where sig
is the previously generated signature.
SignedObject() - Create an empty SignedObject.
boolean verify(PublicKey key) - Use public key
key to verify that the signature is a valid signature of
the encapsulated object.
BigInteger getSignature() - Returns a BigInteger
containing the signature of the encapsulated object.
Object getObject() - Returns the encapsulated object.
Class: CST1b.juliet.security.BlindObject
The BlindObject class encapsulates an object which has
been blinded by multiplication with a large random value.
The data is blinded by XORing it with the blinding factor. The first byte of the data is XOR'd with the first byte of the blinding factor. This implies that the Blinding Factor must be longer than the data to be blinded. Unblinding requires simply repeating the process.
public class BlindObject implements Serializable {
// Constructors
public BlindObject(Serializable v, BigInteger bf);
protected BlindObject();
// Methods
public Object unBlind(BigInteger bf);
public BigInteger toBigInteger();
}
BlindObject(Serializable s, BigInteger bf) - Creates a
new BlindObject of the given object s, using the blinding
factor bf. bf must be long enough to XOR
with all of the data to be blinded.
BlindObject() - Create an empty BlindObject.
Object unBlind(BigInteger bf) - Returns the unblinded
object, using the blinding factor bf.
Class: CST1b.juliet.security.EncryptedInputFilter
Class: CST1b.juliet.security.EncryptedOutputFilter
These two classes should subclass the
java.io.FilterInputStream and
java.io.FIlterOutputStream and override all necessary
methods to provide encryption.
For the purposes of this project the encryption will be to XOR the stream with the key. Encryption will happen on a single byte at a time, with each byte of the key being used in turn in a loop.
public class EncryptedInputFilter extends java.io.FilterInputStream {
// Constructor, takes the stream to wrap and the PrivateKey to
// use
EncryptedInputFilter(InputStream in, PrivateKey key);
}
public class EnrpytedOutputFilter extends java.io.FilterOutputStream {
// Constructor, takes the stream to wrap and the PublicKey to
// use.
EncryptedOutputFilter(OutputStream out, PublicKey key);
}
Classes used during Election
Class: CST1b.juliet.election.Election
This class encapsulates all the information about an
election. There will be one instance of this class in a running
program, any class may access the current Election object using the
static method Election.getElection(). When a serialized
election object is read - it should replace any current global
election object.
public class Election extends Serializable {
// Create a default Election object.
protected Election();
// Gets an instance of an election object. There should only
// be one of these in any running program. If there is no
// Election object in this program, create one.
public static Election getElection();
// The directory containing the files for this election.
public String getElectionBase();
public void setElectionBase(String eb);
// The name of this election. The title is a one line
// Informative String.
public String getTitle();
public void setTitle(String title);
// A reference to a web page containing the rules for this
// election.
public String getRulesURL();
public void setRulesURL(String rurl);
// An array containing all candidates. The index into this
// array is used to identify the candidate in the voting
// form.
public Candidate[] candidates;
// An Hash table containing each of the positions available,
// keyed by Position.id
public Hashtable positions;
// name or dotted-quad (IP) addresses of the 2 servers.
// eg: http://authserver.cam.ac.uk[:8123]/. Where [:8123] is
// an optional port number.
public String getAuthorizationServerURL();
public void setAuthorizationServerURL(String url);
public String getSubmissionServerURL();
public void setSubmissionServerURL(String url);
// name or dotted-quad address of the voting form, containing
// the voting applet.
public String getVoteURL();
public void setVoteURL(String url);
// Date objects containing the times to open and close polling
public Date pollOpen;
public Date pollClose;
// Public Key objects for the servers.
public PublicKey authorizationPublicKey;
public PublicKey submissionPublicKey;
}
Class: CST1b.juliet.election.Voter
This class encapsulates all the information which is relevant to a candidate.
public class Voter implements Serializable {
// Create an empty Voter
public Voter();
// The voters full name
public String getName();
public void setName(String n);
// A short string which uniquely identifies the
// voter. eg. Hermes login name.
public String getID();
public void setID(String id);
// The Voters Personal Authentication Code. This is a random
// number which is used as a password.
public BigInteger pak;
// Address. This may contain '\n' so as to use multiple lines.
public String getAddress();
public void setAddress(String addr);
}
Class: CST1b.juliet.election.Candidate
This class encapsulates the information about each candidate.
public class Candidate implements Serializable {
// Create an empty candidate
public Candidate();
// The candidates name
public String getName();
public void setName(String name);
// An optional URL to a candidates web page
public String getWebPageURL();
public void setWebPageURL(String url);
}
Class: CST1b.juliet.election.Position
This class encapsulates the parameters of a single post up for election.
public class Position implements Serializable {
// Create an empty Position
public Position();
// The name of the post.
public String getName();
public void setName(String n);
// A short unique string representing this position.
public String getID();
public void setID(String id);
// The number of spaces available for this post
public int getSpaces();
public void setSpaces(int sp);
// An array containing the index into Election.candidates
// for each candidate.
public int[] candidateIds;
// An array which may contain references to the Candidate
// objects for all the candidate standing for this post.
// These should not be serialized with the object.
public Candidate[] candidates; }
Class: CST1b.juliet.election.Vote
The Vote class represents a Vote. A vote is specified as an array of candidate names in order of preference and a unique random identifier.
public class Vote implements Serializable {
// Constructors
public Vote(BigInteger rid, String position, int[] votes);
protected Vote();
// Methods
public int[] getVotes();
public BigInteger getID();
public String getPosition();
public int getNextPreference(boolean reset) throws
NoMorePreferences;
public boolean verify();
}
Vote(BigInteger rid, String position) - Construct a
new Vote for the position given with a unique random
identifier of rid. The votes are given in
votes each value is the offset in to the field
Candidates in the Election object.
Vote() - Create an empty Vote object.
int[] getVotes() - Returns an array of Strings
representing the candidates voted for in order of preference. The
candidate at [0] represents the top choice.
BigInteger getID() - Return the Random ID of this Vote.
String getPosition() - Returns the unique identifying
string for the position this vote is for.
int getNextPreference(boolean reset) - If reset is
false then on subsequent calls this method will return in order the
preferences of this vote, if reset is true then it will return to the
start of the list and start again. If there are no more preferences
it will throw the exception NoMorePreferences.
boolean verify() - Verify if this vote is a valid vote
- if not return FALSE.
Classes used by the Client GUI
Class: CST1b.juliet.gui.BallotPaper
This class represents a single ballot paper in the client GUI. The GUI is described above in the Client section.
public class BallotPaper extends Component {
public BallotPaper(Position p);
public Vote getVote();
{
BallotPaper(Position p) - Create a new ballot paper
for the position given.
Vote getVote() - Returns a Vote object representing
the choices made in the GUI.
Public Classes used by STV Tallying Module
Class: CST1b.juliet.STV
The STV Tallying module is used by:
usage: public class STV
public static void main(String[] args)
java STV < path to Serialized Election Object >
{
//expected argument: < path to Serialized Election Object >
}
Private Classes used by STV Tallying Module
These are internal implementation details, and the public should not be concerned with them.Class: CST1b.juliet.tally.STVModule
Actual STV Tally Module, which when instantiated, can be called to calculate which candidate(s) will be elected for a particular position.
public class STVModule
{
//Constructor
//Position pos: Position object
//String votesfile: Path to file of Vote objects.
public STVModule(Position pos,String votesfile);
//Methods
//Start the tally
public void startTally();
}
Class: CST1b.juliet.tally.CandVoteRec
Encapsulates all information shown by the form below. Has methods to retrieve values from the class, as well as methods to add new information.
public class CandVoteRec implements Serializable
{
//Constructor
//String name: name of candidate
//int ID: unique identifier
//float quota: quota for election
//Vector voteforms: Vector of Vote objects with preference for this candidate
public CandVoteRec(String name,int ID,float quota,Vector voteforms)
//Methods
//add another ROW of information to form (shown below). Note that it passes the ACTUAL
//Vote Objects inside the Vector voteforms
public void addStageInfo(int stage,int from_ID,String from_name,
float transfer_value,Vector voteforms)
public int getID(); //returns ID of candidate
public float getQuota(); //returns quota
public String getName(); //returns name of candidate
//returns a Vector. Each element of the Vector is a
//ROW of information on the form shown below.
//Each element is of type CandVoteRec.Info (inner class)
public Vector getStageInfo();
public int getStage(); //returns last recorded stage number
public int getFromID(); //returns last recorded From ID (see below)
public String getFromName(); //returns last recorded From Name (see below)
public int getNumberOfPapers(); //returns Number of Papers last received
public float getTransfervalue(); //returns transfer value of last received papers
public float getValueReceived(); //returns Vote Value last received
public float getPresentVote(); //returns latest recorded Vote Value i.e present vote
public Vector getVotes(); //returns a copy of the Vector of Vote Objects last received.
public String toString(); //prints various information for debugging
//Inner Classes
//class Info encapsulates all the information in a single row of the form shown below
class Info
{
//Members
public int stage,from_ID,num_of_papers;
public float transfer_value,value_received,present_vote;
public String from_name;
public Vector votes;
//Constructor
public Info (int stage,int from_ID,String from_name,float transfer_value,
float old_value,Vector voteforms)
}
}
| EXAMPLE VOTE RECORD FORM (class CandVoteRec) | |
|
VOTE RECORD OF CANDIDATE candidate name |
QUOTA quota |
Stage |
From Name |
Number of papers |
Transfer value |
Value received |
Present vote |
1 |
"First preferences" |
Integer |
1.00 |
Float |
Float |
2 |
String |
Integer |
Float |
Float |
Float |
3 |
String |
Integer |
Float |
Float |
Float |
Class: CST1b.juliet.tally.CountControlForm
Encapsulates all information shown by the form below. This form contains information on who has been elected for the Position shown. Has methods to retrieve values from the class, as well as methods to add new information.
public class CountControlForm implements Serializable
{
//Constructor
//String position_name: Name of positon being contested
//int seats: Initial number of seats to be filled
//inbt total_votes: Initial total number of votes.
//float quota: quota of election
public CountControlForm(String position_name,int seats,int total_votes,float quota)
//Methods
//add another ROW of information to form (shown below)
public void addElectedInfo(int elected_ID,String elected_name,float votes)
public boolean isElected(int ID); //returns true if candidate ID is elected, false otherwise;
public int getNumberOfCandsElected(); //returns number of people elected
public int getSeats(); //returns ORIGINAL number of seats to be filled
public int getTotalVotes(); //returns total number of votes received
public float getQuota(); //returns quota
public String getPositionName(); //returns name of Position being contested
//returns a Vector. Each element of the Vector is a
//ROW of information on the form shown below.
//Each element is of type CountControlForm.Info (inner class)
public Vector getElectedCandidates();
public int getSeatsLeft(); //returns seats left to fill
public String getName(int ID); //returns Name(b) (see below) of candidate ID
public float getVotes(int ID); //returns Votes(c) (see below) of candidate ID
public float getSurplus(int ID); //returns surplus(d) (see below) of candidate ID
public float getElectedVotes(int ID) //similar to above for column (e)
public float getTotalVotesLess(int ID); //similar to above for column (f)
public public String toString(); //prints various information for debugging
//Inner Classes
//class Info encapsulates all the information in a single row of the form shown below
class Info
{
//Members
public int num,elected_ID,seats_left_plusone;
public float votes,surplus,elected_votes,total_votes_less;
public String elected_name;
//Contructor
public Info(int num,int elected_ID,String elected_name,
float votes,float surplus,float elected_votes,
int seats_left_plusone,float total_votes_less)
}
}
|
EXAMPLE COUNT CONTROL FORM (class CountControlForm) | ||
|
Election for Position Name |
||
|
Seats to be filled seats |
Total Vote total votes |
Quota quota |
|
Calculation of total votes attributed to elected candidates | ||
|
No. |
|
Votes |
Surplus |
|
Total vote less votes of elected candidates (f) |
Seats remaining to be filled + 1 (g) |
|
1 |
String |
Float |
Float |
Float |
Float |
Integer |
|
2 |
String |
Float |
Float |
Float |
Float |
Integer |
Exceptions used by all Modules:
| Exception Name | Description |
CST1b.juliet.election.NoMorePreferences |
Thrown by Vote.getNextPreference when this vote has
no more preferences. |
The following protocol is a modified version of the Voting with
Blind Signatures protocol given on page 126 of Applied
Cryptography (Second Edition) by Bruce Schneier.
All communications between the client and server should be encrypted for security...
The following is a comprehensive account of how counting of the votes will occur within this computer program. It is based upon Points 5 to 17 of the Single Transferable Vote Regulations in the University of Cambridge Statutes and Ordinances, pages 121 to 124. This account has been designed firstly to take into account the differences between counting votes on a computer and counting by hand, and secondly to present the rules of counting in a clearer form of English. It is hoped that this clearer account will ease the translation of the regulations into actual code.
1.1 Count all the voting papers to determine the total number of votes cast(=total valid vote).
Quota = (Total Valid Votes) / (number of VACANCIES to be filled+1)
if (quota>100) quota=ceiling(quota);
else quota=(quota round UP in the second d.p.)
1.5 Considering each candidate in turn in DESCENDING order of their votes, deem elected any candidate whose vote equals or exceeds the quota, up to the number of places to be filled, subject to NOTES (*).
1.6 That completes the first stage of the count.
We will expect some testing to be carried out in conjunction with the programming phase by the programmers themselves, on the code as they write it. This could just be the testing of a single line or the block of the code. It is hoped that as many problems as possible, to do with the internal 'private' workings of modules, will be caught and corrected at this early stage. Of course it would be impossible to anticipate and catch all possible problems with such testing, so further testing will be carried out on different scales using a Three Phase Testing Plan:
This is small scale testing. Individual classes will be tested using test frames. The test frames will be used to pass both valid and invalid data to the classes. Testers will check that a valid output is produced whenever a valid input is fed into a class. Also they will check that classes behave sensibly on the input of invalid data. Should we a class fail its test then the class will be modified.
Full testing of the Pre-Election GUI will also take place during phase one.
This phase will be documented. This documentation will included the test frames used, the test results, and the details of any major changes that had to be made because of a phase one test
This is medium scale testing. Clusters of related modules will be tested to ensure that they work and communicate together as intended by the specifications. If and when necessary, feedback will be used to re-engineer modules.
The primary clusters to be tested will be:
This stage will be documented fully. The tests carried out on the various clusters will be noted together with their results and any further action taken.
This is large scale (or 'System Level') testing. The system will be tested as a whole using pre-prepared test data. This will be an election with 10 voters, 2 positions, and 3 candidates for each position. This election will also be carried out manually and the manually obtained election results will be compared to the election results of the system.
The system will be checked to see whether the Acceptance Criteria for the finished product have been fulfilled.
This stage will be documented fully. Details of the tests performed input data fed in and output data received will be recorded. Compliance with the acceptance criteria will be justified.
An Analyst will be in overall control of testing.
The following documentation will be produced:
This will include:
This document is meant to be a piece of technical documentation rather than for the eyes of end user.
This piece of documentation will be designed for the people physically running the election. It will document tasks such as:
This guide will not use vast amounts of technical jargon
This guide is supposed to be a comprehensive explanation of how to use the client side of the program. It will also include a simple and brief explanation of security protocols to try to show that the system is secure.
It is not intended that this guide will be sent out to all voters. It should be available for individual voters by request, and possibly also placed in computer rooms or other such places where mass voting may occur.
This piece of documentation is intended to be a sort of 'Dummies Guide' to explain how to vote using the applet. It would probably be sent out to voters with all the other information that they are sent. It should be written with clarity of language in mind, and designed so that poster versions could also be produced.
It has been decided that the members of the group will generally have more than one role throughout the project. This is to try and ensure that the workload for each member is roughly even through time. This is deemed preferable to a member of the group having little to do initially and then a vast amount to do at later stages(or vice versa). Such a philosophy would not necessarily maximise human resources.
The roles of each group member are as follows:
| Sagar R. Shah: | Manager + Chief Documenter |
| Tak L. Fung: | Vice-Manager + Programmer + Tester |
| Ian J. Campbell: | Analyst + Code Librarian |
| Ritchie N. Hughes: | Programmer + Documenter + Webmaster + Minutes Taker |
| Ian J. Bunning: | Programmer + Tester |
All members of the group will be expected to keep some sort of log of their activities in relation to this project. Not only will these logs facilitate the writing of personal reports but they will also be required if the Illness Contingency Plan is activated.
Each of the programmers has been assigned responsibility for specific components of the system:
| Tak L. Fung: | Tallying/Counting Sub-System |
| Ritchie N. Hughes: | Pre-Election Setup + End User GUI for Voting System. |
| Ian J. Bunning: | Client & Server Sides of the Authentication, Submission and Information Sub-Systems. |
Due to the size and complexity of his brief Ian Bunning will be able to delegate some of the programming work to Ian Campbell and the other two programmers.
This plan will be activated in the event of the illness or loss of a group member.
Should Sagar R. Shah, be ill then his managerial role and responsibilities will be assumed by the Vice-Manager, Tak Fung.
His Chief Documenter role will be assumed by the Documenter, Ritchie Hughes.
Should Tak Fung be ill then the role of Vice-Manager and his testing role will be taken by Ian Campbell.
His programming role will be taken over by Ritchie Hughes
Should Ian Campbell be ill then the role of Code Librarian will be taken by Sagar R. Shah.
The role of Analyst will be taken by Tak Fung.
Should Ritchie Hughes be taken ill then the role of Documenter will be taken by Sagar R. Shah.
The role of Webmaster will be taken by Ian Bunning.
The role of Minute Taking will be taken by Ian Campbell.
His programming responsibilities will be taken by Tak Fung.
Should Ian Bunning be taken ill then his programming role will be taken by Ian Campbell.
His testing role will be taken by Ritchie Hughes
Should a the manager find that a member of the group is not able to carry out extra responsibilities for some reason then it will be the Manager's (or Vice-Manager's) responsibility to modify the Illness Contingency Plan to take this in to account.
Should two or more members of the group fall ill or are lost at the same time then the Manager (or Vice-Manager) must devise and implement an emergency plan. The timing of such an event will considerably affect whether the group will be able to meet all deadlines.
Should an extra member be added to the group then they will first be asked to familiarise themselves with the project requirements and specifications, and they will subsequently will discuss with the Manager what roles they will be assigned.
Important Dates:
| Date | Event |
| 20 Jan | Inaugural Meeting |
| 02 Feb | Deadline for first set of deliverables |
| 03 Feb | Overseer Meeting |
| 08 Feb | Presentation Skills Lecture |
| 16 Feb | Deadline for second set of deliverables |
| 17 Feb | Overseer Meeting |
| 01 March | Deadline for third set of deliverables |
| 02 March | Overseer Meetings |
| 06 March | NOON Deadline for final code |
| 08 March | Group Presentations |
In addition to the meetings with the group's overseer, it is the intention to hold meetings on the Monday and Friday of each week.
The following is a list of some enhancements that could be made to our system, either by ourselves if we were to continue to develop the system past this term, or by another group that wanted to extend the system.