EVoting SDS Document

Software Design Specification

UCCS Computer Science De-partment

CS701 - PROJECT

Online E-voting System

Submitted By: Hakan Eve-cekVersion 1.0

Description of Project

DOCUMENT NO: 2VERSION: 1.0

CONTACT: UCCSEMAIL: [email protected]

DATE: 4/7/2023

Distribution is subject to copyright.

Hakan Evecek Software Design Specification

DisclaimersThe information contained in this document is the proprietary and exclusive property of UCCS except as otherwise indicated. No part of this document, in whole or in part, may be reproduced, stored, transmitted, or used for design purposes without the prior written permission of UCCS.

The information contained in this document is subject to change without notice.

The information in this document is provided for informational purposes only. UCCS Computer Science Department specifically disclaims all warranties, express or limited, including, but not limited, to the implied warranties of merchantability and fitness for a particular purpose, except as provided for in a separate software license agreement.

Privacy InformationThis document may contain information of a sensitive nature. This information should not be given to persons other than those who are involved in the E-Voting Online Prototype Tool project or who will become involved during the lifecycle

Version History

REVISION CHART

Version Author(s) Description of Version Date Completed

1.0 Hakan Evecek Online E-voting System Software Design Specification version 1.0

03/27/2007

1.1 Hakan Evecek White-Box Design documents, database de-sign documents, use cases are updated

05/20/2007

Confidential - 05/25/07 Page 2


Document Owner

The primary contact for questions regarding this document is:

Author: Hakan Evecek

Project Name: Online E-Voting System

Phone: +612-5454-5454

Email: [email protected]

Document Approval

Document Name: Software Design Specification for Online E-Voting System

Publication Date: 05/11/2007

Contract Number: N/A

Project Number: 1.0.0

Prepared by: Hakan Evecek

Approval: __________________________

Name and Organization

Concurrence: _________________________

Name and Organization



Table of Contents:

SOFTWARE DESIGN SPECIFICATION.........................................................................1

TABLE OF CONTENTS:................................................................................................. 4

DETAILED DOCUMENT DESCRIPTION.......................................................................6

1. INTRODUCTION................................................................................................ 6Purpose:..................................................................................................................................... 6Document Overview.................................................................................................................... 6Scope.......................................................................................................................................... 6Revision History......................................................................................................................... 7References.................................................................................................................................. 7Additional References................................................................................................................. 7Methodology, Tools and Techniques...........................................................................................7Key Stakeholders........................................................................................................................ 7Points of Contact........................................................................................................................ 7Definitions, important terms, acronyms, or abbreviations...........................................................8

1.1 OVERVIEW OF DOCUMENT....................................................................................82. SYSTEM OVERVIEW......................................................................................... 93. DESIGN CONSIDERATIONS...............................................................................9

Assumptions and Dependencies...................................................................................................9Related software or hardware.....................................................................................................9End-user characteristics...........................................................................................................10General Constraints.................................................................................................................. 10Goals and Guidelines................................................................................................................ 12Call-return Development style..................................................................................................12

4. ARCHITECTURAL STRATEGIES:......................................................................14Design Patterns Description.....................................................................................................15Documentation.......................................................................................................................... 15Domain knowledge.................................................................................................................... 15Environmental constraints:.......................................................................................................16

5. SYSTEM ARCHITECTURE................................................................................17Use cases from the SRS Document............................................................................................18

5.2.1 Use Case 1 Specification...........................................................................................18Use Case #1 Diagram............................................................................................................... 195.2.2 Use Case 2 Specification..................................................................................................20

5.2.3 Use Case 3 Specification:..........................................................................................225.2.4 Use Case 4 Specification:..........................................................................................245.2.5 Use Case 5 Specification:..........................................................................................265.2.6 Use Case 6 Specification:..........................................................................................285.2.7 Use Case 7 Specification:..........................................................................................305.2.8 Use Case 8 Specification:..........................................................................................32

6. POLICIES AND TACTICS:.......................................................................................346.1 State Design Pattern:.....................................................................................................356.2 Visitor Design Pattern:..................................................................................................366.3 Strategy Design Pattern:................................................................................................37

7. DESIGN DOCUMENTS............................................................................................ 387.1 Black Box Design for E-Voting System – DFD...............................................................38

Classification..................................................................................................................... 38Definition........................................................................................................................... 38Responsibilities.................................................................................................................. 38Constraints......................................................................................................................... 38



Uses/Interactions................................................................................................................ 40Resources........................................................................................................................... 40Processing.......................................................................................................................... 40

7.1 White Box Design for E-Voting System – UML: Class Diagrams :.................................417.1.1 E-Voting System Classes......................................................................................42

8. Database Interface Requirements Specification for the E-Voting System...............................52Database Design and Tables Relations Diagram :.....................................................................52E-Voting System Tables............................................................................................................. 53UserLogin Table....................................................................................................................... 53Candidate Table........................................................................................................................ 53Elections Table......................................................................................................................... 53Ballots Table............................................................................................................................. 54Votes Table............................................................................................................................... 54SafePrimeNumbers Table..........................................................................................................54BallotList Table........................................................................................................................ 55Stored Procedures:................................................................................................................... 56

Glossary................................................................................................................... 59



Detailed Document Description

This section describes the contents of each section of the Software Design Specification.

1. Introduction

Purpose: This Software Design Specification (SDS) provides an overview of the pro-posed Online E-Voting system project design. It will encompass in detail the basic out-line of our project and represent a basis for the development process. This will also al-low critical analysis of the logical and functional aspects of the design before any com-mitment is made to actual code. Online E-voting system tool is a tool designed as a pro-totype to demonstrate the functionality of Pailler Threshold Crytptosystem (PTC). We will also consider some additional security concerns during the design process.

Document Overview

Below is the outline of the each section described in this document.

Chapter 1 – Document Description

Chapter 2 - System Overview

Chapter 3 – Design Considerations

Chapter 4 – Architectural Strategies

Chapter 5 – System Architecture (Use Cases from SRS)

Chapter 6 – Policies and Tactics

