Contents

• Erratum in Function Specification and Module Design
• Summary of Progress
• Clarifications to Specification
• Modifications to Specification
• Status of Classes
• Pointers to On-Line Information

Erratum in Functional Specification and Module Design

The Notes section of the Computer Related STV Regs should have read:

(*)If, when candidates should be deemed elected under sections 1.5, 3.9 or 4.4, there are not sufficient places left for them all, then none of them shall be deemed elected at that stage.

to be fully compliant with point 6 in the University STV Regulations. This is a subtle correction, but important for the implementation.

Summary of Progress

The project is proceeding fairly well and is roughly on target. All major classes have been written and most have been tested (see classes and interfaces section below). There have been no problems with communication among group members, we are working well as a team. Problems have appeared that have required changes to the specification, but none of these problems has been massively significant. The limitations of the AWT of Java 1.1x have made it difficult to create aesthetically pleasing GUIs, but the priority was to get the internals of the GUIs working. Their user interfaces may be improved later.

We have addressed the possibility of the authentication server failing to work. Should this happen our contingency plan will be to make small changes to submission server to allow it to accept votes without checking. This would at least allow us to demonstrate that the other parts of the system are working.

Our next course of action will be to integrate and test whole modules, and finally, the entire system.

A rough estimate of the hours worked by group members follows:

Clarifications to Specification

If the blinding factor supplied to BlindObject is too small it will be wrapped.

When the CountVoteRecord and CountControlForm for each position are serialized to disk their filenames will be [PositionID].CVR and [PositionID].CCF respectively. These files will be written to the election-base directory.

The sockets that will be listened on by default will be:

• AuthServer 4153 (AS ascii)
• SubServer 5353 (SS ascii)

The OutputResults program will also generate the vote verification data. For each position it will generate a HTML file containing the RandomIDs of the votes used for that position and the preferences of each vote. This will allow voters to check that their vote has been counted.

The specification was slightly inconsistent over whether the Authentication Server was called that or Authorization Server. To clarify, it will be called the Authentication Server and this is reflected in the class listing later in this document.

Modifications to Specification

The exception CST1b.juliet.election.NoMorePreferences has been renamed CST1b.juliet.election.NoMorePreferencesException for consistency with standard naming conventions. Methods that use this exception have been modified accordingly

An extra exception CST1b.juliet.tally.IDNotFoundException has been created for use by the CST1b.juliet.tally.CountControlForm class. Methods in this class will throw the exception if they are asked to utilise an invalid candidate ID.

Exceptions CST1b.juliet.election.IDNotUniqueException and CST1b.juliet.election.CandidateNotInElectionException have been added for use by methods in the Election class.

The argument taken by the OutputResults utility has been changed. Rather than requiring the election name as an argument it requires the path to the serialized election object. Usage:

This is a sensible modification. The program needs to know where the election object is kept, i.e. what the election-base directory is. It does not need the election name as this is a variable internal to the object. Also one would never keep two serialized election objects in the same directory.

Two new public methods have been added to the CST1b.juliet.tally.CountControlForm class:

These methods are required to set and get a private float field called untransferred_votes. These are required for the module to work, they should have been included in the original specification.

Candidates are no longer stored inside of the election object. Instead they are stored inside the position object for the position that they are contesting. This is a clearer implementation as it better corresponds to the real world model. The fields:

• int[] candidates
• Candidate[] candidates

• Candidate getCandidate(int i)
• int getCandidateIndex(Candidate c)
• Enumeration getCandidates()
• void addCandidate(Candidate c)
• void removeCandidate(Candidate c)

CST1b.juliet.election.Vote will now index candidates by their position in their respective Position object.

The following public fields have been removed from CST1b.juliet.election.Election:

• Date pollOpen
• Date pollClose
• PublicKey authorizationPublicKey
• PublicKey submissionPublicKey
• HashTable positions

In their place we have added corresponding private fields and the following public methods:

• Date getPollOpen()
• Date getPollClose()
• void setPollOpen(Date d)
• void setPollClose(Date d)
• PublicKey getAuthorizationPublicKey()
• PublicKey getSubmissionPublicKey()
• void setAuthorizationPublicKey()
• void setSubmissionPublicKey()
• Position getPosition(String id)
• Enumeration getPositions()
• void addPosition(Position p) throws IDNotUniqueException
• void removePosition(Position p)

These methods allow us to validate and verify data and their use is consistent with the idea of encapsulation in Object Orientated Programming.

For the same reasons we have also removed the field BigInteger pak from CST1b.juliet.election.Voter and added the methods void setPAK(BigInteger i) and BigInteger getPAK()

The communications protocol now sends stream objects rather than a stream of bytes

Status of Classes

Package CST1b.juliet

Package CST1b.juliet.authserver

Package CST1b.juliet.client

Package CST1b.juliet.election

Package CST1b.juliet.security

Package CST1b.juliet.setup

Package CST1b.juliet.submission

Package CST1b.juliet.tally

Testing Classes

To facilitate testing, the following classes have been written by IanC:

• Test.java
• TestHarness.java
• TestHarnessGUI.java
• TestHarnessText.java
• TestTest.java

These classes reside in the package CST1b.juliet.testharness. All major classes have an associated [ClassName]Test.java Class that will be used by the Testharness in performing tests.

The exception classes are trivial and do not require testing above checking that they compile correctly.

Pointers to On-Line Information

Our source code is available at: http://www.thor.cam.ac.uk/group/CST1b/juliet/src/

Details of testing that has been performed along with the test results and javadoc documentation of the actual classes are available at http://www.thor.cam.ac.uk/group/CST1b/juliet/javadoc/

Sumaries of our daily project logs are at http://www.thor.cam.ac.uk/group/CST1b/juliet/sagar/prlogs.html