We have designed our ballots to contain a set of categories. Each category is divided into options. There are different types of categories: these include one that only allows one option to be selected, one that allows all options that apply to be selected, and one that allows the options to be ranked. We considered implementing the ballot in the form of a composite pattern. However, we decided that the increased flexibility did not justify the increase in complexity. We did not implement a candidate data type in our design; candidates, parties and referendum are all represented as options.
We have designed two types of elections, one that allows a ballot to be updated, the other only allows a person to submit their ballot once. Having two election types permits the use of a more secure model when users are not permitted to update their vote. In this model the ballots do not have to be associated with the user that submitted them. The other model requires that this association be maintained --- which is a security risk.
The list of voters eligible to participate in an election is determined prior to the open of the election. It seems reasonable to require registration prior to the open of the election and this design minimizes the possibility of tricking the system into letting a person vote twice in an election (when it is not permitted).
Election results can be obtained from an election at any time. This is simply a set of all the ballots submitted thus far. It does not contain any user IDs. This object is then used to produce election tallies and statistical data without the risk of divulging sensitive information.
Election tallies are built from an ElectionResults object. Our SimpleElectionTalley just proclaims a winner for each category. More complicated talley objects could easy be added to the system.
Similar to Tallies, election statistics are built from ElectionResults objects. SimpleElectionStatistics simply reports the turnout rate for the election. However, more advanced statistical models can be implemented in this model.
The details of the role of election officers is not specified in this design. However, the infrastructure is in place. They use the UserIDs and authentication mechanism just like the voters. However, they would be granted additional options in the UI. These options include building new ballots and creating the associated elections. They are also able to control the eligible voters and election guards (detailed later in this document).
The election, ballot, category and option objects all have associated meta-data for voters to view. This data is handled by the info interface. All of these objects implement this info interface as a way of advertising in a general way that data is available to the users.
Authentication in our system is largely deferred. We provide an adapter interface for talking to a user database. It is assumed that the necessary data for validating users can be stored there. However, we do not explicitly specify what that data is. We do have objects that represent unique user identification numbers and also user authentication objects. These are required for voting in our system; they allow us to validate and track users. Furthermore, the adapter interface includes the functionality for registering new users.
Here is the documentation for the java skeleton code of our system. Collapsed UML for the entire system. The java skeleton code can be found here
The EligibleVoterFilter is an example of the strategy pattern. Each object that implements this interface is able to produce a set of voters eligible to vote in a specific type of election. For example, one such filter would produce the voters registered to vote in the state of North Carolina.
Another example of the strategy pattern is the ElectionGuard. This interface enforces rules external to any given election, but maintained between a set of elections. For example, we would like to ensure that voters are only eligible to vote in one state election. A guard to enforce this type of rule would take all state elections as input and output any voters listed more than once.
The voting system might be required to interface with multiple databases. For example, each state might have its own way of storing registration information. The DatabaseAdapter allows all of these databases to be accessed through a single common interface.
Our design has kept the elements of the ballot completely general. Using categories and options to represent these items allows our design to be used for many purposes. For example our design makes no reference to specific uses such as candidates and referendums.
Our info design is particularly noteworthy. Any object that requires meta-data implements the info interface so that there is one general way accessing any object's auxiliary information.
Category selections are not simply restricted to "choose only one." Instead, category selection may be choose one, choose all that apply, or rank the options. Furthermore, the design is such that the system can be extended to support new types of categories as need be.
There may be rules of the election that are out of the scope of the system. Our ElectionGuard is a tool that can be used to enforce these rules with minimal additional code and user parameters.
To get the best of both worlds, we've implemented two different types of elections. The first is a traditional approach where voters can only vote once and ballots are anonymous. The other type allows voters to alter their vote mid-election but is inherently a greater security risk.
Our current ballot design, as previously mentioned, only allows for two levels: categories and options. In different election scenarios, it might be useful to have multiple option sublevels. A good way to address this would be to use the composite pattern.
Our current tally scheme weights votes equally. If this online voting system was used for a shareholders' meeting, for instance, a different weighting of votes might be useful. While not currently supporting it, our design allows for the addition of such a feature.
Our system does not currently specify how the meta-data will be updated. The implemented version of our design would want to allow an election officer the control to add, edit, and delete such data while also allowing some users to have the privilege of editing some info fields. For example, a candidate in an election could alter their own info.
Our design does not have a good mechanism for reusing ballot designs. A reoccurring election might warrant such a mechanism to avoid unnecessary reconstruction.