Chapter 7 - Design Documents

o Black Box Design

o White Box Design

o Database Design

Scope:

The scope of the design document is to illustrate the functionality of Pailler Thresh-old Cryptosystem. This prototype e-voting tool is an online tool. It will use the Pail-lier Threshold Cryptography Web Service and Paillier Threshold CryptoService-Provider in such an online voting system scenario.

The design document will also show interactions between the web services, between different forms used by both voters and administrators who are the main actors in the design.

SDS will be used by the project manager and the development team.

Revision History

Date Revision Description Author



04/06/2007 1.0.0 Initial version Hakan Evecek

05/22/2007 1.0.1 SDS for E-Voting System Hakan Evecek

References:

Online Reference and Printed Materials

Classical and Object-Oriented Software Engineering with UML and Java, 4th edition, Stephen R. Schach, McGraw-Hill, 1999.

Paillier Threshold Cryptosystem web services, Mr. Brett Wilson, http://cs.uccs.edu/~chow/

Additional References:

Dr Edward Chow, UCCS (Client), Colorado Springs, CO.

Methodology, Tools and Techniques

Word document, Visio diagrams and Enterprise Architecture 6.5.8 are the tools used to create this design document. Use cases and UML diagrams are created to describe the scenarios.

Key Stakeholders

Project stakeholders are below:

Prof. Dr. Edward Chow, UCCS (client)

Mr. Brett Wilson, Graduated Masters Student and also designer and creator of PTC web services.

Mr. Hakan Evecek, creator of online PTC Web Services prototype tool.

Points of Contact

Prof. Dr. Edward Chow, UCCS (client)

Definitions, important terms, acronyms, or abbreviations:


http://cs.uccs.edu/~chow/


GUIGraphical User Interface - a visually based application that serves to pro-vide an interactive medium between the user and the application.

SRSSoftware Requirements Specification - the explicit requirements defini-tion used to maintain product consistency during the development process

Web site

A hierarchy of linked HTML-encoded text files that display on a web browser as a series of related text pages with embedded graphics and con-trols

DFD Data Flow Diagram

1.1 Overview of Document

Section 1.0 introduces the project. Section 2.0 provides an abstract view of the system ar-chitecture, including the components, structure and relationships, and user interfaces. Section 3.0 describes each of these components in more detail, including design and ar-chitectural decisions. Section 4.0 explores the relationships to other products. Section 5.0 discusses design decisions, tradeoffs, and the reasoning behind these decisions. Section 6.0 is reserved for policies and tactics. It also discusses design patterns that can be ap-plied. Section 7.0 has detailed diagrams. It has both black box model and white box model.



2. System Overview

Module Description

User Login Form

The starting page which asks for login credentials. Also user is ex-pected to type the text shown in the image to make sure that human interaction is in place. In other words, there is not automatic soft-ware or script trying to access to the page.

Election FormAdministrator creates the elections and ballots for the voters. This is also the form where the users are added.

Help PageThe pages that provide the information to the Administrator and voters for the functionalities of the pages.

Tally FormContains the details of the vote results. This form also decrypts the encrypted votes.

Submitted Vote Form

This form displays the summary of the voter’s successful submis-sion.

3. Design Considerations

This section describes many of the issues which need to be addressed or resolved before attempting to devise a complete design solution.

Assumptions and Dependencies

The diagrams in this document were created through Visio Diagram or by the Enterprise Architect version 6.5.8. Enterprise Architect is a great tool for creating UML diagrams especially for school project. Trial version can be downloaded from http://www.sparxsystems.com/

Related software or hardware

This program will be coded in Visual Studio 2005. We will be using Visual basic and SQL Server 2005 for databases. Preferred operating system is Windows 2003 server. Windows 2000 server creates some exception errors that need to be researched and fixed if this is the preferred environment.


http://www.sparxsystems.com/


End-user characteristics

1- Voter - The users for the e-voting system.

2- Network – the LAN that exists between the two machines that will be involved in this system.

3- Administrator – One of the users of the e-voting system. This user creates elec-tions.

4- Internet – the internet connection of the user’s machine to be able to use the e-voting online tool.

General Constraints

1) Hardware or software environment

There is a web server requirement. Windows 2003 is the preferred operating system due to the security requirements. ASP .Net 2.0 Framework needs to be installed.

2) End-user environment

Administrator and voter should have network and internet connectivity. They will need to login with their user credentials to be able to use the e-voting system.

3) Availability or volatility of resources

This depends on the network and internet connection. Election process will be done via online. Stability and availability can be measured with the number of failures on the internet connection.

4) Standards compliance

None

5) Interoperability requirements

None

6) Interface/protocol requirements

Network connectivity and TPC/IP support are required.

7) Data repository and distribution requirements

Data will be stored in the database and Web services will be used to store the en-crypted data. Stored procs will be used in some functions. By doing all the connec-tions via stored procs can limt the access to the databases to the stored proc level.

8) Security requirements (or other such regulations)

Paillier Cryptograhy will be used. It is important to have a secure web site, user cre-dentials and secure web servers hosting PTC Web services and online forms.

9) Memory and other capacity limitations

5MB/10MB HDD space is required.

10) Performance requirements



No internal failures are acceptable. The only known and accepted failures are from the network or Internet connection that is providing the communication between the two machines.

11) Network communications

Network should be up all the time as part of the functionality is to be able to use the e-voting tool on the network or internet.

12) Verification and validation requirements (testing)

Two machines on the same network are required to be able to test and verify the net-work and internet functionality.

13) Other means of addressing quality goals

None

14) Other requirements described in the requirements specification

a) Online User Documentation and Help System Requirements The instructions for PTC Web services can be found online at: http:// cs.uccs.edu/~gsc/pub/master/hevecek/docs

b) Design ConstraintsNone.

c) Purchased ComponentsEnterprise Architecture 6.5.8 version tool is purchased for both SRS and SDS.

d) Interfacesi) User InterfacesOnline application and user interface will be designed with APS .Net tools avail-bale.

