Introduction

Purpose

The Software Architecture Document (SAD) contains the description of the system in terms of its various architectural views, in order to highlight the different aspects of it.

Scope

This Software Architecture Document provides an architectural overview of the Exceed Vote server, administrative interface and mobile client.

Glossary

See SRS Glossary

Architectural Requirements

Non-functional requirements

1. The server side must be developed with Java
2. Voters must be able to vote using their own internet connected smartphone (at least iPhone and Android)
3. The application must be able to support 200 concurrent users
4. Most of the options in this application should be configurable
5. Voters must be authenticated
6. The server can be located locally or remotely

Use Case View

See SRS System Feature

Architecturally-Significant Use Cases

UC1: Make a vote

Assuming voter has already identified themselves, they open the application and see a list of groups. They select a group to vote for. They see the group's project information and voting categories. They enter their scores into the voting form and system will show that the voting has been registered.

UC4: Scan from booth

Voter visits the group's booth. They use their device to detect from a physical object located at the booth and the application will show up with that group's information same as when they have manually select that group.

UC7: Installing a product

Voter open application and select a group from the list of group. The group information shows and user can opt to install that product. If that product is not supported on their device (for example, if they use an iPhone and the product is an Android application, or if their phone runs an ancient version of Android) there should be a visual indicator telling them that installation is not supported on their device and the reason why.

UC8: Authentication by KU student/staff

Voter who has a KU account opens the application and verify their KU account. Application checks with the KU system and logs the user in with access permissions set according to their status in KU. The application should greets the voter by his name.

Logical View

Architecture Overview

The application is splitted into 2 separate applications.

1. Server side
   1. Administrative interface - Handle administrative actions
   2. API - Handle clientside requests
2. Client side - Vote client which runs on user's mobile phone and communicate with server to perform actions.