This document will describe in detail the software architecture and design of our project. In this document we will describe the structure of the various classes in our project. This document will provide several views of the system design to provide a richer understanding of the system. We intend to capture the significant architectural and design decisions in our project.
- Showing the internal architecture planned for the application.
- Divide the project into organized structures for future tasks distribution.
- Assure the structure correctness.
- Assure the software design modularity.
- Order the application structure to simplify the code that would be written.
| Capability | Description (Original Requirement) | Non-realization outcome |
|---|---|---|
| Main information cards | Show information cards pushed by the organization to the students on the home page | Loss of the main project purpose* |
| Calendar information | Show the organization future events | Loss of a major project purpose* |
| Calendar synchronization | Allow the user to synchronize his personal calendar with the events mentioned in the application | Disorder regarding the organization events within the user base |
| Gallery | Show images from the organization Facebook page | Loss of a major project purpose* |
| Information | Show general information on the organization and its departments | Loss of a major project purpose* |
| FAQ | Provide a frequently asked questioned segment in the application | High number of repetitive questions directed at the organization, causing major time loss |
| Contact page | Provide contact information and a built-in contact system | Disconnection between the organization and its user base |
* Please refer to the project SRS document for information on the project purpose
The diagram shows the basic idea for the application deployment. Please refer to the following notes:
- The application is heavily relying on successful API integration of multiple components, which is obligating a clean and simple design for smooth interrupt-less functionallity
- Most arrows appear two-way to show that data is being delivered back and forth through most of the diagram components, excluding the user client which suppose to only receive data
- Webcal is used for mail synchronization and Facebook API is used for the application gallery
- Data integration, although mostly minimal, will be handled on the server side
| Responsibilities | Collaborators |
|---|---|
| Send notification | Firebase |
| Add new data | Firebase |
| Responsibilities | Collaborators |
|---|---|
| Show stories to clinets | Firebase |
| Show single story on demand | Story |
| Responsibilities | Collaborators |
|---|---|
| Verify Admin login | Firebase |
| Navigate between pages | Home, Gallery, Calendar, Info |
The diagram shows the basic idea for the application. Please refer to the following notes:
- All pages connected to firebase that holds the data for them.
- Firebase is also the "connector" between the admin area and the other pages.
The diagram show what the user can do in the app:
- use the app as admin and edit the data
- use as normal user to get data and notifications
- The application's data and and items will be stored in a database placed at firebase. Data will be stored in non-SQL database with Collection-Document schema.
- When the device is connected the database synchronizes the local data changes in real time.
- The files that going to manage that:
- firebaseCloudFuncs (for admin)
- fcmProvider (for notifications)
- dbProvider (for data sync in real-time)
- Photo Gallery will pull media from Facebook with Facebook's API
- Push notifications will be based on native platform functionality instead web platform's
The updated risk table can be found here
- Push updates: Updates will be uploaded to the app and we'll check for Push notifications across all devices. The test will be a manual check by one of the team members. The test frequency will be performed after any code changes and updates to the operating system.
- Automatic answer matching to questions: Enter different questions and check that the system finds correct answers. Development of an automated test that feeds random questions from a database of questions and checking the correctness of the answers. The test frequency will be done after each relevant code change.
- Calendar: Check that the event was added to the student's personal calendar. Manual review that adds an event to the app and checks that the event has been added to the different calendars. The test frequency will be done after each code relevant change and software updates.
- Gallery: Checking the synchronization between the gallery of the Aguda on Facebook and the gallery in the application. A manual check to see if there was syncing after each album upload. The test frequency will be done after each relevant code change.
After any visual/desing changes the app will be showed to all Aguda members to get their opinion as regular users and get feedbacks.
Each team member will be responsible of his part in the app, and every bug will be handle by him (with help from all the team).