ii) Hardware InterfacesWeb Server needs to be installed and configured.

iii) Software InterfacesSQL Server 2005 is required for the databases.

iv) Communications InterfacesPaillier Threshold Cryptosystem web services, databases will be communicated via online.

e) Licensing RequirementsLicensing requirements are the same as the licensing requirements for a Visual Studio 2005 and SQL Server 2005.

f) Legal, Copyright, and Other NoticesNone.

g) Applicable StandardsNone.

Goals and Guidelines

15) Apply The KISS principle ("Keep it simple and straightforward!").


http://cs.uccs.edu/~gsc/pub/master/hevecek/docs


The eight requirements that identify for a good design which are well structured, sim-ple, efficient, adequate, flexible, practical, implementable and standardized are the guidelines to create this design.

16) Emphasis on speed versus memory use.

17) Working, looking, or "feeling" like an existing online application.

The goal of this project is to deliver the product completed on time. Use all the recom-mended models in the design document during coding. At the end we will demonstrate a prototype tool that uses PTC Web services.

Call-return Development style:

The concept of an ordered and hierarchical transfer of control from one processing ele-ment to another underpins this style. The call-and-return style places much greater em-phasis upon control aspects rather than upon data transfer issues. A call return style there-fore closely linked to the traditional program structuring form of main program and sub-programs. This is heavily used in PTC Web services and will be used on the online pro-totype application.

Feature Instantiation in call and return

Components Subprogram units, objects.

Connectors Subprogram invocation (calling), procedure calling.

Control of Execution Sequencing is controlled through the calling hierarchy and (in detail) the algorithms in the components.

Data Communication Data is passed via parameters and can also be accessed di-rectly.

Control/Data interaction This is relatively limited, beyond the linking of parameters and return inform within the calling stack.

Design reasoning Encourages use of a ‘top-down’ strategy, based upon func-tion. A design method such as the ‘traditional’ Structured Analysis / Structured Design will produce solutions that em-ploy this style.

The design method of the system is an important start. The used design method should help the designer to produce a system that is structured in a consistent way. The use of a design method both helps with defining the chosen architectural form and also establishes a set of common standards, criteria and goals for use by the team.

Black Box and white box diagrams of the models will be drawn for the design in the fol-lowing sections. The Data-Flow diagram can be one of the design diagrams used in our project. The DFD is mainly used for describing a very problem-oriented view of the workings of a system. It provides a description based on modelling the flow of informa-tion around a network of operational elements, with each element making use of or modi-fying the information flowing into that element. We would like to apply more view points to be able to define the system better for the developers. However we will concentrate on the constructional and the behavioral view



points. For the white box model, we will define each black box model with class dia-grams which is a core concept of the object model that is centered upon the relationships that involve classes and any objects that are created from these. Identification of candi-dates for classes is one of the primary activities in object oriented practices.



4. Architectural Strategies:

Architecture is the set of decisions that must be made at the enterprise level before spe-cific applications are designed and built in order to provide conceptual integrity and san-ity across the systems. Architecture includes a decomposition of the systems into separate orthogonal viewpoints along with the enforced rules that enable this clean decomposition and isolation of design viewpoints. This is done so functional (application requirements) and non-functional (system qualities) and other aspects of the application system may be defined and built by independent specialists in their specific field. An architecture not only divides the system, it also divides the roles and responsibilities of those who work with the system into separate organizational concerns and disciplines that are conceptu-ally tractable and can be effectively managed.

There are four architectural viewpoints: Behavioral, Constructional, Data Modeling, and Functional. In our project behavioral and functional viewpoints will be used to desing it. Additionally, constructional view point strategy can also be used.

Behavioral forms are essentially concerned with causal issues, connecting an event to a response via any necessary conditions. These forms tend to be far more abstract than the constructional class, which are usually concerned with compliable entities that have defi-nite syntax and semantics. Sequencing aspects can be described fairly well. Fixed-inter-nal descriptions are also fairly tractable, although their use is mainly restricted to particu-lar features of real-time systems. Constraint effects are very difficult to capture and de-scribe using existing forms of description. Behavioral description can be used for both black box modeling roles (considering how the system as a whole will respond to spe-cific events) and white box modeling (describing how the system elements will interact in terms of chains of events and actions). Overall, their importance and use has probably become much more pervasive as systems have become larger and also as constructional forms such as classes and objects have come into more widespread use.

Behavioral notations are dynamic properties where events, states, actions and conditions can be defined. Their relationships are modeled with cause & effect and sequencing & parallelism. Notation examples are state transition diagrams, statechart, UML: Use case diagram or UML: Activity Diagram.

Use cases for the project are provided in this document. They are in the next section where system architecture is defined.

Functional viewpoint shows the main functions of a system and their relations in terms of the flows of information, value or goods between them. The Function viewpoint provides high-level insight in the general operations of the system, and can be used to identify necessary competencies, or to structure according to its main activities.

For the black box design we can use Dataflow diagram (DFD) as mentioned above. DFD has design characteristics of information flow, dependency of operations on other operations and relation with data stores. It is mainly used for describing a very problem oriented view of workings of a system. It provides a description based on modeling the flow of information around a network of professional elements, with each element mak-ing use of modifying the information flowing into the element. It depicts processes (as bubbles) and the flow of data between them (as directed arcs). DFDs are usually orga-



nized into a hierarchy of nested diagrams, where a bubble on one diagram maps to an en-tire diagram at the next lower level of detail. DFDs do not depict conditional logic or flow of control between modules.

Constructional viewpoint is mainly concerned about describing how the various soft-ware-structuring forms provided in programming languages, markup languages in the systems. Constructional forms described by this viewpoint include: data specifications, threads of execution, packaging constructs, invocation and uses hierarchy which de-scribes the dependencies that exist between classes. For the white box model, additional to the use cases class diagrams will be drawn for the main classes used in this project.

Design Patterns Description:

