Architecture - 1154046/Tutor-Tracker GitHub Wiki

1. Architectural Representation

This document presents the architecture as a series of views; Logical view – Class diagram, Process view – Activity diagram, Development view – Component view and Physical view – Deployment view . These are views on an underlying Unified Modeling Language (UML) model.
Before, jumping into the Views, Audience refers to people who will be dealing with the particular view at that time and Area explains what each view achieves.

1.1 Process View

  • Audience: Developers, Integrators.
  • Area: Non-functional requirements, describes the design’s concurrency and synchronization aspects.

1.2 Development View

  • Audience: Developers, Testers.
  • Area: Software components, describes the modules and subsystem divisions of the system.

1.4 Physical View

  • Audience: System engineers, Deployment managers.
  • Area: Persistence- describes architecturally significant persistent elements in the data model. Describes the mapping of the software onto the hardware and shows the system’s distributed aspects.

2. Architectural Goals and Constraints

There are some key requirements and system constraints that have a significant bearing on the architecture. They are:

2.1 Server side

Tutor tracker will be hosted on a web server. Since this is a web based application, the underlying client OS can be any mobile operating system (IOS and Android). Ionic as a framework, takes care of tasks such as browser difference and client/server communication hence all communication with client has to comply with public TCP/IP communication protocol standards.

2.2 Client side

Users will be able to access tutor tracker only online. Initially, this will be hosted as a standalone application but may later be integrated with other university systems. Clients/users are encouraged to use some of the latest versions of android and ios to achieve full user experience.

2.3 Persistence
All the data will be saved in the remote server.

2.4 Reliability/Availability

The system will be subjected to several continuous testing (unit testing, integration testing, system testing) before being deployed to make sure that the system is reliable. These tests will be implemented at every phase of development. The Firebase server can respond to many clients at the same time while maintaining data integrity.

2.5 Performance

The system performance depends on available hardware, network and internet connection capabilities. Therefore, actual performance can only be determined after the system is deployed and tested.

2.6 Development tools
The project incorporates many development tools.

Programming: node.js Ionic Framework.
Database: Real-time Firebase server.
Diagrams: draw.io
Schedule: taiga.io

3. Architecturally Significant Use Cases

Use Case Diagram:

4. Process view

It elaborates the run time behavior of the system. The Activity diagram illustrates the tutor tracker organized as executable processes. Processes exist to exist to capture, retain and organize tutor information, as would be specified by the tutor.

Activity diagram:

5. Development View

The figure below is a component diagram. It shows the system’s physical structure and pays attention to the system’s components and how they relate.

Component Diagram:

6. Physical View

A deployment diagram is shown below to visualize the software to hardware implementation of the system. The deployment diagram illustrates the flow of data from the moment enters data until the functionality is performed by the system.

Deployment diagram:

Class diagram

⚠️ **GitHub.com Fallback** ⚠️