An Internet Voting System Manager

1. An Internet Voting System Manager Yonghua Li Kansas State University March 28, 2002 MSE Project - Phase 2

2. Give my thanks to: Dr. Maria Zamfir-Bleyberg Dr. William Hsu Dr. David Gustafson

3. Presentation Overview Project Overview Prototype: GUI Project Design: Object Model Formal Specification Test Plan Formal Technical Review (FTR) Software Quality Assurance (SQA) Summary and Question

4. Project Review: Goals • To design an internet voting system where voters can cast ballots through internet; • To test some approaches on internet voting system; • Also to improve the integrity and fairness of voting

5. Project Review: Components • Emphasis on two components • IVS manager (IVSM) (sever side) • Voter (client side) • Integration with other components, e.g., database

6. Basic Functions of IVSM • Administrator login setup • login id – administrator’s ID; • password – administrator’s password; • Database setup • Candidate list database; • Voter database; • Voting period setup • Start time; • Stop time;

7. Basic Functions of IVSM (Cont’d) • Server initializing; • Ballot counting – doing statistics on the voting ballots.

8. Basic Functions of the Server • Idling – waiting for visit; • Querying – getting ballots for the requested election title from the database; • Caching – storing data and making them available to querying; • Uploading – sending required blank ballots to client.

9. Basic Functions of Client • Login • providing voter ID and password; • downloading a blank ballot; • Voting – casting the ballot.

10. Prototype: GUI (Server Side)

11. Prototype: GUI (Client Side)

12. Object Model: IVSM

13. Object Model: Client

14. Sequence Diagram for Server Side

15. Sequence Diagram in Client Side

16. Formal Specification: USE-Class • model IVSM • -- Class • class Administrator • attributes • password:String • operations • verifyPassword(password:String):boolean • end • class ConnectionPool • end • class ConnManager • end • class QueryWrapper • end • class Ballot • attributes • candidates:String • end • class CommCandidate • end • class ServerProtocol • end • class ConnServer • end

17. Formal Specification: USE-association • association session between • ConnServer[1] role connserver • ConnClient[1] role connclient • end • association admin between • Administrator[1] role manager • IVSM[1] role system • end • association service between • Server[1] role server • IVSM[1] role system • end • association mediator between • QueryWrapper[1] role wrapper • IVSM[1] role system • end • association pool between • ConnectionPool[1] role poolsink • ConnManager[1] role handler • end • association connQuery between • QueryWrapper[1] role wrapper • ConnManager[1] role handler • end • association thread between • Server[1] role server • ConnServer[*] role connserver • end • association cache between • ConnServer[1] role connserver • Ballot[*] role ballot • end • association xmlhandler between • ConnServer[1] role connserver • ServerProtocol[1] role xmlprocess • end

18. Formal Specification: USE-Constraints • context Administrator::VerifyPassword(psword : String) : boolean • pre passwordNotNull:psword.isdefined() • post resultPost: • result = self.password.equals(psword) • context IVSM • -- Over time must be greater than Start time • inv overtimeGreaterthanstart: • self.startTime < self.overTime • context Server • -- system is ready before it can accept the request • inv systemready: • self.connserver.isdefined() implies self.system.isdefined() • context ConnServer • -- every ConnServer must have its own ConnClient • inv connServerClientPair: • ConnServer.allInstances->forAll(c1,c2:ConnServer|c1<>c2 implies (c1.connclient<>c2.connclient)) • -- every ConnServer belongs to the same Server • inv connServerHasSameServer: • ConnServer.allInstances->forAll(c1,c2:ConnServer|c1.server=c2.server) • -- Ballot on request • inv ballotOnRequest: • self.ballot.isdefined() implies (self.ballot.size = 1 && self.connclient.isdefined()) • -- QueryWrapper is ready before ballot is ready. • self.ballot.isdefined() implies (self.server.system.wrapper.isdefined() • context ConnClient • -- ConnClient set up a connection before receive a ballot • inv connFirst: • self.ballot.isdefined() implies self.connserver.isdefined() • -- ConnClient receives ballot after ConnServer gets it ready • inv ballotready: • self.ballot.isdefined() implies self.connserver.ballot.isdefined() • -- ballot ConnClient received is the one its ConnServer sent • inv sameballot: • self.ballot.candidates.equals(self.connserver.ballot.candidates)

19. Test Plan • Unit Testing: • each class is tested separately. Focus on major functions in each class • Integration Testing • tests the program structure, the program is built with unit-tested modules. • System Testing: Performance Testing • Stress testing • Boundary testing

20. Test Plan: Test Case • Stress Testing: - From the same machine, keep sending a number of connecting requests to the server to test the performance • Boundary testing: - Sending the server some special characters, eg !~#@()+_-=\|$%* • Authentic testing: - testing voter id, password, registering code

21. Test Plan: Test Case (Cont’d) • Error Handling Testing: - The error handling testing case will test if the server and client will show the right feedback • Log Handling Testing: - This type of testing case will check if the log system will works well when the system run. • Voting Period Testing - Voting period testing will check if the server will accept connection in the right time.

22. Prototype: Test Suite GUI

23. Formal Technical Review (FTR) • Software Formal Inspection Process Standard NASA-SYD-2202-93 • Ensure consistency between previously approved documents of phase I and the new design concepts resulting from documents of phase II • In this project, the system design will be subjected to the FTR. A formal checklist will be developed and used to inspect the document

24. FTR: Checklist Check list * Completeness * Modifiability * Consistence * Tracebility * Correctness * Understandability * Feasibility * Maintainability * Verifiability * Testability

25. Software Quality Assurance Plan (SQA) • IEEE standard Std 730-1989 • Software Quality Assurance Plan documents a plan, which assures the quality of the software during the whole life cycle of the software. • Including Purpose, Reference, Management, Documentation, Standards Practices Conventions and Metrics, Review and Audit, Tools Techniques and Methodologies,Code Control, Training, Risk Analysis

26. Phase III – Implementation • User Manual • Source Code • Formal Technical Review • Testing & Reliability Evaluation • Project Evaluation

27. Summary • Project Overview • Project Design: Object Model • Formal Specification • Test Plan • Formal Technical Review (FTR) • Software Quality Assurance (SQA) • URL: http://www.cis.ksu.edu/~yli3568/mse/mse.html

28. Thank!