The concept of the design pattern is very much associated with the object-oriented archi-tectural style, although in principle there are no reasons why patterns could not be em-ployed with other styles. The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of software development. Forming a common pattern language for con-veying the structures and mechanisms of our architectures allows us to intelligibly reason about them. Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution over without ever doing it the same way twice. In this project state, strategy and visitor desing patterns can be applied. The details of these desing patterns will explained in the following sections.

Documentation:

Documented set of procedures used in the system: Documentation of a system is impor-tant for both system development and its maintenance. The new team needs to under-stand the procedures used during the development so that they can implement the changes in the same way. This will keep the changes in the same structure. Also docu-menting the feature sets and how the game works needs to be done for users.

Domain knowledge

This needs to be defined. This information is needed to find out the type of the problem involved during the design and any implementation features. Experienced designers may often work in an opportunistic manner, but that this practice may be less well-formed and reliable when the designer is less familiar with a problem or its domain. So for the inex-perienced designer, or the designer who is working in an unfamiliar domain, the use of a design method may assist with the formulation and exploration of mental methods used to capture the essential features of the design. This way method knowledge may provide a substitute for domain knowledge, where the latter is inadequate or lacking. Addition-ally, classifying the problem domain will also help to understand the environment more.

In our case network and internet connections are involved in our domain. We need to consider all possibilites about the connection of machines to the network and internet. Voters should be able to access easily from the browser and complete the process.



Environmental constraints:

They need to be considered in our design: Most software designers believe that effective development of software relies on understanding unique constraints of each problem, and so universal notations are doomed because each provides a notational bias that necessarily makes the notation useless or dangerous for some set of tasks. There can always be constraints that effect the overall implementation and new changes that devel-oper needs to be aware of. So knowing this information and keeping this in mind during the new changes will definitely help the developer to deliver a better product. Especially setting up the permissions, giving access to the certifcates for the users in the voting sys-tem will be some of the constraints to be able to setup the environment. Voting system should be able to validate the user’s certifcates according to the design that will be pro-vided. Web services should be easiy accessed to be able to complete the e-voting process.

In our system one of the major constraints is the network and internet connectivity. With the recommended design patterns and the TCP/IP network protocol checks this con-neciton needs to be monitor during the voting process.Additonal security checks can also be part of the process to make sure that there are not any outsite attackers trying to use the systems.

Secure connections needs to be built. If the users are using their home PCs, secure con-nections might be established to do the voting. Secure ports and connections must be the requirement for the web server’s setup.

18) Use of a particular type of product (programming language, database, library, etc. ...)

There will be database involved in this system. SQL Server 2005 will be required. Visual studio 2005 Visual Basic ASP .Net environment wil be used for building the system.

19) Reuse of existing software components to implement various parts/features of the system

For additional features re-use of the forms is possible.

20) Future plans for extending or enhancing the software

This e-voting sstem is a basic prototype. More additional features can ve added if needed.

21) User interface paradigms (or system input and output models)

Administrators will be able to create elections, ballots etc. for voters to be able to lo-gin and vote. Creating these forms for the voters will create output XML files and voters will use them as input files.

22) Hardware and/or software interface paradigms

None

23) Error detection and recovery

Error detection and recovery will be done. To be able to separate error-handling code from the regular code, we will add exception errors in the code. For example,



Try

// Code

Catch ex As Exception

lblInfo.Text = "Error XXX. Exception Msg: " + ex.Message End Try

24) Memory management policies

Not required. However Sessions will be used to be able to pass the data from one form to another. This is for transferring data in ASP .Net environment.

25) External databases and/or data storage management and persistence

External databases are involved in the code and will be used to store election results.

26) Distributed data or control over a network

None

27) Generalized approaches to control

None

28) Concurrency and synchronization

None

29) Communication mechanisms

TCP/IP network communication is required as this application involves network and internet connectivity to connect to the e-voting online tool.

30) Management of other resources

The only additional resource that needs to be managed is the internet and network re-sources. The connecitity of the network and internet need to be checked frequently and throw error messages if there is any connection problem.

5. System Architecture

In this section high-level overview of how the functionality and responsibilities of the system were partitioned and then assigned to subsystems or components are provided. Detail about the individual components themselves will be discussed in the detailed de-sign part of this document.

E-Voting system will be an online tool using PTC Web services. It will have the ability to demonstrate the web services functionality. Customers will be able to create new elec-tion pages, ballots, save them and use them during our voting processes.

Users will be added with encryption if this option is enabled. In other words, users voting can have the encryption setup. This will add an additional security during the voting process.



Use cases from the SRS Document

5.2.1 Use Case 1 Specification:

Use Case ID: 1

Use Case Name: Access to Admin Page

Created By: Hakan Evecek Last Updated By: Hakan Evecek

Date Created: 03/14/2007 Date Last Updated: 04/15/2007

Primary Actors: Administrator

Secondary Actors: N/A

Description: This use case describes how to access to the Admin page.

Trigger: Administrator requires managing the Election pages.

Preconditions: Actor Network is idle. Actor internet is idle.

Actor Database is idle.

Postconditions: Administrator will have an admin page to be able to connect and man-age.

Normal Flow: Administrator logs in and connects to the Administrator page where he will have access to create a new election, modify an election, voting, tally and/or decrypt the votes. Connect to the network via actor network. Connect to the database via actor database.

Alternative Flows: None.

Exceptions: When there is a network problem create an error and report it .

When there is a database connectivity problem report the problem via Er-ror Messaging Technique.

Includes: None

Priority: High

Frequency of Use: High

Business Rules: None

Special Requirements: Only certain users can have access to this page. It will require adminis-trator privileges to open it.

Open Issues None

Assumptions: Server or desktop using online e-voting has a network and internet con-nection.

Notes and Issues: Any internet connection or network connection issue will cause access problems.



Use Case #1 Diagram:

uc Admin Page Use Cases

E-Voting System Admin Page

1. Access to Admin Page

Administrator

1a. Links for the Admin Pages

1b. Link for the Help Menu




Use Case ID: 2

Use Case Name: Login Page access



Primary Actors: Users

Secondary Actors: Network, Database, Error Messages.

Description: This use case describes how to access to the e-voting system.

