Post on 22-Sep-2014
transcript
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: hevecek@uccs.edu
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
Hakan Evecek Software Design Specification
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: hevecek@uccs.edu
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
Confidential - 05/25/07 Page 3
Hakan Evecek Software Design Specification
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
Confidential - 05/25/07 Page 4
Hakan Evecek Software Design Specification
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
Confidential - 05/25/07 Page 5
Hakan Evecek Software Design Specification
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
Confidential - 05/25/07 Page 6
Hakan Evecek Software Design Specification
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:
Confidential - 05/25/07 Page 7
Hakan Evecek Software Design Specification
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.
Confidential - 05/25/07 Page 8
Hakan Evecek Software Design Specification
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.
Confidential - 05/25/07 Page 9
Hakan Evecek Software Design Specification
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
Confidential - 05/25/07 Page 10
Hakan Evecek Software Design Specification
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!").
Confidential - 05/25/07 Page 11
Hakan Evecek Software Design Specification
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
Confidential - 05/25/07 Page 12
Hakan Evecek Software Design Specification
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.
Confidential - 05/25/07 Page 13
Hakan Evecek Software Design Specification
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-
Confidential - 05/25/07 Page 14
Hakan Evecek Software Design Specification
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.
Confidential - 05/25/07 Page 15
Hakan Evecek Software Design Specification
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,
Confidential - 05/25/07 Page 16
Hakan Evecek Software Design Specification
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.
Confidential - 05/25/07 Page 17
Hakan Evecek Software Design Specification
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.
Confidential - 05/25/07 Page 18
Hakan Evecek Software Design Specification
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
Confidential - 05/25/07 Page 19
Hakan Evecek Software Design Specification
5.2.2 Use Case 2 Specification:
Use Case ID: 2
Use Case Name: Login Page access
Created By: Hakan Evecek Last Updated By: Hakan Evecek
Date Created: 04/24/2006 Date Last Updated: 04/24/2006
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
Frequency of Use: High
Business Rules: None
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.
Confidential - 05/25/07 Page 20
Hakan Evecek Software Design Specification
Use Case #2 Diagram:
uc Login to the E-Voting System
Login Page
2a. Admin Credentials
2b. Voter Credentials
2. Login Page Access
Administrator
Confidential - 05/25/07 Page 21
Hakan Evecek Software Design Specification
5.2.3 Use Case 3 Specification:
Use Case ID: 3
Use Case Name: Add User
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 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.
Alternative Flows: None.
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
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. 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.
Confidential - 05/25/07 Page 22
Hakan Evecek Software Design Specification
Use Case #3 Diagram:
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
Confidential - 05/25/07 Page 23
Hakan Evecek Software Design Specification
5.2.4 Use Case 4 Specification:
Use Case ID: 4
Use Case Name: Display Submitted Vote Details and Thank you message
Created By: Hakan Evecek Last Updated By: Hakan Evecek
Date Created: 03/14/2007 Date Last Updated: 04/15/2007
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.
Alternative Flows: None.
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
Frequency of Use: High
Business Rules: None
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.
Notes and Issues: Any internet connection or network connection issue will cause access problems.
Confidential - 05/25/07 Page 24
Hakan Evecek Software Design Specification
Use Case #4 Diagram:
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
Confidential - 05/25/07 Page 25
Hakan Evecek Software Design Specification
5.2.5 Use Case 5 Specification:
Use Case ID: 5
Use Case Name: Create a new ballot
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: 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.
Postconditions: None.
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.
Alternative Flows: None.
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
Frequency of Use: High
Business Rules: None
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.
Confidential - 05/25/07 Page 26
Hakan Evecek Software Design Specification
Use Case #5 Diagram:
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
Confidential - 05/25/07 Page 27
Hakan Evecek Software Design Specification
5.2.6 Use Case 6 Specification:
Use Case ID: 6
Use Case Name: Create a new Election
Created By: Hakan Evecek Last Updated By: Hakan Evecek
Date Created: 03/14/2007 Date Last Updated: 04/15/2007
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.
Alternative Flows: None.
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
Frequency of Use: High
Business Rules: None
Special Requirements: Only Administrators can create the new elections.
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. Accessing problems to the default folder will cause issues to save the elections.
Confidential - 05/25/07 Page 28
Hakan Evecek Software Design Specification
Use Case #6 Diagram:
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
Confidential - 05/25/07 Page 29
Hakan Evecek Software Design Specification
5.2.7 Use Case 7 Specification:
Use Case ID: 7
Use Case Name: Tally / Decrypt Votes
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: 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.
Postconditions: None.
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.
Alternative Flows: None.
Exceptions: When there is a network problem create an error and report it. Database access errors will be reported.
Includes: None
Priority: High
Frequency of Use: High
Business Rules: None
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
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.
Confidential - 05/25/07 Page 30
Hakan Evecek Software Design Specification
Use Case #7 Diagram:
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
Confidential - 05/25/07 Page 31
Hakan Evecek Software Design Specification
5.2.8 Use Case 8 Specification:
Use Case ID: 8
Use Case Name: Vote for the Election
Created By: Hakan Evecek Last Updated By: Hakan Evecek
Date Created: 03/14/2007 Date Last Updated: 04/15/2007
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.
Alternative Flows: None.
Exceptions: Network and database connectivity issues.
Includes: None
Priority: High
Frequency of Use: High
Business Rules: None
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.
Confidential - 05/25/07 Page 32
Hakan Evecek Software Design Specification
Use Case #8 Diagram:
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
Confidential - 05/25/07 Page 33
Hakan Evecek Software Design Specification
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.
Confidential - 05/25/07 Page 34
Hakan Evecek Software Design Specification
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.
Confidential - 05/25/07 Page 35
Hakan Evecek Software Design Specification
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-
Confidential - 05/25/07 Page 36
Hakan Evecek Software Design Specification
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.
Confidential - 05/25/07 Page 37
Hakan Evecek Software Design Specification
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.
Confidential - 05/25/07 Page 38
Hakan Evecek Software Design Specification
Uses/Interactions
Confidential - 05/25/07 Page 39
Hakan Evecek Software Design Specification
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. ...}
Confidential - 05/25/07 Page 40
Hakan Evecek Software Design Specification
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.
Confidential - 05/25/07 Page 41
Hakan Evecek Software Design Specification
7.1.1 E-Voting System Classes
E-voting system classes are created from the DFD diagram drawn above.
Election Builder Form:
Confidential - 05/25/07 Page 42
Hakan Evecek Software Design Specification
Encryption Builder Form
Confidential - 05/25/07 Page 43
Hakan Evecek Software Design Specification
Voter Form:
Confidential - 05/25/07 Page 44
Hakan Evecek Software Design Specification
Submmitted Vote Form:
Confidential - 05/25/07 Page 45
Hakan Evecek Software Design Specification
Tally / Decrypt Form:
Confidential - 05/25/07 Page 46
Hakan Evecek Software Design Specification
Ballot Builder Form:
Confidential - 05/25/07 Page 47
Hakan Evecek Software Design Specification
Threshold Crypto Library Classes
Threshold Crypto Library classes are also created from the original source code created for PTC Web services.
Confidential - 05/25/07 Page 48
Hakan Evecek Software Design Specification
Confidential - 05/25/07 Page 49
Hakan Evecek Software Design Specification
Voting Services Library Classes
Voting Services Library classes are extracted from the original source code where the web services were created.
Confidential - 05/25/07 Page 50
Hakan Evecek Software Design Specification
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
Confidential - 05/25/07 Page 51
Hakan Evecek Software Design Specification
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.
Confidential - 05/25/07 Page 52
Hakan Evecek Software Design Specification
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
Confidential - 05/25/07 Page 53
Hakan Evecek Software Design Specification
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
Confidential - 05/25/07 Page 54
Hakan Evecek Software Design Specification
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.
Confidential - 05/25/07 Page 55
Hakan Evecek Software Design Specification
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]
Confidential - 05/25/07 Page 56
Hakan Evecek Software Design Specification
@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
Confidential - 05/25/07 Page 57
Hakan Evecek Software Design Specification
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
Confidential - 05/25/07 Page 58
Hakan Evecek Software Design Specification
Glossary
SRS: Software Requirements Specification
SDS: Software Design Specification
DFD: Data Flow Diagram
GUI: Graphical User Interface
Confidential - 05/25/07 Page 59