Downloaded 2,669 times
![class should be relatively self-contained (generally using
encapsulation). Collectively, the properties and methods
defined by a class are called members.
Object
An instance (that is, an actual example) of a class. Example 1:
The class Voter is a pattern or blueprint for candidate objects
by listing the characteristics and behaviors they can have; the
object Ahmed is one particular candidate.
Instance
One can have an instance of a class; the instance is the actual
object created at run-time. In programmer vernacular, the
Ahmed object is an instance of the voter class. The set of
values of the attributes of a particular object is called its state.
The object consists of state and the behavior that's defined in
the object's class.
Method
An object's abilities. In language, methods (sometimes referred
to as "functions") are verbs. Ahmed, being a voter, has the
ability to submit a vote So submit () is one of Ahmed's methods.
He may have other methods as well, for example Login().
Within the program, using a method usually affects only one
particular object; all voters can submit a vote, but you need
only one voter to submit one vote.
Message passing
"The process by which an object sends data to another object
or asks the other object to invoke a method."Also known to
some programming languages as interfacing. For example, the
object called AdminClerk may tell the Ahmed object to apply by
passing a "submit" message which invokes Ahmed's "submit"
method. The syntax varies between languages, for example:
[Ahmed submit] in Objective-C. In Java, code-level message
passing corresponds to "method calling". Some dynamic
languages use double-dispatch or multi-dispatch to find and
pass messages.
Inheritance
"Subclasses" are more specialized versions of a class, which
inherit attributes and behaviors from their parent classes, and
can introduce their own.
For example, the class person might have sub-class called
Page 21](https://image.slidesharecdn.com/e-votingver2-1-3-110727074342-phpapp02/85/E-voting-21-320.jpg)
![3 tier Architecture 1
Web Application
In system software, a web application is an application that is
accessed over a network such as the Internet or an intranet.
The term may also mean a computer software application that
is hosted in a browser-controlled environment (e.g. a Java
applet)[citation needed] or coded in a browser-supported
language (such as JavaScript, combined with a browser-
rendered markup language like HTML) and reliant on a
common web browser to render the application executable.
Web applications are popular due to the ubiquity of web
browsers, and the convenience of using a web browser as a
client, sometimes called a thin client. The ability to update and
maintain web applications without distributing and installing
software on potentially thousands of client computers is a key
reason for their popularity, as is the inherent support for cross-
platform compatibility. Common web applications include
webmail, online retail sales, online auctions, wikis and many
other functions.
The web interface places very few limits on client functionality.
Through Java, JavaScript, DHTML, Flash and other technologies,
application-specific methods such as drawing on the screen,
playing audio, and access to the keyboard and mouse are all
possible. Many services have worked to combine all of these
Page 27](https://image.slidesharecdn.com/e-votingver2-1-3-110727074342-phpapp02/85/E-voting-27-320.jpg)
Uploaded byMohamed Shalash
E voting
This document is a project report submitted in partial fulfillment of the requirements for a diploma in information systems from Cairo University. The project aims to develop an electronic voting (e-voting) system to automate the voting process, help solve fraud problems, decrease voting time, and streamline the vote counting process. It provides background on documented problems with previous voting systems and outlines the objectives, scope, framework and requirements of the proposed e-voting system.
More Related Content
E voting
- 1. ISSR E-Voting A project submitted in partial fulfillment of the requirements for the degree of Diploma of Information System Project team: Maged Mohamed Farid Elwakil Abd Elmenaem Zeinhom Abd Elmaksoud Wesam Rabeh Ali ELAgamy Rania ElEasawy Abd Elreheem Amal hassan Ali Talkhan Mohamed Talaat Rashed Shalash Under supervision: Dr. Doaa Nabil Cairo 2011
- 2. Document Version History Ver.No. Ver. Date Prepared By Reviewed By Description Wesam Rabeh Mohamed Shalash Amal Talkhan Initial Document and 1.0.0 12-4-2011 Rania Zora scope Abd Elmonem Maged Elwakil Mohamed Shalash 1.0.1 14-4-2011 Requirement definition Maged Elwakil 1.0.2 17-4-2011 Maged Elwakil Dr. Doaa Nabil Wesam Rabeh Use cases and analysis 1.2.0 4-5-2011 Mohamed Shalash documents Maged Elwakil 1.3.0 7-5-2011 Maged Elwakil Design diagrams Wesam Rabeh Mohamed Shalash Amal Talkhan 1.4.0 11-5-2011 Dr.Doaa Nabile Review Rania Zora Abd Elmonem Maged Elwakil Component, deployment, 1.5.0 Maged Elwakil and network infrastructure diagrams Mohamed Shalash 1.6.0 2-6-2011 Rania Zora Application Interfaces Maged Elwakil Wesam Rabeh Mohamed Shalash Amal Talkhan 2.0.0 15-6-2011 Dr. Doaa Nabil Test plan Rania Zora Abd Elmonem Maged Elwakil Mohamed Shalash 2.0.1 18-6-2011 Enhancement Maged Elwakil Mohamed Shalash Final and approved 2.1.1 1-7-2011 Dr. Doaa Nabil Maged Elwakil document Page 2
- 3. Acknowledgement On the behalf of the Institute of Statistical Studies and Research, Cairo University, and on our own behalf, we would like to express our profound thanks and great attitude to all those respectable Professors in capacity of Dr. DOAA NABIL who guided us through the preparation of this project. We would also appreciate the 25th January revolution and its spirit which inspired the Egyptians to move towards the modernization, the establishment and the democracy of future EGYPT. Page 3
- 4. Abstract Elections allow the populace to choose their representatives and express their preferences for how they will be governed. Naturally, the integrity of the election process is fundamental to the integrity of democracy itself. The election system must be sufficiently robust to withstand a variety of fraudulent behaviors and must be sufficiently transparent and comprehensible that voters and candidates can accept the results of an election. Unsurprisingly, history is littered with examples of elections being manipulated in order to influence their outcome. The design of a “good” voting system, whether electronic or using traditional paper ballots or mechanical devices must satisfy a number of sometimes competing criteria. The anonymity of a voter’s ballot must be preserved, both to guarantee the voter’s safety when voting against a malevolent candidate, and to guarantee that voters have no evidence that proves which candidates received their votes. The existence of such evidence would allow votes to be purchased by a candidate. The voting system must also be tamper-resistant to thwart a wide range of attacks, including ballot stuffing by voters and incorrect tallying by insiders. Another factor is the importance of human factors. A voting system must be comprehensible to and usable by the entire voting population, regardless of age, infirmity, or disability. Providing accessibility to such a diverse population is an important engineering problem and one where, if other security is done well, electronic voting could be a great improvement over current paper systems. Flaws in any of these aspects of a voting system, however, can lead to indecisive or incorrect election results. There have been several studies on using computer technologies to improve elections. These studies caution against the risks of moving too quickly to adopt electronic voting machines because of the software engineering challenges, insider threats, network vulnerabilities, and the challenges of auditing. Page 4
- 5. Table of Contents Acknowledgement..........................................................................................................3 1.1Introduction:.............................................................................................................9 1.2 Problem definition:.................................................................................................10 1.3 Glossary & Key terms............................................................................................10 1.4 Goals and Objectives .............................................................................................11 1.5 Project Scope:.........................................................................................................11 1.6 E-Voting Process Framework................................................................................12 1.7 Background research..............................................................................................13 Documented problems.......................................................................................................13 2.1 Methodologies........................................................................................................19 Object Oriented Programming............................................................................................19 Design Patterns..................................................................................................................24 ECC Pattern....................................................................................................................24 Adaptor pattern............................................................................................................25 Three-tier architecture.......................................................................................................25 Web Application................................................................................................................27 Distributed Data Base.........................................................................................................28 2.2 Feasibility Analysis:-.............................................................................................32 SWOT/PEST Analysis...........................................................................................................32 Strengths.........................................................................................................................32 Opportunities..................................................................................................................33 Weaknesses....................................................................................................................34 Threats............................................................................................................................34 2.3 Major Identified Risks...........................................................................................37 2.4 Requirement specification:-..................................................................................38 Functional Requirements:...................................................................................................38 B) Non-Functional Requirements:...................................................................................39 Security Requirements...............................................................................................39 2.5 Domain Model.......................................................................................................42 2.6 Use Cases...............................................................................................................43 Manage Judge/Admin-clerk............................................................................................43 Manage Precinct & Poll Station......................................................................................48 Manage Candidate..........................................................................................................53 Manage Voter.................................................................................................................58 Voting Process Use case .................................................................................................62 Reporting Use Case ........................................................................................................68 2.7 E-voting State Chart Diagram................................................................................72 Page 5
- 6. ......................................................................................................................................73 2.8 E-voting ActivityDiagram.....................................................................................74 2.9 Package Diagram ..................................................................................................75 3.2 E-voting System Database ERD............................................................................78 3.5 Sequence Diagram.................................................................................................81 4.1 Component diagram...............................................................................................84 4.2 Deployment diagram..............................................................................................85 4.3 Network Infrastructure and VPN...........................................................................86 4.4 Application Interface..............................................................................................87 5.1 INTRODUCTION..................................................................................................91 5.1.1 Objectives..................................................................................................................91 5.1.2 Testing Strategy.........................................................................................................91 5.1.4 Reference Material....................................................................................................92 5.2 TEST ITEMS.........................................................................................................92 5.2.1 Program Modules......................................................................................................92 5.2.2 User Procedures.........................................................................................................94 5.2.3 Operator Procedures.................................................................................................94 5.3 Features to Be Tested.............................................................................................94 5.4. FEATURES NOT TO BE TESTED.....................................................................95 5.5. APPROACH.........................................................................................................95 5.5.2- Acceptance testing...................................................................................................96 Check all the links:..........................................................................................................96 Test forms in all pages: ..................................................................................................96 Cookies testing:...............................................................................................................97 Validate HTML/CSS.........................................................................................................97 Database testing.............................................................................................................97 Usability Testing..............................................................................................................98 Compatibility Testing:.....................................................................................................99 Performance testing:......................................................................................................99 Security Testing:...........................................................................................................101 GUI Test........................................................................................................................101 5.6. PASS / FAIL CRITERIA....................................................................................102 5.6.1 Suspension Criteria..................................................................................................102 5.7. Testing Process....................................................................................................103 5.7.1 Test Deliverables......................................................................................................103 5.7.2 Testing Tasks............................................................................................................103 5.7.3 Responsibilities........................................................................................................104 5.7.4 Resources.................................................................................................................104 Physical Resources:.......................................................................................................104 Human Resources:........................................................................................................104 Page 6
- 7. 5.7.5- Schedule.................................................................................................................104 5.8. EnvironmentalRequirements..............................................................................105 5.8.1 Hardware.................................................................................................................105 Software 105 5.8.3 Risks and Assumptions.............................................................................................105 Conclusion and future work.......................................................................................106 References..................................................................................................................107 Page 7
- 8. Chapter One Introduction Page 8
- 9. 1.1 Introduction: Elections allow the populace to choose their representatives and express their preferences for how they will be governed. Naturally, the integrity of the election process is fundamental to the integrity of democracy itself. The election system must be sufficiently robust to withstand a variety of fraudulent behaviors and must be sufficiently transparent and comprehensible that voters and candidates can accept the results of an election. Unsurprisingly, history is littered with examples of elections being manipulated in order to influence their outcome. The design of a “good” voting system, whether electronic or using traditional paper ballots or mechanical devices must satisfy a number of sometimes competing criteria. The anonymity of a voter’s ballot must be preserved, both to guarantee the voter’s safety when voting against a malevolent candidate, and to guarantee that voters have no evidence that proves which candidates received their votes. The existence of such evidence would allow votes to be purchased by a candidate. The voting system must also be tamper-resistant to thwart a wide range of attacks, including ballot stuffing by voters and incorrect tallying by insiders. Another factor is the importance of human factors. A voting system must be comprehensible to and usable by the entire voting population, regardless of age, infirmity, or disability. Providing accessibility to such a diverse population is an important engineering problem and one where, if other security is done well, electronic voting could be a great improvement over current paper systems. Flaws in any of these aspects of a voting system, however, can lead to indecisive or incorrect election results. There have been several studies on using computer technologies to improve elections. These studies caution against the risks of moving too quickly to adopt electronic voting machines because of the software engineering challenges, insider threats, network vulnerabilities, and the challenges of auditing. Page 9
- 10. 1.2 Problem definition: Electronic voting systems are increasingly replacing the traditional paper-based voting systems. These systems can make the voting process more convenient and may therefore lead to improved turnout. Electronic recording and counting of votes could be faster, more accurate and less labor intensive. The goal of the E-Voting as a product is to automate the voting process, help in solving fraud problems, decreasing the voting time, and the process of counting. a strong relationship between the indicator from one side and the related parameters from the other side, so reaching the required data is really a big problem. 1.3 Glossary & Key terms a group of people living in a particular local area or a Community group of nations having common interests an employee who performs clerical work (e.g., keeps Clerks records or accounts) group of people who evaluate or judge a critical Judges opinion group of people electorate to make a decision or Voters express an opinion or group of citizens who has a legal right to vote a place where voters go to cast their votes in an Polling election or a venue established for the purpose of station/Committe polling and controlled by staff of the electoral e management body the place where people vote or an inquiry into public Polls opinion conducted by interviewing a random sample of people is the system by which a government records the vital Civil registry events of its citizens and residents someone who administers a business or someone Administrators who manages a government agency or department A person who is elected or nominee to a certain Candidate position or person seeking or being considered for some kind of position eg (to be elected to an office) An election is a formal decision -making process by Election which a population chooses an individual to hold public Page 10
- 11. 1.4 Goals andObjectives The e-voting system provides a voting service that allows people to vote from any poll site in the country electronically. This system encompasses legal, regulatory, behavioral, and sociological aspects of the current voting system, while adding additional convenience and security to the overall voting process. This system is designed to improve the current voting process in the following ways 1. Allow voters to vote from any poll site in the country without the use of absentee ballots 2. Reduce the number of legitimate votes not counted by reducing the number of over-votes, and eliminating vote tampering 3. Improve the registration process by allowing voters to check their registration status prior to voting and centralizing registration databases 4. Increase voter confidence and improve the voting experience 1.5 Project Scope: The system deals with how an e-vote process should be designed and implemented in order to comply with the democratic election principles and rights as well as to other human rights, which constitute the cornerstone of the international legal civilization. These issues are discussed in the light of the voting principles and rights of the users involved in an election process. The scope of the system is limited to the general public elections, and also includes every election or decision-making process, which takes place through voting. It extends also to (Internet or Intranet) polls without binding effects (if the latter - in view of their nature or their extent - could influence the public discourse in a given state or organization). The significance of the issues addressed herein is clearly manifested by the volume of debate that lately has begun on them, in many countries over the globe. This is understandable in view of the fact that technology usually moves at a pace faster than the legal system does. However, technological evolution should always be pursued as a means to improve human life as opposed to an end by itself. In this Page 11
- 12. respect, all technologicaldevelopment, in particular those directly or indirectly affecting fundamental principles should be carefully reviewed with an eye towards determining their contribution to the betterment of society. Despite the volume of material published to support this debate, including user requirements specifications, no consolidated view on the requirements deriving from constitutional and legal consideration is available. This is the main contribution of the system. The system is structured as follows: • The main issues associated with e-voting in presidential public election processes are discussed. • Requirements for an electronic voting system to be used in general elections. • Discusses requirements stemming from the democratic nature of the election process. The E-Voting system passes 3 major steps: 1- Pre-Voting (preparing administration, committee, candidates, and voters) 2- Voting (Voting process itself) 3- Post-Voting(Result counting and generating reports) 1.6 E-Voting Process Framework E-Voting process Framework 65535 Page 12
- 13. 1.7 Background research Polling place electronic voting or Internet voting examples have taken place in Australia, Belgium, Brazil, Canada, Estonia, the European Union, France, Germany, India, Ireland, Italy, the Netherlands, Norway, Romania, Switzerland, the United Kingdom, Venezuela, and the Philippines. Documented problems 1. the United States: Florida - A number of problems with voting systems in Florida since the 2000 Presidential election. - Punched cards received considerable notoriety in 2000 when their uneven use in Votomatic style systems in Florida was alleged to have affected the outcome of the U.S. presidential election. Invented by Joseph P. Harris, Votomatic was manufactured for a time under license by IBM. William Rouverol, who built the prototype and wrote patents, stated that after the patents expired in 1982, lower quality machines had appeared on the market. The machines used in Florida had five times as many errors as a true Votomatic, he said. - Punched-card-based voting systems, the Votomatic system in particular, use special cards where each possible hole is pre-scored, allowing perforations to be made by the voter pressing a stylus through a guide in the voting machine. A problem with this system is the incomplete punch; this can lead to a smaller hole than expected, or to a mere slit in the card, or to a mere dimple in the card, or to a hanging Chad. This technical problem was claimed by the Democratic Party to have influenced the 2000 U.S. presidential election in the state of Florida; critics claimed that punched card voting machines were primarily used in Democratic areas and that hundreds of ballots were not read properly or were disqualified due to incomplete punches, which allegedly tipped the vote in favor of George W. Bush over Al Gore. - Other punched card voting systems use a metal hole-punch mechanism that does not suffer nearly as much from this fault, although most states have eliminated punched card voting systems Page 13
- 14. of all typesafter the 2000 Florida experience. South Korea still predominantly uses punched card ballots. Virginia: - Fairfax County, Virginia, November 4, 2003. Some voters complained that they would cast their vote for a particular candidate and the indicator of that vote would go off shortly after. California: - The Premier Election Solutions (formerly Diebold Election Systems) TSx voting system disenfranchised many voters in Alameda and San Diego Counties during the March 2, 2004 California presidential primary due to non-functional voter card encoders. On April 30 California's secretary of state Kevin Shelley decertified all touch-screen machines and recommended criminal prosecution of Diebold Election Systems. The California Attorney- General decided against criminal prosecution, but subsequently joined a lawsuit against Diebold for fraudulent claims made to election officials. Diebold settled that lawsuit by paying $2.6 million On February 17, 2006 the California Secretary of State Bruce McPherson then recertified Diebold Election Systems DRE and Optical Scan Voting System. Napa County, California, March 2, 2004, an improperly calibrated mark sense scanner overlooked 6,692 absentee ballot votes. - Problems in the United States general elections, 2006: o During early voting in Miami, Hollywood and Fort Lauderdale, Florida in October 2006 three votes intended to be recorded for Democratic candidates were displaying as cast for Republican. Election officials attributed it to calibration errors in the touch screen of the voting system. o In Pennsylvania, a computer programming error forced some to cast paper ballots. In Indiana, 175 precincts also resorted to paper. Counties in those states also extended poll hours to make up for delays. o Cuyahoga County, Ohio: The Diebold computer server froze and stopped counting votes then the printers jammed so paper copies could not be retrieved for many votes and there was no way to be sure of the accuracy of the votes when the votes were being counted. o Walsenburg, Arkansas: The touch screen computer tallied zero votes for one mayoral candidate who confirmed that he Page 14
- 15. certainly voted forhimself and therefore there would be a minimum of one vote, this is a case of disappearing votes on touch screen machines. The subsequent investigation found that the under vote was not caused by software error. Poor ballot design was widely acknowledged as the cause of the under vote. - Instances of faulty technology and security issues surrounding these machines were documented on August 1, 2001 in the Brennan Center at New York University Law School. NY University Law School released a report with more than 60 examples of e-voting machine failures in 26 states in 2004 and 2006. Examples included Spanish language ballots that were cast by voters but not counted in Sacramento in 2004. - 2008 United States Elections: o Virginia, Tennessee, and Texas: Touch screen voting machines flipped votes in early voting trials o Humboldt County, California: A security flaw erased 197 votes from the computer database. California top to bottom review. In May 2007, California Secretary of State Debra Bowen commissioned a "Top to Bottom review" of all electronic voting systems in the state. She engaged computer security experts led by the University of California to perform security evaluations of voting system source code as well as "red teams" running "worst case" Election Day scenarios attempting to identify vulnerabilities to tampering or error. The Top to Bottom review also included a comprehensive review of manufacturer documentation as well as a review of accessibility features and alternative language requirements. The end results of the tests were released in the four detailed Secretary of State August 3, 2007 resolutions (for Diebold Election Systems, Hart InterCivic, Sequoia Voting Systems and Elections Systems and Software, Inc.) and updated October 25, 2007 revised resolutions for Diebold and Sequoia voting systems. The security experts found significant security flaws in all of the manufacturers' voting systems, flaws that could allow a single non-expert to compromise an entire election. On August 3, 2007 Bowen decertified machines that were tested in her top to bottom view including the ES&S InkaVote machine, which was not included in the review because the company submitted it past the deadline for testing. The report issued July 27, 2007 was conducted by the expert "red team" attempting to detect the levels of technological vulnerability. Another report on August Page 15
- 16. 2, 2007 wasconducted by a source code review team to detect flaws in voting system source code. Both reports found that three of the tested systems fell far short of the minimum requirements specified in the 2005 Voluntary Voting System Guidelines (VVSG). Some of the systems tested were conditionally recertified with new stringed security requirements imposed. The companies in question have until the February 2008 California Presidential Primaries to fix their security issues and insure that election results can be closely audited. The Premier Election Solutions (formerly Diebold Election Systems) AccuVote-TSx voting system was studied by a group of Princeton University computer scientists in 2006. Their results showed that the AccuVote-TSx was insecure and could be "installed with vote-stealing software in under a minute." The scientists also said that machines can transmit computer viruses from one to another "during normal pre- and post-election activity 2. India: - Omesh Saigal, an IIT alumnus and IAS officer blew the top of the Election Commissioner Navin Chawla in front of the whole nation when he successfully demonstrated that the 2009 elections in India when Congress Party of India came back to power might be rigged. This forced the election commission to review the current EVMs and brought bad reputation for Mr. Navin Chawla. - On October 30, 2006 the Dutch Minister of the Interior withdrew the license of 1187 voting machines from manufacturer Suds NV, about 10% of the total number to be used, because it was proven by the General Intelligence and Security Service that one could eavesdrop on voting from up to 40 meters using Van Eck phreaking. National elections are to be held 24 days after this decision. The decision was forced by the Dutch grass roots organization Wij vertrouwen stem computers net ("We do not trust voting computers"). 3. Finland: - In Finland, the Supreme Administrative Court declared invalid the results of a pilot electronic vote in three municipalities, and ordered a rerun of the municipal elections. The system had an usability problem where the messages were ambiguous on whether the vote had been cast. In a total of 232 cases (2% of votes), voters had logged in, selected their vote but not confirmed it, and left the booth; the votes were not recorded. Following the failure of the Page 16
- 17. pilot election, theFinnish government has abandoned plans to introduce electronic voting to the country. Page 17
- 18. Chapter Two System Analysis Page 18
- 19. 2.1 Methodologies Object OrientedProgramming Object-oriented programming (OOP) is a programming paradigm that uses "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction, encapsulation, modularity, polymorphism, and inheritance. It was not commonly used in mainstream software application development until the early 1990s. Many modern programming languages now support OOP. An object is a discrete bundle of functions and procedures, often relating to a particular real-world concept such as a voter or candidate. Other pieces of software can access the object only by calling its functions and procedures that have been allowed to be called by outsiders. A large number of software engineers agree that isolating objects in this way makes their software easier to manage and keep track of. However, a significant number of engineers feel the reverse may be true: that software becomes more complex to maintain and document, or even to engineer from the start. The conditions under which OOP prevails over alternative techniques (and vice-versa) often remain unstated by either party, however, making rational discussion of the topic difficult, and often leading to "religious wars" over the matter. Object-oriented programming has roots that can be traced to the 1960s. As hardware and software became increasingly complex, manageability often became a concern. Researchers studied ways to maintain software quality and developed object-oriented programming in part to address common problems by strongly emphasizing discrete, reusable units of programming logic. The technology focuses on data rather than processes, with programs composed of self-sufficient modules ("classes"), each instance of which ("objects") contains all the information needed to manipulate its own data structure ("members"). This is in contrast to the existing modular programming which had been dominant for many years that focused on the function of a module, rather than specifically the data, but equally provided for code reuse, and self-sufficient reusable units of programming logic, enabling collaboration Page 19
- 20. through the useof linked modules (subroutines). This more conventional approach, which still persists, tends to consider data and behavior separately. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent 'machine' with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. For example, the data structures tend to 'carry their own operators around with them' (or at least "inherit" them from a similar object or class). In the conventional model, the data and operations on this data doesn't have a tight formal association. Fundamental concepts and features A survey by Deborah J. Armstrong of nearly 40 years of computing literature identified a number of "quarks", or fundamental concepts, found in the strong majority of definitions of OOP. Not all of these concepts are to be found in all object-oriented programming languages, and so object-oriented programming that uses classes is called sometimes class-based programming. In particular, prototype-based programming does not typically use classes. As a result, a significantly different yet analogous terminology is used to define the concepts of object and instance. Class 'A class defines' the abstract characteristics of a thing (object), including its characteristics (its attributes, fields or properties) and the thing's behaviors (the things it can do, or methods, operations or features). One might say that a class is a blueprint or factory that describes the nature of something. For example, the class Voter would consist of traits shared by all voters, such as Name and age color (characteristics), and the ability to cast vote (behaviors). Classes provide modularity and structure in an object-oriented computer program. A class should typically be recognizable to a non-programmer familiar with the problem domain, meaning that the characteristics of the class should make sense in context. Also, the code for a Page 20
- 21. class should berelatively self-contained (generally using encapsulation). Collectively, the properties and methods defined by a class are called members. Object An instance (that is, an actual example) of a class. Example 1: The class Voter is a pattern or blueprint for candidate objects by listing the characteristics and behaviors they can have; the object Ahmed is one particular candidate. Instance One can have an instance of a class; the instance is the actual object created at run-time. In programmer vernacular, the Ahmed object is an instance of the voter class. The set of values of the attributes of a particular object is called its state. The object consists of state and the behavior that's defined in the object's class. Method An object's abilities. In language, methods (sometimes referred to as "functions") are verbs. Ahmed, being a voter, has the ability to submit a vote So submit () is one of Ahmed's methods. He may have other methods as well, for example Login(). Within the program, using a method usually affects only one particular object; all voters can submit a vote, but you need only one voter to submit one vote. Message passing "The process by which an object sends data to another object or asks the other object to invoke a method."Also known to some programming languages as interfacing. For example, the object called AdminClerk may tell the Ahmed object to apply by passing a "submit" message which invokes Ahmed's "submit" method. The syntax varies between languages, for example: [Ahmed submit] in Objective-C. In Java, code-level message passing corresponds to "method calling". Some dynamic languages use double-dispatch or multi-dispatch to find and pass messages. Inheritance "Subclasses" are more specialized versions of a class, which inherit attributes and behaviors from their parent classes, and can introduce their own. For example, the class person might have sub-class called Page 21
- 22. voter. In thiscase, Ahmed would be an instance of the voter subclass. Suppose the people class defines a method called View() and a property called name. Each of its sub-classes (voter, candidate, and judge) will inherit these members, meaning that the programmer only needs to write the code for them once. Each subclass can alter its inherited traits. For example, the voter subclass might specify that the default status for a voter is true. The Subclasses can also add new members. The voter subclass could add a method called submit(). So an individual Ahmed instance would use a high-pitched submit() from the voter subclass. The Baradey object would also have the apply() method, but Ahmed would not, because he is a candidate, not a voter. In fact, inheritance is an "a... is a" relationship between classes, while instantiation is an "is a" relationship between an object and a class: a voter is a person ("a... is a"), but ahmed is a voter ("is a"). Thus, the object named Ahmed has the methods from both classes voter and person. Multiple inheritances is inheritance from more than one ancestor class, neither of these ancestors being an ancestor of the other. For example, independent classes could define person and community, and a Ahmed object could be created from these two which inherits all the (multiple) behavior of person and community. This is not always supported, as it can be hard to implement. Abstraction Abstraction is simplifying complex reality by modeling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem. For example, Ahmed the Voter may be treated as a voter much of the time, a community instance when necessary to access community-specific attributes or behaviors, and as a person (perhaps the parent class of voter). Encapsulation Encapsulation conceals the functional details of a class from objects that send messages to it. For example, the voter class has a submit() method. The code Page 22
- 23. for the submit()method defines exactly how a submition happens (e.g., by login() and then verify(), at a particular pitch and volume). Ali, Ahmed's friend, however, does not need to know exactly how he votes. Encapsulation is achieved by specifying which classes may use the members of an object. The result is that each object exposes to any class a certain interface — those members accessible to that class. The reason for encapsulation is to prevent clients of an interface from depending on those parts of the implementation that are likely to change in the future, thereby allowing those changes to be made more easily, that is, without changes to clients. Members are often specified as public, protected or private, determining whether they are available to all classes, sub- classes or only the defining class. Some languages go further: Java uses the default access modifier to restrict access also to classes in the same package, C# and VB.NET reserve some members to classes in the same assembly using keywords internal (C#) or Friend (VB.NET), and Eiffel and C++ allow one to specify which classes may access any member. Polymorphism(Subtype) Polymorphism allows the programmer to treat derived class members just like their parent class's members. More precisely, Polymorphism in object-oriented programming is the ability of objects belonging to different data types to respond to calls of methods of the same name, each one according to an appropriate type-specific behavior. One method, or an operator such as +, -, or *, can be abstractly applied in many different situations. Decoupling Decoupling allows for the separation of object interactions from classes and inheritance into distinct layers of abstraction. A common use of decoupling is to polymorphically decouple the encapsulation, which is the practice of using reusable code to prevent discrete code modules from interacting with each other. However, in practice decoupling often involves trade- offs with regard to which patterns of change to favor. The science of measuring these trade-offs in respect to actual change in an objective way is still in its infancy. Page 23
- 24. Design Patterns In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Design patterns reside in the domain of modules and interconnections. At a higher level there are Architectural patterns that are larger in scope, usually describing an overall pattern followed by an entire system. Not all software patterns are design patterns. For instance, algorithms solve computational problems rather than software design problems. Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns. In order to achieve flexibility, design patterns usually introduce additional levels of indirection, which in some cases may complicate the resulting designs and hurt application performance. By definition, a pattern must be programmed anew into each application that uses it. Since some authors see this as a step backward from software reuse as provided by components, researchers have worked to turn patterns into components. Meyer and Arnout claim a two-thirds success rate in componentizing the best-known patterns. Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem. ECC Pattern Engine-Collection-Class, a Design Pattern for Building Reusable Enterprise Components The Enterprise Computing Center Page 24
- 25. (ECC) is aresearch center of the ETH Zürich established in collaboration with industry to promote education, research, and technology transfer in the general areas of enterprise IT architecture, enterprise computing, enterprise application integration, middleware, high performance and large scale data management, multi-tier architectures, and service oriented architectures. The charter of the ECC involves: • To conduct advanced research as part of joint projects with the industrial partners. • To pursue graduate education programs (Master / Ph.D. level) that better prepare students for the problems they will encounter in industry. • To establish a permanent dialogue between academic research and industry on technology, education, and research, acting as a vehicle and catalyst for information exchanges across companies and the development of a better understanding of the problems surrounding enterprise computing. Adaptor pattern In computer programming, the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple Boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value. Three-tier architecture is a client–server architecture in which the user interface, functional process logic ("business rules"), computer data storage and data access are developed and maintained as independent modules, most often on separate platforms. It was developed by John J. Donovan in Open Environment Page 25
- 26. Corporation (OEC), atools company he founded in Cambridge, MA. The three-tier model is a software architecture and a software design pattern. Apart from the usual advantages of modular software with well-defined interfaces, the three-tier architecture is intended to allow any of the three tiers to be upgraded or replaced independently as requirements or technology change. For example, a change of operating system in the presentation tier would only affect the user interface code. Typically, the user interface runs on a desktop PC or workstation and uses a standard graphical user interface, functional process logic may consist of one or more separate modules running on a workstation or application server, and an RDBMS on a database server or mainframe contains the computer data storage logic. The middle tier may be multi- tiered itself (in which case the overall architecture is called an "n-tier architecture"). Three-tier architecture has the following three tiers: Presentation tier This is the topmost level of the application. The presentation tier displays information related to such services as browsing merchandise, purchasing, and shopping cart contents. It communicates with other tiers by outputting results to the browser/client tier and all other tiers in the network. Application tier (business logic, logic tier, data access tier, or middle tier) The logic tier is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality by performing detailed processing. Data tier This tier consists of database servers. Here information is stored and retrieved. This tier keeps data neutral and independent from application servers or business logic. Giving data its own tier also improves scalability and performance. Page 26
- 27. 3 tier Architecture1 Web Application In system software, a web application is an application that is accessed over a network such as the Internet or an intranet. The term may also mean a computer software application that is hosted in a browser-controlled environment (e.g. a Java applet)[citation needed] or coded in a browser-supported language (such as JavaScript, combined with a browser- rendered markup language like HTML) and reliant on a common web browser to render the application executable. Web applications are popular due to the ubiquity of web browsers, and the convenience of using a web browser as a client, sometimes called a thin client. The ability to update and maintain web applications without distributing and installing software on potentially thousands of client computers is a key reason for their popularity, as is the inherent support for cross- platform compatibility. Common web applications include webmail, online retail sales, online auctions, wikis and many other functions. The web interface places very few limits on client functionality. Through Java, JavaScript, DHTML, Flash and other technologies, application-specific methods such as drawing on the screen, playing audio, and access to the keyboard and mouse are all possible. Many services have worked to combine all of these Page 27
- 28. into a morefamiliar interface that adopts the appearance of an operating system. General purpose techniques such as drag and drop are also supported by these technologies. Web developers often use client-side scripting to add functionality, especially to create an interactive experience that does not require page reloading. Recently, technologies have been developed to coordinate client-side scripting with server-side technologies such as PHP. Ajax, a web development technique using a combination of various technologies, is an example of technology which creates a more interactive experience. Applications are usually broken into logical chunks called "tiers", where every tier is assigned a role. Traditional applications consist only of 1 tier, which resides on the client machine, but web applications lend themselves to a n-tiered approach by nature. Though many variations are possible, the most common structure is the three-tiered application Distributed Data Base We can define a distributed database (DDB) as a collection of multiple logically interrelated databases distributed over a computer network, and a distributed database management system (DDBMS) as a software system that manages a distributed database while making the distribution transparent to the use. A collection of files stored at different nodes of a network and the maintaining of interrelationships among them via hyperlinks has become a common organization on the Internet, with files of Web pages. Reasons of DDB 1. More computer power is harnessed to solve a complex task, and. 2. Each autonomous processing element can be managed independently and develop its own applications. Page 28
- 29. Some different databasesystem architectures. (a) Shared nothing architecture. (b) A networked architecture with a centralized database at one of the sites. (c) A truly distributed database architecture. Shared nothing architecture. 1 A networked architecture with a centrali 1 Page 29
- 30. Truly distributed databasearchitecture 1 Advantages of DDB: - Increased reliability and availability: These are two of the most common potential advantages cited for distributed databases. Reliability is broadly defined as the probability that a system is running (not down) at a certain time point, whereas availability is the probability that the system is continuously available during a time interval. When the data and DBMS software are distributed over several sites, one site may fail while other sites continue to operate. Only the data and software that exist at the failed site cannot be accessed. This improves both reliability and availability. Further Page 30
- 31. improvement is achievedby judiciously replicating data and software at more than one site. In a centralized system, failure at a single site makes the whole system unavailable to all users. In a distributed database, some of the data may be unreachable, but users may still be able to access other parts of the database. - Improved performance: A distributed DBMS fragments the database by keeping the data closer to where it is needed most. Data localization reduces the contention for CPU and I/O services and simultaneously reduces access delays involved in wide area networks. When a large database is distributed over multiple sites, smaller databases exist at each site. As a result, local queries and transactions accessing data at a single site have better performance because of the smaller local databases. In addition, each site has a smaller number of transactions executing than if all transactions are submitted to a single centralized database. Moreover, inter query and inter query parallelism can be achieved by executing multiple queries at different sites, or by breaking up a query into a number The potential advantages Of DDBMS The DDBMS software must be able to provide the following functions in addition to those of a centralized DBMS: - Keeping track of data: The ability to keep track of the data distribution, fragmentation, and replication by expanding the DDBMS catalog. - Distributed query processing: The ability to access remote sites and transmit queries and data among the various sites via a communication network. - Distributed transaction management: The ability to devise execution strategies for queries and transactions that access data from more than one site and to synchronize the access to distributed data and maintain integrity of the overall database. - Replicated data management: The ability to decide which copy of a replicated data item to access and to maintain the consistency of copies of a replicated data item. - Distributed database recovery: The ability to recover from individual site crashes and from new types of failures such as the failure of a communication links. Page 31
- 32. - Security: Distributed transactions must be executed with the proper management of the security of the data and the authorization/access privileges of users. - Distributed directory (catalog) management: A directory contains information (metadata) about data in the database. The directory may be global for the entire DDB, or local for each site. The placement and distribution of the directory are design and policy issues. 2.2 Feasibility Analysis:- SWOT/PEST Analysis In this section, not only the SWOT but also the PEST factors are examined to assess the current and prospective states of e-voting in Egypt by using a practical approach. SWOT analysis is employed to discuss strengths (S), weaknesses (W), opportunities (O) and threats (T) of e-Voting in Egypt. Each of the four components of SWOT analysis is further examined according to PEST factors, referring to political (P), economic (E), social (S) and technological (T) determinants. Strengths The strengths of Egypt to develop and maintain e-Voting lie with the public policy. This is an important political determinant in the PEST model. Political: After 25 January revolution, the need for a system that automate the election process, to facilitate the participation of the large amount of voters into the process of the election, and help in getting rid of all means of fraud. Economic: Implementing E-Voting system with central database will decrease transposition cost for voting boxes, as this costs will be replaced by the cost of intranet used for voting system. Implementing such a system will guide business to such a field of providing services to the government and automating their process, this will open new job vacancies for IT people. Social: Page 32
- 33. Implementing such asystem in Egypt will gain the attention of people to IT, and hence this system can help in removing technology Illiteracy. Automating the system will decrease the time of voter verification and hence will decrease the time of the voting process and voting queues, helping in preventing valance among voters. The idea of automating voting process will gain voter respects and trust, since no one has control on their decisions. Technology strengths: The system will utilize the technology and make benefits of it. New infrastructure will be added, and the system will reflect the effect of technology on the public live and will encourage innovation. Opportunities Political: In spite of the abovementioned shortcomings, there are many opportunities for E-Voting to grow in Egypt. The political willingness of leaders to build and automate the voting process creates an opportunity for businesses in Egypt to show their commitment to E- Voting, and government may help in planning, designing and implementing such a system. Economic: People with IT proficiency have better opportunities for employment since computer literacy is a requirement for most industries in Egypt. Thus, people are motivated to learn computer skills. Time constraints are another motive to urge the public to adopt e-Services. Social: The system provide opportunities for the society as it direct their attention to the technology and how it can they help them in their live to improve, provide opportunities for voters to get rid from their fairs of frauds by all its means or affecting their opinions. Technology: The development of new technology applications presents opportunities for better, cheaper and more efficient e-services. Page 33
- 34. Weaknesses Political: Traditionally, the publicbelieve that the old government always wants to introduce new methods and new approaches to return to political live. This belief may cause people to hesitate in trying E- Voting. Other weaknesses are the public feelings of insecurity and concern about making mistakes and being fined. These issues discourage people from tapping into E-Voting. Economic: Economic costs for providing all infrastructures required to run the system and so the original version of software applications used. Social: Large portion of blue-collar workers and the older generation is still computer illiterate. Others may find it difficult to follow instructions on the Internet or may be discouraged by computer-related problems. Technology: Less IT-savvy people and the older generation are afraid of computer related problems. The performance and traffic on the server is another issue. Threats Political: Opposition system may take advantage of the Internet to spread propaganda on their ideologies and to create social disorder as they can question about the electronic system depending on most people illiteracy with the IT. Security breaches are another problem for E-Voting. The loopholes in the legal system and advanced technology make it easy for hackers to penetrate portal and steal confidential information. This will create insecurity among voters who then may not be so willing to trust service. Internet and computer related crimes, such as hacking, scam, spam, phishing or identity fraud and theft, will hinder the development of E-Voting. If problems relating to security and privacy are not properly addressed, voter could hesitate to use the service. Economic: Page 34
- 35. Economic threat forincreasing of technologies costs. Social: Rapid development of telecommunication and competition is major threats. Mobile voting may be developed that lead the user to avoid using our system. Competition may lead another company to develop a system with easier technologies and infra structure. Technology: The dependence of people on technology may produce the adverse effect of people serving technology, instead of technology serving people. An electronic crisis may disrupt activities and the whole country could be paralyzed without any Internet connection. Computer viruses, worms and computer bugs may affect the result counting function. Network problems are also a major barrier. Users may feel helpless when they have to deal with technological problems. Page 35
- 36. SWOT/PEST Analysis Summery SWOT/ Strength Weaknesses Opportunities Threats PEST (S) (W) (O) (T) - Cyber terrorism - Public policy Conservation in and cyber Political Political trying e- crimes aspect (P) willingness Services - Security breach - Economic policies - Funds for eservices IT-proficient To improve Infrastructure people can have Infrastructure Economic social and costs better costs aspect (E) physical Software costs opportunity for Software costs infrastructure employment - Low cost of Internet subscripti on - Remove technology Workers and The rapid - IT Illiteracy older development of Social aspect Education - Decrease generation mobile (S) are computer - Fraud technology violence illiterate prevention competition Gain voter trust - Some government Dependency on - High-tech websites are IT, i.e. small Technological based unfriendly-user Broadband technical aspect Economy - Over- facilitates faster problems will (T) - Innovatio capacity connection disrupt the n of the Internet entire networks highway due to heavy traffic Page 36
- 37. 2.3 Major IdentifiedRisks Threat Consequence Likelihood Counter measures Trojan horse No known example, installed by Wholesale but theoretically Operating possible System vendor Prevents Develop Lack of adequate testing Certain standards (a standards of Voting system slow process) Configuration Stronger legal Lack of change could Known problems with sanctions – but configuration introduce new configuration oversight is oversight voting oversight expensive compromises Potential for Better testing multiple voting, and Buggy software Unknown loss of voter certification of privacy voting systems Common, occurred No simple Denial of Disenfranchisem during Canadian counter Service ent Internet election measures Detection difficult. Individual PCs Trojan horse can be spyware to Vote theft, loss of Widely available tools protected, but change or privacy for this assuring monitor votes compliance difficult, especially for public PCs. Page 37
- 38. 2.4 Requirement specification:- FunctionalRequirements: The main features in the system are: A- Pre-voting phase: 1- Manage admin 2- Manage election committee 3- Manage candidates 4- Manage voters B- Voting phase 1- Submit vote C- Post-voting phase 1- View results 2- Generate reports Module 1: Manage Admin Module 1- Super admin must be able to add new admin with specific privileges to the system. 2- Super admin must be able to edit admin. 3- Super admin shall be able to delete admin. 4- Super admin shall be able to view admin information and privileges. Page 38
- 39. 5- Super adminmay be able to sort admins by committee, privileges, and names. 6- Super admin may be able to filter admins by committee, privileges. 7- Super admin may be able to search for a specific admin Module 2: Manage election committee Module 1- Admin must be able to add new committee election. 2- Admin must be able to edit exiting committee election. 3- Admin shall be able to delete existing committee election. 4- Admin shall be able to view committee information. 5- Admin may be able to sort committee by name, location. 6- Admin may be able to filter committee by locations. 7- Admin may be able to search for a specific committee. Module 3: Manage candidate 1- Admin must be able to add new candidate. 2- Admin must be able to edit exiting candidate. 3- Admin shall be able to delete existing candidate. 4- Admin shall be able to view candidate. 5- Admin may be able to sort candidate by name, location. 6- Admin may be able to filter candidate by committee. 7- Admin may be able to search for a specific candidate. Module 4: Manage Voters 1- Admin must be able to add new Voter. 2- Admin must be able to edit exiting voter. 3- Admin shall be able to delete existing voter. 4- Admin shall be able to view voter. 5- Admin may be able to sort voter by name, location. 6- Admin may be able to filter voter by committee assigned to. 7- Admin may be able to search for a specific voter. Module 5: Voting Voters module 1- Voter must be able to login to the system. 2- User must be able to submit vote. 3- Admin must be able to verify user SSN. Module 6: Result management module 1- Judge/auditor must be able to filter result according to votes per committee, votes per candidates, and votes per candidate and committee. B) Non-Functional Requirements: Security Requirements - The security requirements for this system span all aspects of the voting process and include voter authenticity, voter Page 39
- 40. anonymity, data confidentiality,data integrity, system accountability, system integrity, system availability, system assurance, and system reliability - An individual not registered to vote must not be able to cast a ballot - A voter must not be able to vote more than once - The privacy of the vote has to be guaranteed during the casting, transfer, reception, collection, and tabulation of votes - No voter should be able to prove that they voted in a certain way - None of the participants involved in the voting process (organizers, election officials, trusted third parties, voters, etc) should be able to link a vote to an identifiable voter - Each vote is recorded precisely as the voter intended - Each voter is ensured a "clean slate" of the system to ensure equality, confidence, and minimize system tampering - The outcome of the voting process must correspond to the votes cast - It should be infeasible to exclude a valid vote from the tabulation, and to validate a non-valid one - System and voter operations are logged and audited - The system cannot be re-configured during operation - Access to voted ballots is prohibited until after the close of the polls - Additional ballots cannot be cast once the polling place has closed - The system must be open to independent inspection and auditing - The system is protected against accidental and malicious denial of service attacks Privacy: the voting system has to protect privacy, concealing the relation between voter and his/her cast vote, and ensuring that the voter's choice will remain anonymous. This requirement must be fulfilled once the voter has cast his/her vote and must be preserved during the counting processes. Integrity: A voting system has to protect the vote against manipulation once it is cast and until it is counted. Therefore the channel must to provide measures to prevent and/or detect any attempted to change the voter's intent once the vote has been cast. Page 40
- 41. Voter Verifiability –Cast as Intended: Voter must have the possibility to check that his/her vote has been accurately recorded. In the case of remote voting, this implies the availability to check if the vote received by the election officials and stored in the remote Ballot Box (in a physical or electronic manner) is the same as cast by the voter. It is important to note that the requirement cannot conflict with others once. Voter Verifiability – Counted as Cast: In the counted as cast verification, voters must have the possibility to verify the inclusion of his/her vote in the final tally. It is considered as security improvement. Prevention of Intermediate results: It is important to prevent the disclosure of intermediate results before the election is closed. This way, or the voters have the same information during the voting stage. This implies that the secrecy of the vote must be preserved until the tally process. Ballot Box Accuracy: Protection of the ballot box against the addition of bogus ballots or the elimination of valid ballots is needed. In the case that multiple voting is allowed, this measured must guarantee that one vote per voter will be counted. Prevention of Voting Errors: The voting channel has to prevent involuntary voting errors by voters when casting their votes (e.g., under-voting, over-voting). This practice is becoming more common for poll-site voting in complex elections. Ease of Use: the voting channel must be easy to use by average voters. In remote voting this requirement is of paramount importance to prevent disenfranchisement and facilitate the participation of voters. Correctness: All input votes are correctly counted and no other votes are counted Robustness: The counting tolerates the corrupt or faulty behavior of any group of authorities up to a threshold. Page 41
- 42. 2.5 Domain Model Page 42
- 43. 2.6 Use Cases ManageJudge/Admin-clerk Page 43
- 44. Administrator add newjudge / admin-clerk Description Administrator must be able to add judge / admin-clerk. Administrator add judge / admin-clerk Title: Administrator adds judge/admin-clerk personal. Intent: Describe Administrator interacts with the system during add data about new judge/admin-clerk as an initial data. Preconditions Administrator login to the system Actors • Administrator Main Scenario 1- Administrator enters data about new judge/admin- clerk (User id – user name – SSN – title – address - mission). Specification 2- Administrator press save button s 3- Data is saved and confirmation message appear that data is saved successfully. Alternate Scenario1 1- Wrong User id entered (duplicate User id) 2- System displays a message that (invalid User id, User id already exist) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 44
- 45. Administrator edit judge/ admin- clerk Description Administrator must be able to edit judge / admin-clerk. Administrator edits judge / admin-clerk Title: Administrator edits judge/admin-clerk personal data. Intent: Describe Administrator interacts with the system during editing judge/admin-clerk personal data. Preconditions Administrator login to the system. Judge/admin-clerk data already recorded. Actors 1- Administrator Main Scenario 1- Administrator selects judge/admin-clerk user id for the record to be displayed. 2- Administrator amends data. 3- Administrator press save button 4- Confirmation message appear that data is saved Specification successfully. s Alternate Scenario1 1- Wrong user id entered. 2- System displays a message that (invalid user id, user id does not exist) Alternate Scenario2 (Voting Day) 1- The system does not permit editing during voting Process. 2- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 45
- 46. Administrator deletes judge/ admin- clerk Description Administrator must be able to delete judge / admin-clerk Administrator deletes judge / admin-clerk Title: Administrator deletes judge / admin-clerk ion. Intent: Administrator interacts with the system during deleting judge / admin-clerk. Preconditions Administrator login. judge / admin-clerk data already recorded. Actors 1- Administrator Main Scenario 1- Administrator selects judge / admin-clerk to be displayed and press delete. 2- Confirmation message displayed to confirm deletion Specification process. s 3- Administrator press delete button. 4- Precinct and Poll Station is deleted. Alternate Scenario1 (Voting Day) 1- The system does not permit deleting during voting Process. 2- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Administrator displays judge / admin-clerk Description Administrator must be able to display judge / admin- Page 46
- 47. clerk. Administrator displays judge / admin-clerk Title: Administrator displays judge / admin-clerk data. Intent: Describe Administrator interacts with the system during displaying judge / admin-clerk tion data. Preconditions Administrator login. Judge / admin-clerk data already recorded. Actors: Administrator Main Scenario 1- Administrator login to Manage judge / admin-clerk module. All judge / admin-clerk appear with their basic data (User id – user name – SSN – title – address - mission). 2- Administrator selects a judge / admin-clerk. 3- judge / admin-clerk information is displayed in details. Alternate Scenario1 1- The first time Administrator is logged to the system and no judge / admin-clerk exists Specification 2- The system displays a message welcome the Administrator and tells him that there is no data is recorded in the system s yet. Uses/Extends Included1 Sort: 1- Administrator presses any column title in the display page (User id – user name – SSN – title – address - mission). 2- Precinct and Poll Station are sorted according to the pressed column title. Included2 Search: 1- Administrator type judge / admin-clerk name and press search button 2- Matching judge / admin-clerk appear in the result. 3- If there is no result, not found message appear. Included3 Filter: 1- Administrator selects criteria to filter with (title, mission) 2- Matching candidates appear in the result. 3- If there is no result, not found message appear. Frequency Frequent Issues N/A Priority High Page 47
- 48. Manage Precinct &Poll Station Page 48
- 49. Add new Precinctand Poll Station Administrator must be able to add new Precinct or Poll Description Station. Administrator adds precinct and poll station Title: Administrator adds new Precinct or Poll Station. Intent: Describe Administrator interacts with the system during add data about new Precinct or Poll Station as an initial data. Preconditions Administrator login to the system Actors • Administrator Main Scenario 4- Administrator enters data about new Precinct or Poll Station (Code – name – governorate - district - address – Judge ID) Specifications 5- Administrator press save button 6- Data is saved and confirmation message appear that data is saved successfully. Alternate Scenario1 3- Wrong code entered (duplicate code) 4- System displays a message that (invalid code, code already exist) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 49
- 50. Edit Precinct andPoll Station data Administrator must be able to edit Precinct and Poll Description Station. Administrator edits Voter Title: Administrator edits Precinct and Poll Station data. Intent: Describe Administrator interacts with the system during editing Precinct and Poll Station data. Preconditions Administrator login to the system. Precinct and Poll Station data already recorded. Actors 2- Administrator Main Scenario 5- Administrator selects Precinct and Poll Station id for the record to be displayed. 6- Administrator amends data. 7- Administrator press save button 8- Confirmation message appear that data is saved Specification successfully. s Alternate Scenario1 3- Wrong code entered. 4- System displays a message that (invalid id, id does not exist) Alternate Scenario2 (Voting Day) 3- The system does not permit editing during voting Process. 4- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 50
- 51. Delete Precinct andPoll Station data Administrator must be able to delete Precinct and Poll Description Station Administrator deletes Precinct and Poll Station Title: Administrator deletes Precinct and Poll Station. Intent: Administrator interacts with the system during deleting Precinct and Poll Station. Preconditions Administrator login. Precinct and Poll Station data already recorded. Actors 2- Administrator Main Scenario 5- Administrator selects Precinct and Poll Station to be displayed and press delete. 6- Confirmation message displayed to confirm deletion Specifications process. 7- Administrator press delete button. 8- Precinct and Poll Station is deleted. Alternate Scenario1 (Voting Day) 3- The system does not permit deleting during voting Process. 4- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 51
- 52. Display Precinct andPoll Station Data Administrator must be able to display Precinct and Poll Description Station. Administrator displays Precinct and Poll Station Title: Administrator displays Precinct and Poll Station data. Intent: Describe Administrator interacts with the system during displaying Precinct and Poll Station data. Preconditions Administrator login. Precinct and poll data already recorded. Actors 1- Administrator Main Scenario 4- Administrator login to Manage Precinct and Poll Station module. All Precinct and Poll Station appear with their basic data (Code – name – governorate - district - address – Judge ID) 5- Administrator selects a Precinct and Poll Station. 6- Precinct and Poll Station information is displayed in details. Alternate Scenario1 Specification 3- The first time Administrator is logged to the system and s no Precinct and Poll Station exists 4- The system displays a message welcome the Administrator and tells him that there is no data is recorded in the system yet. Uses/Extends Included1 Sort: 3- Administrator press any column title in the display page (code, Name, governorate, district- address- judge id) 4- Precinct and Poll Station are sorted according to the pressed column title. Included2 Search: 4- Administrator type Precinct and Poll Station name and press search button 5- Matching Precinct and Poll Station appear in the result. 6- If there is no result, not found message appear. Included3 Filter: 4- Administrator selects criteria to filter with (governorate, judge) 5- Matching candidates appear in the result. 6- If there is no result, not found message appear. Frequency Frequent Issues N/A Priority High Page 52
- 53. Manage Candidate Page 53
- 54. Add new Candidate Description Administrator must be able to add new candidate. Administrator adds candidate Title: Administrator adds Voter data. Intent: Describe Administrator interacts with the system during add data about candidate as an initial data. Preconditions Administrator login to the system Actors • Administrator Main Scenario 7- Administrator enters data about Candidate (SSN - name - Birth date –Age – Governorate - District – Address, image, election symbol). Specification 8- Administrator press save button s 9- Data is saved and confirmation message appear that data is saved successfully. Alternate Scenario1 5- Wrong SSN entered (duplicate id) 6- System displays a message that (invalid id, id already exist) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 54
- 55. Edit Voter date Description Administrator must be able to edit Voter. Administrator edits Voter Title: Administrator edits candidate data. Intent: Describe Administrator interacts with the system during editing candidate data. Preconditions Administrator login to the system. Candidate data already recorded. Actors 3- Administrator Main Scenario 9- Administrator enters candidate id for the record to be displayed. 10-Administrator amends data. 11-Administrator press save button 12-Confirmation message appear that data is saved Specification successfully. s Alternate Scenario1 5- Wrong id entered. 6- System displays a message that (invalid id, id does not exist) Alternate Scenario2 (Voting Day) 5- The system does not permit editing during voting Process. 6- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 55
- 56. Delete Candidate data Description Administrator must be able to delete candidate. Administrator deletes candidate Title: Administrator deletes candidate. Intent: Administrator interacts with the system during deleting canidate. Preconditions Administrator login. candidate data already recorded. Actors 3- Administrator Main Scenario 9- Administrator selects candidate to be displayed and press delete. 10- Confirmation message displayed to confirm deletion Specification process. s 11- Administrator press delete button. 12-Candidate is deleted. Alternate Scenario1 (Voting Day) 5- The system does not permit deleting during voting Process. 6- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 56
- 57. Display candidate Data Description Administrator must be able to display Voter. Administrator displays Voter Title: Administrator displays candidate data. Intent: Describe Administrator interacts with the system during displaying candidate data. Preconditions Administrator login. candidate data already recorded. Actors 2- Administrator Main Scenario 7- Administrator login to Manage candidate module. 8- All candidates appear with their basic data (Id, Name, and precinct, party, symbol). 9- Administrator selects a candidate. 10-Candidate information is displayed in details. Alternate Scenario1 5- The first time Administrator is logged to the system Specification and no candidate exists s 6- The system displays a message welcome the Administrator and tells him that there is no data is recorded in the system yet. Uses/Extends Included1 Sort: 5- Administrator press any column title in the display page(ID, Name, Precinct, party) 6- Candidates are sorted according to the pressed column title. Included2 Search: 7- Administrator type candidate name and press search button 8- Matching candidates appear in the result. 9- If there is no result, not found message appear. Included3 Filter: 7- Administrator selects criteria to filter with (precinct, party) 8- Matching candidates appear in the result. 9- If there is no result, not found message appear. Frequency Frequent Issues N/A Priority High Page 57
- 58. Manage Voter Page 58
- 59. Add new Voter Description Administrator must be able to add new Voter. Administrator adds Voter Title: Administrator adds Voter data. Intent: Describe Administrator interacts with the system during add data about Voter as an initial data. Preconditions Administrator login to the system Actors • Administrator Main Scenario 10-Administrator enters data about Voter (SSN - name - Birth date –Age – Governorate - District - Address). 11-Administrator press save button Specifications 12-Data is saved and confirmation message appear that data is saved successfully. Alternate Scenario1 7- Wrong SSN entered (duplicate SSN) 8- System displays a message that (invalid SSN, SSN already exist) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 59
- 60. Edit Voter data Description Administrator must be able to edit Voter. Administrator edits Voter Title: Administrator edits Voter data. Intent: Describe Administrator interacts with the system during editing Voter data. Preconditions Administrator login to the system. Voter data already recorded. Actors 4- Administrator Main Scenario 13-Administrator enters Voter SSN for the record to be displayed. 14-Administrator amends data. 15-Administrator press save button 16-Confirmation message appear that data is saved Specification successfully. s Alternate Scenario1 7- Wrong SSN entered. 8- System displays a message that (invalid SSN, SSN does not exist) Alternate Scenario2 (Voting Day) 7- The system does not permit editing during voting Process. 8- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 60
- 61. Delete Voter Description Administrator must be able to delete Voter. Administrator deletes Voter Title: Administrator deletes Voter data. Intent: Administrator interacts with the system during deleting Voter data. Preconditions Administrator login. Voter data already recorded. Actors 4- Administrator Main Scenario 13-Administrator selects voter to be displayed and press delete. 14- Confirmation message displayed to confirm deletion Specification process. s 15- Administrator press delete button. 16-Voter is deleted. Alternate Scenario1 (Voting Day) 7- The system does not permit deleting during voting Process. 8- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Display Voter Data Description Administrator must be able to display Voter. Page 61
- 62. Administrator displays Voter Title: Administrator displays Voter data. Intent: Describe Administrator interacts with the system during displaying Voter data. Preconditions Administrator login. Voter data already recorded. Actors 3- Administrator Main Scenario 11-Administrator login to Manage voter’s module. 12-All voters appear with their basic data (Id, Name, and precinct). 13-Administrator selects a voter. 14-Voter information is displayed in details. Alternate Scenario1 7- The first time Administrator is logged to the system and Specifications no voter exists 8- The system displays a message welcome the Administrator and tells him that there is no data is recorded in the system yet. Alternate Scenario2 Uses/Extends Included1 Sort: 7- Administrator press any column title in the display page(ID, Name, Precinct) 8- Voters are sorted according to the pressed column title. Included2 Search: 10-Administrator type voter name and press search button 11-Matching voters appear in the result. 12-If there is no result, not found message appear. Included3 Filter: 10-Administrator selects criteria to filter with (precinct) 11-Matching voters appear in the result. 12-If there is no result, not found message appear. Frequency Frequent Issues N/A Priority High Voting Process Use case Page 62
- 63. Voter verification Description Admin shall be able to verify voter SSN, finger print Specifications Verify user SSN and finger print Page 63
- 64. Title: Admin verify user SSN and finger print Intent: Describe Admin interaction with the system during verifying voter SSN, and finger print Preconditions 1. Voter is registered before in the system Actors 1- Admin 2- Voter Main Scenario 1. Use case begins when admin decide to verify voter SSN, and finger print before voting process. 2. Admin insert user SSN and press verify button 3. User information page appear with requesting user finger print 4. User inserts his/her finger print 5. Finger print is verified and message appear that user is verified successfully Alternate Scenario1 1. Voter SSN Not registered in the system 2. System displayed a message that this SSN not registered in the system Alternate Scenario2 1- Voter SSN verified before in the system 2- System displayed a message that this SSN has been verified before Alternate Scenario3 1- Admin inserted a wrong SSN(not registered/wrong format/verified) 3 times 2- System displayed a message and sound alert for the judge that a wrong entry is done. Alternate Scenario4 1- Voter insert wrong finger print 2- System displayed a message that wrong finger print is entered. Uses/Extends N/A Frequency Frequent Issues N/A Priority High Opening session Admin shall be able to open session for voter to cast his Description vote Specifications Opening session for user caste vote Title: Admin open session for user to caste vote Page 64
- 65. Intent: Describe Admin interaction with the system during opening the session Preconditions 1- User has passed verification process 2- User has not cast vote before Actors admin Main Scenario 1- Admin press activation button. 2- Session is opened and candidate selection page appear Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 65
- 66. Voter cast hisvote User should be able to cast his vote for a specific Description candidate User cast his vote for a specific candidate Title: Voter cast his vote for a specific candidate Intent: Describe voter interaction with the system during vote casting Preconditions User has logged in Actors 1- Voter Main Scenario 1- Use case begins when user decides to cast his vote for a specific candidate 2- User press a voter object(Voter image, Full Name, and Election Symbol) 3- System displays popup window containing the select user information and confirmation message for the voter 4- Voter confirm his selection Specifications 5- System display a message that voting is successfully done. 6- Voter session is closed Alternate Scenario1 1- Voter discard the confirmation message 2- The voter page appear for user to select a candidate Alternate Scenario2 1- Voters desires to select a candidate 2- System displays an option with candidates as others Alternate Scenario3 1- Session time out 2- The vote is calculated as other and user is terminated Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 66
- 67. Manage voting process Description Judge shall be able to manage the poll station Judge Manage poll station Title: Judge manage the voting system in the committee Intent: Describes the judge manage process to the system Preconditions N/A Actors 1- Judge Main Scenario 1- Judge inserts his user name and password for all machines within the poll station 2- All machines are logged to the system. 3- Judge monitors the admin clerks during their work. Specifications 4- After the election time finish the judge press sign out Alternate Scenario1 1- Wrong user name or password inserted 2- System displays a message that a wrong password is inserted Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 67
- 68. Reporting Use Case Page 68
- 69. Filter result Judge staff shall be able to filter results according criteria: No of votes in each polling station, No of votes for each Description candidate, No of votes for each candidate in a specific(polling station, polls) Filter Result Title: Judge Filter the result as a requested criteria Intent: Describe judge interaction with the system during filtering result Preconditions Judge is logged in Actors Judge Main Scenario 1- The use case starts when the judge decides to display results with a specific orientation. 2- Judge selects precinct. 3- Judge selects polling station. 4- Judge selects polls Specifications 5- Judge selects candidate. 6- Judge selects filter button. 7- Results for the selected criteria appear. Alternate Scenario1 1- Judge not select a filter type 2- The system displays all in each combo box as a default value. Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 69
- 70. Generate reports Judge staff shall be able to generate report for filtered Description result. Generate reports Title: Judge generates report for filtered data Intent: Describe generating report Preconditions Judge is logged in Actors Judge Main Scenario 1- Judge press report button 2- New window open containing report with selected criteria, and containing the report generating date and time, and judge who generated the report. Specifications Alternate Scenario1 3- Judge not select a filter type 4- Message appear that user shall select criteria first Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 70
- 71. Print report Description Judge shall be able to print generated report. Print report Title: Judge print generated report Intent: Describe r printing report Preconditions Judge is generated report User printer is configured to the system Actors Judge Main Scenario Specifications 1- Judge press print report button 2- Printing setting window open for user to select printing configuration Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 71
- 72. 2.7 E-voting StateChart Diagram Admin state chart 1 Page 72
- 73. Voting state chart1 Page 73
- 74. 2.8 E-voting ActivityDiagram E-Voting Activity Diagram PreVoting Voting Post Voting Not Valid Authenticate Check Start Admin user validity and password Valid Start Admin Manage Check Manage Admin Committee authority Candidate Authenticate Voter ID and Not Valid Manage fingerprint Admin Manage Voters Check validity End Valid Caste Vote Voter Voter Confirm Perform selection Counting Generate Judge Judge report End Activity Diagram 1 Page 74
- 75. 2.9 Package Diagram Package Diagram 1 Page 75
- 76. Chapter Three System Design Page 76
- 77. 3.1- Application Architecture E-voting application architecture 65535 Page 77
- 78. 3.2 E-voting SystemDatabase ERD E-Voting ERD 1 Page 78
- 79. 3.3 E-voting SystemDatabase Mapping Page 79
- 80. 3.4 Data baseschema Page 80
- 81. 3.5 Sequence Diagram Voting Sequence diagram 1 Add Sequence diagram 1 Page 81
- 82. Delete Sequence diagram1 View Sequence diagram 1 Page 82
- 83.
- 84. 4.1 Component diagram Component diagram 1 Page 84
- 85. 4.2 Deployment diagram Deployment diagram 1 Page 85
- 86. 4.3 Network Infrastructureand VPN E-Voting Network Infrastructure & VPN (Ver. : 1.2.0) AD A D S S ta SL M L M ndby Ho odem ode m t Poll Station 1 VPN / Firewall Clients (IPS) Sw it ` ` ch ` ` ` ` ` ` ` ` VPN Tunnel AD S AD Child Domain SL LM Mo DataBase Server od e d em m VPN / Firewall (IPS) H ot S ta ndb VPN Tunnel y Application Server Switc h Domain Controller Additional Domain AD VPN Tunnel Controller SL A D S ta M Clients Ho ode m S L ndb t ` M od y ` Hot DataBase Standby DataBase em Server Server ` ` ` Poll Station 2 ` VPN / Firewall ` Clients (IPS) Sw it ` ` ch ` ` ` Hot Application Standby Application ` ` ` Head Quarters Server Server ` ` Child Domain DataBase Server Application Server Page 1 Page 86
- 87. 4.4 Application Interface Login Form Home page Add candidate symbol Page 87
- 88. Add Candidate Edit candidate Viewcandidate Page 88
- 89. Add Voter Select Candidate Page 89
- 90. Chapter Five System Testing Page 90
- 91. 5.1 INTRODUCTION The Software Test Plan (STP) is designed to prescribe the scope, approach, resources, and schedule of all testing activities. The plan must identify the items to be tested, the features to be tested, the types of testing to be performed, the person responsible for testing, the resources and schedule required to complete testing, and the risks associated with the plan. 5.1.1 Objectives - Describe the strategy for Testing for the <E-Voting> to verify compliance with requirements as specified in the requirement document. - Ensure all requirements for testing the < E-Voting > System are appropriately assessed and planned within the overall Project Plan. - Demonstrate to all stakeholders that the testing processes to be undertaken will be appropriately managed and controlled. 5.1.2 Testing Strategy Testing is the process of analyzing a software item to detect the differences between existing and required conditions and to evaluate the features of the software item. Specific test plan components include: - Purpose for this level of test, - Items to be tested, - Features to be tested, - Features not to be tested, - Management and technical approach, - Pass / Fail criteria, - Individual roles and responsibilities, - Schedules, and - Risk assumptions and constraints. Page 91
- 92. 5.1.3 Scope Testing will be performed at several points in the life cycle as the product is constructed. Testing is a very 'dependent' activity. As a result, test planning is a continuing activity performed throughout the system development life cycle. Test plans must be developed for each level of product testing throughout the major steps of the system: 1- Pre-Voting (preparing administration, committee, candidates, and voters) 2- Voting (Voting process itself) 3- Post-Voting(Result counting and generating reports) 5.1.4 Reference Material To successfully carry out the testing the tester should be provided with: • System requirements specifications. • High level design document. • Use cases. • Detail design document. • Features list. • User interface. 5.2 TEST ITEMS Specify the test items included in the plan. Supply references to the following item documentation: - Requirements specification, - Design specification, - Users guide, - Operations guide, - Installation guide, - Features (availability, response time), - Defect removal procedures, and - Verification and validation plans. 5.2.1 Program Modules (Outline testing to be performed by the developer for each module being built.) Page 92
- 93. - Developers Performcode inspection/Coverage test and report the result. Page 93
- 94. - The followingModules shall be included in the testing: D- Pre-voting phase: 5- Manage admin 6- Manage election committee 7- Manage candidates 8- Manage voters E- Voting phase 2- Submit vote F- Post-voting phase 3- View results 4- Generate reports - Each of the above modules has their sub modules that will mentioned separately in the detailed test plan for each module. 5.2.2 User Procedures Describe the testing to be performed on all user documentation to ensure that it is correct, complete, and comprehensive.) Be Performed by QA Engineer. 5.2.3 Operator Procedures (Describe the testing procedures to ensure that the application can be run and supported in a production environment (include help Desk procedures)). - System and acceptance testing will be performed on a testing server that is same as the production environment. - PM shall ensure that required environments by testing are available. - PM shall ensure that the version is uploaded on the test server. - All critical test cases will be executed on those environments. 5.3 Features to Be Tested (Identify all software features and combinations of software features to be tested. Identify the test design specifications associated with each feature and each combination of features.) A- Pre-voting phase: 1- Manage admin 2- Manage election committee 3- Manage candidates 4- Manage voters B- Voting phase 1- Submit vote C- Post-voting phase Page 94
- 95. 1- View results 2- Generate reports 5.4. FEATURES NOT TO BE TESTED (Identify all features and specific combinations of features that will not be tested along with the reasons.) - All the listed features will be tested 5.5. APPROACH The testing methodology used is black box testing where black box testing is testing without knowledge of the internal workings of the item being tested. For example, when black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but not how the program actually arrives at those outputs. It is because of this that black box testing can be considered testing with respect to the specifications, no other knowledge of the program is necessary. For this reason, the tester and the programmer can be independent of one another, avoiding programmer bias toward his own work. For this testing, test groups are often used, "Test groups are sometimes called professional idiots...people who are good at designing incorrect data." Also, due to the nature of black box testing; the test planning can begin as soon as the specifications are written. The opposite of this would be glass box testing, where test data are derived from direct examination of the code to be tested. For glass box testing, the test cases cannot be determined until the code has actually been written. Both of these testing techniques have advantages and disadvantages, but when combined, they help to ensure thorough testing of the product. In addition, include a description of how many times any testing procedure will be executed e.g. testing will be structured into test cycles. A test cycle is a complete pass through all the required tests. When new versions of the <Verticals> System are delivered during testing, the Testing Team will cease the current cycle at an appropriate time and commence anew cycle. Each new cycle will include any retesting for problems corrected. It is expected, due to time constraints with this project, that only two test cycles may be possible. Page 95
- 96. 5.5.1- System testing Wherethe system as a whole is tested against the Design Specifications: - System Testing will be the responsibility of testing engineer - System and integration testing shall be performed to ensure that the system works as a whole - A System Test Plan will be prepared by the test manager. - System Testing will be performed jointly by testing engineer - System Testing will be performed in the test environment located on the test server. - System Testing will include volume testing (with a high number of transactions and records processed) and stress testing (with transactions processed at high frequency). - Results of tests will be recorded and where system components do not perform as expected, a Test Problem Report will be raised. - Refer to the System and integration test cases. 5.5.2- Acceptance testing Where the system is tested against the Functional Specifications in simulated live operation:- 1- Acceptance Testing will be undertaken on the production server. 2- A specific set of test cases will exist for each function. Check all the links: - Test the outgoing links from all the pages from specific domain under test. - Test all internal links. - Test links jumping on the same pages. - Test links used to send the email to admin or other users from web pages. - Test to check if there are any orphan pages. - Lastly in link checking, check for broken links in all above- mentioned links. - Automation anywhere tool will be used. Test forms in all pages: Forms are the integral part of any web site. Forms are used to get information from users and to keep interaction with them. So what should be checked on these forms? Page 96
- 97. - First check all the validations on each field. - Check for the default values of fields. - Wrong inputs to the fields in the forms. - Options to create forms if any, form delete, view or modify the forms. Cookies testing: - Test the application by enabling or disabling the cookies in your browser options. - Test if the cookies are encrypted before writing to user machine. - Check for login sessions and user stats after session end. Validate HTML/CSS - http://validator.w3.org/ is used. Database testing Query response time The turnaround time for responding to queries in a database must be short. The results from this testing may help to identify problems, such as bottlenecks in the network, specific queries, the database structure, or the hardware. Data integrity - Test the creation, modification, and deletion of data in tables as specified in the functionality. - Test that when a particular set of data is saved to the database, each value gets saved fully. In other words, the truncation of strings and rounding of numeric value does not occur. - Test whether default values are saved in the database if the user input is not specified. - Test the compatibility with old data. In addition, old hardware, versions of the operating system, and interfaces with other software need to be tested. Page 97
- 98. Usability Testing Test fornavigation: - How the user surfs the web pages, different controls like buttons, boxes or how user using the links on the pages to surf different pages. - Web site should be easy to use. - Instructions should be provided clearly. - Main menu should be provided on each page. It should be consistent. Content checking: - Content should be logical and easy to understand. - Check for spelling errors. - Use of dark colors annoys users and should not be used in site theme. - All the anchor text links should be working properly. - Images should be placed properly with proper sizes. Other user information for user help: - Site Map should be present with all the links in web sites with proper tree view of navigation. - Check for all links on the sitemap. - Search in the site” option will help users to find content pages they are looking for easily and quickly. Interaction between servers: - Errors are handled properly (Properly and in a friendly helpful and even funny manner. Please refer to http://www.smashingmagazine.com/2007/08/17/404-error-pages-reloaded/). - If database or web server returns any error message for any query by application server then application server should catch and display these error messages appropriately (Properly and in a friendly helpful and even funny manner. Please refer to http://www.smashingmagazine.com/2007/08/17/404-error- pages-reloaded/) to users. - Check what happens if user interrupts any transaction in- between. Page 98
- 99. - Check whathappens if connection to web server is reset in between. Compatibility Testing: - Browser compatibility (IE6, IE7, FF3, FF4). - Operating system compatibility. Performance testing: Identify performance acceptance criteria - 1 Identify key scenarios - 2 Create a workload model - 3 Identify the target load levels - 4 Identify metrics - 5 Design specific tests - 6 Run tests - 7 Analyze the results - 8 Web server stress tool will be used- Total page size HTML size URL Size Comment KB Image size URL Size Comment KB Client side script size URL Size Comment KB Page 99
- 100. Number or requestsper page (per event) URL No. requestsComment Processor and memory consuming Client Side Close all programs and then open a browser and the task manager, then open the site and use it while recording the CPU and memory usage. Server Side For each component of the system using a simulator to simulate a user who will stay for 5 minutes in the site doing one single action or every possible action that is supported by the system and log the processor and memory usage. While the user is working another user will open the site and do the same functions. Test time cost in different internet speeds Dial up Time cost for each component loading URL Time sec Comment DSL 256 Time cost for each component loading URL Time sec Comment Page 100
- 101. DSL 512 Time cost for each component loading URL Time sec Comment Security Testing: - Test by pasting internal URL directly into browser address bar without login. Internal pages should not open. - If you are logged in using username and password and browsing internal pages then try changing URL options directly. I.e. If you are checking some users profiles with user ID= 123. Try directly changing the URL user ID parameter to different user ID which is not related to logged in user. Access should be denied for this user to view others stats. - Try some invalid inputs in input fields like login username, password, and input text boxes. Check the system reaction on all invalid inputs. - Web directories or files should not be accessible directly unless given download option. - Test if SSL is used for security measures. If used proper message should get displayed when user switch from non- secure http:// pages to secure https:// pages and vice versa. - All transactions, error messages, security breach attempts should get logged in log files somewhere on web server. GUI Test Test each toolbar and menu item for navigation using the- .mouse and keyboard .Test window navigation using the mouse and keyboard- Test to make sure that proper format masks are used. For- example, all drop-down boxes should be properly sorted. .The date entry should also be properly formatted Test that the colors, fonts, and font widths are to standard- .for the field prompts and displayed text Test that the color of the field prompts and field background- .is to standard in read-only mode Make sure that vertical scroll bars or horizontal scroll bars- .do not appear unless required Test that the various controls on the window are aligned- .correctly .Make sure that the window is resizable- Page 101
- 102. Check the spellingsof all the text displayed in the window,- such as the window caption, status bar options, field .prompts, pop-up text, and error messages Test that all character or alphanumeric fields are left-- .justified and that the numeric fields are right-justified .Check for the display of defaults if there are any- In case of multiple windows, check that they all have the- .same look and feel .Check that all shortcut keys are defined and work correctly- Check for the tab order. It should be from top left to bottom - right. Also, the read-only/disabled fields should be avoided .in the TAB sequence Check that the cursor is positioned on the first input field- .when the window is opened Make sure if any default button is specified, it should work- .properly .Check for proper functioning of ALT+TAB- Ensure that each menu command has an alternative hot key- sequence and that it works correctly. (See Appendix B & (.Appendix C Check that there are no duplicate hot keys defined on the- .window Validate the behavior of each control, such as push button,- .radio button, list box, and so on Test to make sure that the window is modal. This will- prevent the user from accessing other functions when this .window is active .Test that multiple windows can be opened at the same time- .Make sure that there is a Help menu- Check to make sure that the command buttons are grayed- .out when not in use 5.6. PASS / FAIL CRITERIA (Specify the criteria to be used to determine whether each item has passed or failed testing.) 5.6.1 Suspension Criteria (Specify the criteria used to suspend all or a portion of the testing activity on test items associated with the plan.) - Unavailability of external dependent systems during execution. Page 102
- 103. - When adefect is introduced that cannot allow any further testing. - Critical path deadline is missed so that the client will not accept delivery even if all testing is completed. - A specific holiday shuts down both development and testing. 5.6.2 Resumption Criteria (Specify the conditions that need to be met to resume testing activities after suspension. Specify the test items that must be repeated when testing is resumed.) - When the external dependent systems become available again. - When a fix is successfully implemented and the Testing Team is notified to continue testing. - The contract is renegotiated with the client to extend delivery. - The holiday period ends. 5.6.3 Approval Criteria The acceptance criteria’s are met. 5.7. Testing Process 5.7.1 Test Deliverables .Test plan -1 .(Test Status Report (an excel file -2 .Bugs are reported through excel file -3 Recommendations – this may include the risk strategy to be -4 .adopted and the impact/consequences of such a strategy 5.7.2 Testing Tasks (Identify the set of tasks necessary to prepare for and perform testing activities. Identify all intertask dependencies and any specific skills required.) - Manage Test and coordinate e Testing Activities: - Prepare the Test Plan and Test procedures and request/obtain the necessary Test resources and execute the planed tests. - Advise on establishment and training of the Test team - Coordinate compilation of, and access to, Test data. - Formally report to the Management on the status of Testing. - Ensure that Tests are completed to the agreed schedule; - Review Test results. - Ensure Tests are repeated where necessary. Page 103
- 104. - In theevent of serious problems, determine whether to recommend Suspension or cancellation of Testing. - Recommend formal acceptance of the system to management. 5.7.3 Responsibilities Stakeholder Reason Individual Develop test plan, Manage Testing testing process, Report M.Shalash manager testing status Test Engineer Execute Test Plan M.Shalash Technical Provide hardware and Maged support recourses required Elwakeel Engineer 5.7.4 Resources Physical Resources: 1- PC CPU2.8 and RAM 1G. 2- Test server. 3- Finger print machine Human Resources: 1- Testing Engineer. 5.7.5- Schedule Design test cases Executing test cases Module estimation(man estimation(man day) day) 1- Manage admin 2 hours 1hour 2- Manage election 2 hours 1hour committee 3- Manage candidates 2 hours 1hour 4- Manage voters 2 hours 1hour 5- Submit vote 3hours 2hours 6- View results 2hours 2hours 7- Generate reports 1 hour 0.5hour Total 14 8.5 22.5 hours, approximately 3 working days. Page 104
- 105. 5.8. Environmental Requirements 5.8.1Hardware 1- High quality test server that works on internet 2- Finger print machine. 3- PC for testing. Software 1- Windows(XP, 7) 2- Web server stress tool. 3- Link checker. 4- Y slow 5- SQL inject me 5.8.3 Risks and Assumptions .Delivery of a third party product .1 .New version of interfacing software .2 .Ability to use and understand a new package/tool, etc .3 .Extremely complex functions .4 .Modifications to components with a past history of failure .5 .Poorly documented modules or change requests .6 .Lack of personnel resources when testing is to begin -7 .Lack of availability of required hardware, software, data or tools -8 .Late delivery of the software, hardware or tools -9 There are some inherent software risks such as complexity; these .need to be identified .Safety .1 .Multiple interfaces .2 .Impacts on Client .3 .Government regulations and rules .4 Page 105
- 106. Conclusion and futurework This paper describes some of the technological activities we have been carrying out within the E-Voting project, which has the goal of introducing e-voting systems for the next presidential elections. We believe that a transition to new technologies, especially in a country which is particularly cautious towards new technologies in the polling stations requires a multi-disciplinary approach that allows taking into account not only the usability requirements of the voters, but also those non-functional requirements that help guaranteeing security and build trust on the new voting machines. So far, we tested our prototypes in pilots that are among the largest e-voting tests ever performed. Several changes and refinements still need to be implemented in the e-voting solutions, both functional (like audio interfaces for visually impaired people) and non functional, in order to reduce costs, size, and improve robustness of the prototypes. The technological actions described above, together with the sociological, communication, and normative actions planned for the second phase will gradually broaden the size of experimentations to the whole province, allowing for a smooth introduction of e-voting systems in the province of Egypt. Page 106
- 107. References -The Risk of e-Voting: Thomas W. Lauer School of Business Administration, Oakland University, Rochester, USA - E-Government in Singapore ?A Swot and Pest Analysis HUONG HA Department of Management, Monash University, Australia Huong.Ha@BusEco.monash.edu.au KEN COGHILL Department of Management, Monash University, Australia Ken.Coghill@BusEco.monash.edu.au - Specification of the Control Logic of an eVoting System in UML: the ProVotE experience Roberto Tiella, Adolfo Villafiorita, and Silvia Tomasi Automated Reasoning Systems Division Center for Scientific and Technological Research (ITC-irst) {tiella,adolfo,sitomasi}@irst.itc.it WWW home page: http://sra.itc.it/provote - Electronic Voting Ronald L. Rivest Laboratory for Computer Science Massachusetts Institute of Technology Cambridge, MA 02139 rivest@mit.edu - Analysis of an Electronic Voting System TADAYOSHI KOHNO ADAM STUBBLEFIELD† AVIEL D. RUBIN‡ DAN S. WALLACH§ February 27, 2004 - Competent Electronic Participation Channels in Electronic Democracy Dimitrios Zissis, Dimitrios Lekkas and Anastasia-Evangelia Papadopoulou Department of Product and Systems Design Engineering, Syros, Greece - http://wwwx.cs.unc.edu/~sparkst/comp204/vote/index.html Page 107
- 108. - http://www.scribd.com/doc/42008769/Electronic-Voting- System - http://eprints-phd.biblio.unitn.it/ - Nirwan Ansari, Pitipatana Sakarindr, Ehsan Haghani, Chao Zhang, Aridaman K. Jain, and Yun Q. Shi. Evaluating electronic voting systems equipped with voter-verified paper records. IEEE Security and Privacy, 6(3):30–39, 2008. - Adam Aviv, Pavol Cerny, Sandy Clark, Micah Sherr Eric Cronin, Gaurav Shah, and Matt Blaze. Security Evaluation of ES&S Voting Machines and Election Management System. In In Proc. of the USENIX/ACCURATE Electronic Voting Technology Workshop, 2008. - Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr. Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE Transactions on Dependable and Secure Computing, 01(1):11–33, 2004. - Davide Balzarotti, Greg Banks, Marco Cova, Viktoria Felmetsger, Richard Kemmerer, William Robertson, Fredrik Valeur, and Giovanni Vigna. Are Your Votes Really Counted? Testing the Security of Real-world Electronic Voting Systems. In Proceedings of the International Symposium on Software Testing and Analysis (ISSTA), pages 237– 248, 2008. - Weldemariam, Komminist Sisai (2010) Using Formal Methods for Building more Reliable and Secure e-voting Systems. PhD thesis, University of Trento, Center for Information Technology (FBK-Irst). http://eprints-phd.biblio.unitn.it/253/ Page 108