Trigger: Login credentials will be required to login to the e-voting system.

Preconditions: Actor Network is Idle. Machine running the online e-voting tool. The database connection is idle. Internet connection is idle.

Postconditions: Internet connection is idle.

Normal Flow: User enters username and the password. The username and password are assigned and given to the users earlier. According to the username, sys-tem will connect the user to the Administrator page or directly to the vot-ing page. If user is the administrator, he will be connected to the admin page and will have access to the admin links.

Alternative Flows: None

Exceptions: Invalid data entry needs to be reported in the error logs with the Error Messages.

Includes: None

Priority: High



Special Requirements: Login credentials are valid and confirmed before the entry.

Open Issues None

Assumptions: Username and password are given to the users earlier.

Notes and Issues: Invalid usernames and passwords will not be logged in and will have er-ror pages displayed.




uc Login to the E-Voting System

Login Page

2a. Admin Credentials

2b. Voter Credentials

2. Login Page Access

Administrator




Use Case ID: 3

Use Case Name: Add User




Secondary Actors: N/A

Description: This use case describes how add a user from the Admin page for voters.

Trigger: Administrator requires managing the users for security reasons.

Preconditions: Actor Network is idle. Actor internet is idle.

Actor Database is idle.

Postconditions: Administrator will have an admin page to be able to connect and manage users.

Normal Flow: Administrator logs in and connects to the Administrator page where he will have access to create a new election. In the new election page he will have the option to add the users. Connect to the network via actor network. Connect to the database via actor database.


Exceptions: When there is a network problem create an error and report it .

When there is a permissions issue or other issues to assign the certificates for the users, report the issue with an error message.

Includes: None

Priority: High



Special Requirements: Only certain users can have access to this page. It will require adminis-trator privileges to open it.

Open Issues None

Assumptions: Server or desktop using online e-voting has a network and internet con-nection. User encryption keys are created prior and installed on the server by the Administrator.

Notes and Issues: Any internet connection or network connection issue will cause access problems. Any missing public keys for the users will cause issues to up-load the certificates.




uc Create a New User

Create a New User

3c. Check Encryption

3. Add Users

3a. Get Decryption Threshold Value

3b. Key Size for Encryption

Administrator




Use Case ID: 4

Use Case Name: Display Submitted Vote Details and Thank you message



Primary Actors: Voter

Secondary Actors: Web Server

Description: This use case defines accessing to the summary page after voting.

Trigger: User would like to get the summary of the voting on the results page.

Preconditions: Actor Network is idle. Actor internet is idle. Actor user has access to the voting pages.

Postconditions: None.

Normal Flow: Actor user uses the login page to access voting form. Voter does the vot-ing, finishes and clicks submit button. A message shows up the success-ful submission. Then there will be a button provided to check the voting details sent.


Exceptions: When there is a network problem create an error. If the voting didn’t go successfully, display a message on the check status page for the user.

Includes: None

Priority: High



Special Requirements: Users using the voting form will have access to this page after submitting the vote. Prior to submission this button will be disabled.

Open Issues None

Assumptions: Server or desktop using online e-voting has a network and internet con-nection. User submitted the vote to view the vote summary page.





uc Display the Submitted Vote

Voter

4a. Display Submited Vote Details

4b. Display a Thank you message

Admin Page Use Cases : Vote for the Election




Use Case ID: 5

Use Case Name: Create a new ballot




Secondary Actors: Ballot XML File

Description: This use case describes how to create a new ballot.

Trigger: Administrator requires managing the ballot creation pages.

Preconditions: Actor Network is idle. Actor internet is idle. Actor Database is idle. Ac-tor Ballot XML File can be saved to the default folder.


Normal Flow: Administrator logs in and connects to the Administrator page where he will have access to create a new ballot. Ballot creation pages will be ac-cessible from the election creation pages as well. After filling out the necessary fields in the form, Administrator will be able to save the ballot on the default folder where you will have access to add the ballots for the elections.


Exceptions: Creating the ballots will require both DB access and directory access to be able to write the data into XML. DB will be used just to store the bal-lots information.

Includes: None

Priority: High



Special Requirements: Only administrators can have access to this page. It will require adminis-trator privileges to open it.

Open Issues None

Assumptions: Default XML folder is setup and accessible. Database credentials were setup by the Admin on the web server.

Notes and Issues: Any internet connection or network connection issue will cause access problems to be able to create new ballots.




uc Create a New Ballot

Create a new Ballot

5a. Add Issue

5b. Add Choices

5c. Delete Choices

5d. Sav e Ballot

Ballot XML File

Administrator

5. Create a New Ballot




Use Case ID: 6

Use Case Name: Create a new Election



Primary Actors: Administrator, PTC Web Services

Secondary Actors: Election XML File, Database

Description: This use case describes the process for creating an election page.

Trigger: Administrator will need to have a page to be able to create, modify and post the elections.

Preconditions: Actor internet is idle. Default directory for saving the elections are acces-sible. PTC web Services are active on the web server.

Postconditions: Elections created are posted to be able to use for voting.

Normal Flow: Administrator will have access to the admin page where he will have a link for creating a new election page. Election pages can be a newly cre-ated one or an existing one. Ballots will be added from this page. Voters’ list needs to be entered by using this page as well. If the voter’s encryp-tion is enabled, necessary certificate will be loaded for the username en-tered.


Exceptions: When there is a network or internet connectivity problem create an error. Ballots folder, elections folder and the database connection errors will be displayed.

Includes: None

Priority: High



Special Requirements: Only Administrators can create the new elections.

Open Issues None


Notes and Issues: Any internet connection or network connection issue will cause access problems. Accessing problems to the default folder will cause issues to save the elections.




uc Create a New Election

Create a new Election

6a. Enter Election Details

Admin Page Use Cases : Create a New User

Admin Page Use Cases : Create a New Ballot

6b. Send Request

6d. Post Election

Database

Election XML File

6c. Sav e Election PTC Web Serv ices

Administrator

6. Create a New Election




Use Case ID: 7

