Architectural Diagrams - ISIS3510-MOBILE-T34/T34-Wiki-SpendiQ GitHub Wiki
In this section, we present the architectural diagrams, which are part of the technical app design process related to the software components it will be made of.
The prepared architectural diagrams in the UML visual modeling language are:
- Deployment and Context Diagram
- Components Diagram
- Class Diagram
1. Deployment and Context Diagram
Rationale
The main deployment node for the app is the one related to the user's mobile device and platform. In our case, the app will only run in iPhone devices from the iPhone X onwards and from the iOS 12 Operating System version, in the Android case, it will run from the Android OS 5.0 version onwards. The device's operating system node contains an application layer related to the OS, where our App will run, along with a local database to allow the Caching architectural tactic. The SpendiQ app communicates with Services that live inside the device, like the notifications or authentication methods.
The other nodes are related to external services, where Firebase (analytics engine instance), WhatsApp and the Google/Apple Maps are included.
The communication protocols are encripted, and correspond to the HTTPS version 2 protocol. The communication is asynchronous with a retry mechanism that is implemented in the code-level of the related components to assure the accomplishment of the quality attributes described in a further section of the wiki.
2. Components Diagram
Rationale
The components diagram represents the high-level components that make up the application design, along with their communication. The multi-layered (tiers in this case) Architectural style is evident with the division made into different layers like Presentation and Business, which separate responsibilities and communicate with themselves to request and receive data. Three packages were desgined, one for the Models, other for the ViewModels and other for the Views of the application, these are the distinctive organization of the MVVM architectural pattern, which was chosen for the project.
The Presentation layer is composed of the Views and ViewModels, which carry the responsibility of preparing and rendering data for the user to see it in the devices' screens and allow their interaction with the application.
The Business layer contains Models and Services, which have logic related to the data storing and retrieving. They perform methods to have the needed information available for the ViewModels.
These two layers contain Facades, which have the responsibility of being in front of the connection to another layer and receive all methods requests to send later an answer.
Finally, the External Services Layer and the Mobile Device Layer were designed to do a logical separation between these two different kinds of services, which belong to different environments, and build a separate facade to talk with them from inside the app.
3. Class Diagram
Rationale
The class diagram presented contains visual information about the way how the components of the application frontend and backend relate with each other. The language used to draw the diagrams was the UML, and each class box corresponds to a file that will be created with swift or Kotlin inside the iOS and Android separate projects.
The main type of relation between the classes is the dependency, and that indicates that the class needs to use a method or state from the other. No inheritance, composition or aggregation relations were needed in this case due to the design decisions in the architecture.
To know more about the team's rationale related to the Backend architecture, please go to the following route: