Skip to content
Martinnikoltchev edited this page Aug 13, 2013 · 5 revisions

Usage

Compiling and running the supervisor is easily accomplished by building an artifact. In The InteliJ IDEA IDE go to Build -> Build Artifacts... -> Votebox

The jar will then be compiled and automatically pull in the /path/to/starvote/STAR-Vote/out/Votebox as Votebox.jar

With the jar built, you can simply cd to the jar directory and :

$ java -jar Votebox.jar [serial number] ###Summary and Module Definition

In this document we define specification for the user interface module of the VoteBox voting machine. By "user interface," we mean the module which defines all behaviors that relate to a single voter's interaction with the machine. This notably includes those behaviors which produce the visual software controls which a voter may interact with in order to record his preference in an election, as well as the behavior that creates immutable cast ballots that other parts of the system use. The user interface module keeps no state between voting sessions (where a single voting session is defined as the interval of time where a single voter uses the software to record his preferences in an election). In fact, a different instance of this module is created for every unique voter, and, throughout the software's run time, at most, one instance of this module exists at any single point in time.

###Aside It is important to note that in the domain of human factors testing, the only relevant module is this one. As a consequence of this, all human factors research related design goals are specified here. Because the goals that we have specified for human factors research are, in some cases, necessarily in conflict with those that we have specified for security research, the parts of this document that are explicitly stated as only beneficial to human factors research can be assumed to be left out of any version which we propose should be placed under the scrutiny of an expert in computer security. Because the user interface module (which we will abbreviate UI) defines the parts of the software which directly affect the voter's experience, it is useful (towards the goal of a definition for this module) to give a concise description of what a voter should expect when he interacts with our machine. The voter will be able to use hardware controls to select candidates, navigate the ballot, and cast a finished ballot. Our design allows for flexibility in which hardware controls are used in an implementation. (For example, touch screens, scroll wheels, and arrow keys are reasonable solutions.) While at the machine, the voter will be presented with a series of screens. First, he will navigate through screens which will explain the election. Next, he will be presented with a series of races in which he can vote. After he votes, he will be presented with a summary screen which will allow him to confirm that the machine has accurately recorded his preferences in the races in which he can vote. Finally, the user will confirm his vote, the ballot will be cast, and the machine will appear to "restart" (as the UI module will be thrown away and recreated for the next voter).

The UI will be independently constructed by the [:VoteBoxBackend:Back End] module) for each individual voter who comes into contact with the machine, and will only exist in memory while the voter is interacting with the machine. When the voter declares his intent to cast his ballot, the modules we define here will convey the ballot state to another module in a form that is immutable. The driver component will then release all references to the mutable ballot.

THIS NEEDS TO BE RETHOUGHT AND POSSIBLY PLACED ELSEWHERE The modules we define here will interact as follows (ADD A DIAGRAM). The hardware with which the voter will interact will trigger events in the view. The view's job is simply to display screens to the voter and accept the voter's input. This view will have been constructed by a view manager, whose job is to control all the changes in the view which happen in response to user interface events. The view manager will respond to events by asking the view to change what is being displayed on the screen. A new view manager (and corresponding view) is constructed by the user interface driver every time a new vote session is started. When the voter communicates his intent to cast his ballot, the view manager will ask the ballot to create an immutable representation of itself, which it will hand to the user interface driver. The user interface driver will then release its reference to the view manager, and pass the cast ballot to the vote recording module.

Clone this wiki locally