Use Case Name: Tally / Decrypt Votes




Secondary Actors: Election XML File, Database

Description: This use case defines accessing to the Tally / decrypt votes pages.

Trigger: Administrator requires managing the Tally / Decrypt Votes pages. Ad-ministration group will be the only group who would access to this data.

Preconditions: Actor Network is idle. Actor internet is idle. Admin credentials are setup.


Normal Flow: Administrator logs in and connects to the Administrator page where he will have access to tally and/or decrypt the votes. Database connection will be required to be able to pull the data from the database. Database settings will be done from the settings files. The certificate detail for users will be pulled from the certificates list to be able to decrypt the vote details. Each users certificate will be pulled according to the user-name used to login. It is important to keep it the same when connected to the voting page. This can be transferred from the login to the voting page. Tally will be accurate if the voting is done successfully.


Exceptions: When there is a network problem create an error and report it. Database access errors will be reported.

Includes: None

Priority: High



Special Requirements: Only certain users can have access to this page. This data is the most cru-cial data and it is important to have a limited access.

Open Issues None






uc Tally / Decrypt Votes

Tally / Decrypt Votes

7a. Open an Election

7b. Display Election Details

7c. Display Votes Count for the Selected

Ballot

7d. Decrypt Votes

Database

Election XML File

Administrator

7. Tally / Decrypt Votes




Use Case ID: 8

Use Case Name: Vote for the Election



Primary Actors: Voter

Secondary Actors: PTC web Services, database, Election XML File

Description: This use case describes how to access to the Admin page.

Trigger: Voter will need to login to the Voter form for voting process.

Preconditions: Actor Network is idle. Actor internet is idle. Actor Database is idle. Voter has username and password assigned.

Postconditions: Submitted votes button is available for the voter to view the submitted vote summary.

Normal Flow: Voter logs in and connects to the Administrator page where he will have access to vote. Connect to this via actor internet. Connect to the database via actor database. User will choose the election from the list and open the election. After the election is chosen, user will highlight the ballot and choices to submit his/her votes.


Exceptions: Network and database connectivity issues.

Includes: None

Priority: High



Special Requirements: Any user that has login credentials setup by the admin will have access to the voting page.

Open Issues None

Assumptions: Voter has internet connection and user credentials setup.

Notes and Issues: Any internet connection or network connection issue will cause access problems to the e-voting system.




uc Vote for the Election

Online Voting

8a. Open an Election

8d. Submit Vote

Election XML File

8b. Vote for Each Question

8c. Display Your Vote

PTC Web Serv ices

8. Vote For the Election

Admin Page Use Cases : Display the Submitted Vote

Voter



6. Policies and Tactics:

1. Choice of which specific product to use (compiler, interpreter, database, library, etc. ...)

It will be coded in ASP .Net Framework 2.0 with Visual Basic. Visual Studio 2005 will be required to compile.

2. Engineering trade-offs

None.

3. Coding guidelines and conventions

Design Patterns will be used in the development. Visitor and State Desing patterns will be applied on some of the modules.

4. The protocol of one or more subsystems, modules, or subroutines

TCP/IP network communication needs to be established for network module design. It will be an online application where internet connection will be required.

5. The choice of a particular algorithm or programming idiom (design pattern) to implement portions of the system's functionality

Visitor and State Desing patterns will be applied on some of the modules. Strategy desing pattern can also be used.

6. Plans for ensuring requirements traceability

SRS document was provided and all the requirements specified in the document have been applied in the design. Also use cases are created to make sure that all the func-tionality will be defined in the functions according to the requirements.

7. Plans for testing the software

Al the feature set and needed requirements need to be tested with the scenarios cre-ated. An additional test document will be provided.

8. Plans for maintaining the software

Every Quarter bugs will be reviewed. Any reported problems will be fixed. This doc-ument will need to be updated if there are any new additional requirements involved.

9. Interfaces for end-users, software, hardware, and communications

E-Voting system will require end-users to have internet access, usr login credentials, PC and a browser.

10. Hierarchical organization of the source code into its physical components (files and directories).

Web server will be installed under “c:\InetPub\wwwroot\EVoting” folder. Web Ser-vices will be also in the same folder unser ThresholdService and VotingService fold-ers. They all need to be setup as a virtual web server. More details need to be pro-vided in the setup documents for the users.



11. How to build and/or generate the system's deliverables (how to compile, link, load, etc. ...)

Program will be compiled from the development machine and placed into the web server. Visual Studio 2005, SQL Server 2005 are the two main server application required to be able to run this web site.

Below are the Desing Patterns that can be considered to use in this project’s design:

6.1 State Design Pattern:

Allow an object to alter its behavior when its internal state changes. The object will ap-pear to change its class. Each pieces or tiles state will be changing when the players does their moves.

Suppose an object is always in one of several known states. The state an object is in de-termines the behavior of several methods. We could use if/case statements in each method. However it will be better solution to use state pattern.

We will need to have a reference to a state object. Normally, state object doesn’t contain any fields. Change state object will be created. Methods delegate to state object.

Below is the instance of the state pattern where it can be used. Network communication is another place where state pattern will be helpful to monitor the states.

State pattern can use singletons for instances of each state class. State objects don’t en-capsulate state, so can be shared. It is easy to add new states. New states can extend other states. It overrides only selected functions.



6.2 Visitor Design Pattern:

It represents an operation to be performed on the elements of an object structure. The visitor design pattern is a way of separating an algorithm from an object structure. Visi-tor lets you define a new operation without changing the classes of the elements on which it operates. In other words, a practical result of this separation is the ability to add new operations to existing object structures without modifying those structures.

The classes and/or objects participating in this pattern are: Visitor (Visitor): declares a Visit operation for each class of ConcreteElement in the ob-ject structure. The operation's name and signature identifies the class that sends the Visit request to the visitor. That lets the visitor determine the concrete class of the element be-ing visited. Then the visitor can access the elements directly through its particular inter-face. ConcreteVisitor (IncomeVisitor, VacationVisitor): implements each operation de-clared by Visitor. Each operation implements a fragment of the algorithm defined for the corresponding class or object in the structure. ConcreteVisitor provides the context for the algorithm and stores its local state. This state often accumulates results during the tra-



