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 application's data and and items will be stored in a database placed at firebase.
- When the device is connected the data base 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)