versal of the structure. Element (Element): defines an Accept operation that takes a visitor as an argument.ConcreteElement (Employee): implements an Accept operation that takes a visitor as an argument.ObjectStructure (Employees) can enumerate its elements. It may provide a high-level interface to allow the visitor to visit its elements. It may either be a Composite (pattern) or a collection such as a list or a set.

6.3 Strategy Design Pattern:

It defines a family of algorithms, encapsulates each one, and makes them interchange-able. Strategy lets the algorithm vary independently from clients that use it.

This can be also used in our project.

The classes and/or objects participating in this pattern are: Strategy (SortStrategy): declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy. Con-creteStrategy (QuickSort, ShellSort, MergeSort): implements the algorithm using the Strategy interface. Context (SortedList): is configured with a ConcreteStrategy object, maintains a reference to a Strategy object, may define an interface that lets Strategy ac-cess its data.



7. Design Documents

7.1 Black Box Design for E-Voting System – DFD

Black box design of the e-voting system is done with Data Flow diagram below. This DFD is created from the SRS document provided. If you click on the image below, link will open the visio diagram of the system or if you can not open the visio diagram with the link, visio diagram will be provided.

Classification Class diagrams are drawn for the classes used in this project. Operations and attributes are defined for each class.

Definition The specific purpose and semantic meaning of the component are below. This black box model is drawn by referring to the the requirements specification document. All the re-quirements are drawn in this diagram to make it clear for the developer. For additionals fucntionalities main level is divided into sub levels.

Responsibilities The primary responsibilities and/or behavior of the forms are:

User Login Form: This is the login form. Login credentials will be provided by the Ad-ministrator. According to the login credentials users will be connected either to the Ad-ministrator pages or voting pages.

Election Form: This form will be accessible only by the Administrators. They will be able to create the Elections through this form.

Ballots Form: This form also can be accessed only by the Administrators. Administrator can create new ballots for the election.

Tally / Decrypt Form: This form will decrypt the vote results and tally the votes. Sum-mary of the votes will be displayed on this form.

Submitted Votes Form: After submitting the votes, users will have the option to diplay the summary.

Voting Form: Voting Form is the Form where user can do the voting. This form can be accessed both by the voters and the Administrators.

Constraints There won’t be any constraints on completing this project. It will be completed on time.



Uses/Interactions



The interactions between the classes are defined in the class diagrams drawn below.

Resources

This is a server, client tool. Most of the functions will be running from the server and managed through the server. Election files and ballot files will be saved in XML format on the server. Below will be the directory structure for the web server.

According to the directory structure abovenewly created ballots will be saved in the bal-lots folder. Elections will be palced in the elections folder.

Additionally, Pre-computed Prime numbers will be saved in the PreComputation folder.

Lastly, OnlineEVotingPrototypeHelpMenu folder will have the entire help menu files hosted. Admin help files in this folder will be available to the Administrators only.

Processing Handling of exceptional conditions should be done in each module. All the scenarios that can cause errors need to be handled and not cause applications to crash. Error detection and recovery will be done. To be able to separate error-handling code from the regular code, we will add exception errors in the code. For example, use the following to print the stack trace.

catch (Exception e) {

//A (too) general exception handler. Output goes to lblInfoexceptions to display. Addi-tional messages can be added by the developer if needed. ...}



7.1 White Box Design for E-Voting System – UML: Class Diagrams :

For the white Box Model, class diagrams are used to define the modules mentioned in the DFD. Additionally Web services and 3rd party components used classes are also defined.

Below are class diagrams for the grid where we define all the pieces of the E-Voting sys-tem from the back box DFD. Data Flow Diagram for the black box model is chosen for this porject. One of the reasons why this was chosen is, it is easier to transfer to white box representation and also it is easier to define the levels. DFD provides a description based on modeling the flow of information around the elements. An important character-istic of DFD is that it can be expanded in a hierarchical fashion, with the operation of any bubble being described by means of a further DFD. I have chosen Class diagram for the whitebox: The class diagram defines a detailed design of the system. The class dia-gram classifies the actors defined in the use case diagram into a set of interrelated classes. The relationship or association between the classes can be either an "is-a" or "has-a" rela-tionship. Each class in the class diagram may be capable of providing certain functionali-ties. Class diagram is one of the forms that can be used to view the white box model which is detailed diagrams for each module in the program.



7.1.1 E-Voting System Classes

E-voting system classes are created from the DFD diagram drawn above.

Election Builder Form:



Encryption Builder Form



Voter Form:



Submmitted Vote Form:



Tally / Decrypt Form:



Ballot Builder Form:



Threshold Crypto Library Classes

Threshold Crypto Library classes are also created from the original source code created for PTC Web services.





Voting Services Library Classes

Voting Services Library classes are extracted from the original source code where the web services were created.



7.1.2 GMP Classes

GMP classes are also extracted from the source code created. As there are too many properties involved and image can not fit in an A4 size document, use the link below to access the class diagrams folders for GMP classes and all the other diagrams in this SDS document. http://cs.uccs.edu/~gsc/pub/master/hevecek/doc/diagrams


http://cs.uccs.edu/~gsc/pub/master/hevecek/doc/diagrams


8. Database Interface Requirements Specification for the E-Voting System

Database Design and Tables Relations Diagram :

BallotsBID

EID

BallotID

Issue

ElectionsEID

ElectionID

ElectionTitle

Administrator

VotesVID

BID

Voter

Vote

CandidateCID

BID

Name

VoteValueExp

Below are the design diagram for the user login and SafePrimeNumbers tables. User-Login table will be used for the user’s validation process. SafePrimeNumbers table will be used to get the prime numbers stored. These prime numbers will be calculated prior to the voting to minimize the load of the system and improve the efficiency.



E-Voting System Tables

UserLogin Table

This table is used to store the users login information for the election forms access and privilidges.

Attributes:

Integer, CID (Candidate ID) , This is the primary key for the table.

nvarchar(50) UserName

nvarchar(50), Password.

nvarchar(50) UserType. Either Admin or voter type.

nvarchar(50), SecurityNumber. To store a security key to validate the user.

Candidate Table

This table is used to store candidates’ information for the ballot choices.

Attributes:

Integer, CID (Candidate ID) , This is the primary key for the table.

Integer, BID ( Ballot ID)

varchar(150) Name, Candidate Name/Description

Integer, VateValurExp

Elections Table

This table is used to store Election details. Election Title, Election ID and Election Ad-ministrator are the data collected during the election creation process.

Attributes:

Integer, EID This is the primary key for the table



varchar(255), ElectionID, Election ID is one of the data created during the new election creation process and this ID is stored in the database.

varchar(255) ElectionTitle, is the field stored for the election details.

varchar(255), Administrator, is the field where Administrator name will be stored.

Ballots Table

This table is used to store ballots information for the ballot choices.

Attributes:

Integer, BID ( Ballot ID), This is the primary key for the table.

Integer, EID (Election ID)

varchar(255) BallotID

varchar(500), Issue is the field where Administrator can store ballot is-sue description.

Votes Table

This table is used to store votes information. Administrators will be able to access and count the votes from this table.

Attributes:

Integer, VID (Vote ID), This is the primary key for the table.

Integer, BID ( Ballot ID)

varchar(255) Voter, Voter description / Name

varbinary(256) Vote, will be stored in binary as this can be in encrypted format.

SafePrimeNumbers Table

This table is used to store P or Q Prime Numbers to be able to calculate prior to the process and increase the efficiency of the calculation.

Attributes:

Integer, SafePrimeNumberID , This is the primary key for the table.

Integer, KeySize, Key Size used to create the prime Number value

nvarchar(255) PrimeNumberValue, Calculated Prime Number Value will be saved in this field.

bit, SafePrimeNumberUsed, To find out if this prime number is used previously or not.

nvarchar(2), SafePrimeNumberType. Either P or Q value field.

BallotList Table



This table is used to store the ballots list to be able to save in a database with the ballot choices.

Attributes:

Integer, BallotID is the primary key for the table.

nvarchar(255) BallotIssue, Description of the issue for the ballot

nvarchar(255), ChoiceList, Choice List separated by commas.



Stored Procedures:

EVotingLogin

USE [Voting]GO/****** Object: StoredProcedure [dbo].[EVotingLogin] ******/SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOALTER PROCEDURE [dbo].[EVotingLogin]

@paramUserName nvarchar(50),@paramPassword nvarchar(50)

AS/* SET NOCOUNT ON */

select * from UserLogin where UserName = @paramUserName and Pass-word = @paramPassword

RETURN

GetVotersListUSE [Voting]GO/****** Object: StoredProcedure [dbo].[GetVotersList] ******/SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOALTER PROCEDURE [dbo].[GetVotersList]

/*(@parameter1 int = 5,@parameter2 datatype OUTPUT)*/

AS/* SET NOCOUNT ON */ select distinct Voter from Votes

RETURN

sp_AddBallotsIntoTheDatabaseUSE [Voting]GO/****** Object: StoredProcedure [dbo].[sp_AddBallotsIntoTheDatabase]*/SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOALTER PROCEDURE [dbo].[sp_AddBallotsIntoTheDatabase]



@paramBallotIssue nvarchar(255),@paramChoicesList nvarchar(255)

AS-- SET NOCOUNT ON added to prevent extra result sets from-- interfering with SELECT statements.SET NOCOUNT ON;

insert into BallotsList(BallotIssue, ChoicesList) values (@paramBallotIssue, @paramChoicesList) RETURN

sp_getBallotsToUse

USE [Voting]GO/****** Object: StoredProcedure [dbo].[sp_getBallotsToUse] ******/SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOALTER PROCEDURE [dbo].[sp_getBallotsToUse]

AS/* SET NOCOUNT ON */

RETURN

sp_GetPrimeNumbersAccordingToKeySize

USE [Voting]GO/*** Object: StoredProcedure [dbo].[sp_GetPrimeNumbersAccordingToKey-Size] **/SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOALTER PROCEDURE [dbo].[sp_GetPrimeNumbersAccordingToKeySize]

@paramKeySize int

AS/* SET NOCOUNT ON */ select * from SafePrimeNumberswhere KeySize = @paramKeySize RETURN

sp_NewRandomPrimeNumbers

USE [Voting]GO/****** Object: StoredProcedure [dbo].[sp_NewRandomPrimeNumbers]*/SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGO



ALTER PROCEDURE [dbo].[sp_NewRandomPrimeNumbers]@paramKeySize int,@paramSafePrimeNumberValue nvarchar(255),@paramGetSafePrimeUsed bit,@paramPrimeNumberType nvarchar(2)

AS

-- SET NOCOUNT ON added to prevent extra result sets from-- interfering with SELECT statements.SET NOCOUNT ON;

insert into SafePrimeNumbers(KeySize,PrimeNumberValue,SafePrimeNumberUsed,SafePrimeNumberType) values (@paramKeySize,@paramSafePrimeNumberValue,@paramGet-

SafePrimeUsed,@paramPrimeNumberType ) RETURN

sp_TruncatePrimeNumbersTable

USE [Voting]GO/** Object: StoredProcedure [dbo].[sp_TruncatePrimeNumbersTable] */SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOALTER PROCEDURE [dbo].[sp_TruncatePrimeNumbersTable] ASBEGIN

-- SET NOCOUNT ON added to prevent extra result sets from-- interfering with SELECT statements.SET NOCOUNT ON;

Truncate table SafePrimeNumbers

END



Glossary

SRS: Software Requirements Specification

SDS: Software Design Specification

DFD: Data Flow Diagram

GUI: Graphical User Interface


Date post:	22-Sep-2014
Category:	Documents
Upload:	kahfulwara-muhammad
View:	117 times
Download:	2 times