Architectural Requirements Specification Project Odin

Kyle Erwin Joshua Cilliers Jason van Hattum Dimpho Mahoko Keegan Ferrett Note: This document is constantly under revision due to our chosen methodology, and is subject to change.

Current version: v1.0

Contents

Contents Introduction . . . . . . . . . . System Architectural Design Description of Components User Interface Design . . . . Additional Material . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. 1 . 2 . 5 . 10 . 14

Introduction .1

Purpose

This Architectural Requirements Specification provides a qualitative and quantitative view of the architecture that will be used for Project Odin, including the components, their interactions with each other and other systems.

1

System Architectural Design .1

Chosen System Architecture

The system architecture we decided upon is the microservices architecture. Project Odin will be decomposed into four lightweight, loosely-coupled services that interact with each other to provide the underlying service. All of the services in Odin will communicate over technology-agnostic network sockets, and all of them will run in containerized environments such as Docker. The benefits of this are: • Improved modularity. • Makes the system easier to understand, develop and test. • Allows the system to be developed and deployed in parallel by small autonomous teams. • The system is easy to scale by simply scale individual services. • It is easy to refactor and update individual microservices. • Enables continous delivery and deployment. Under this architecture, the system will be decomposed into four systems: • Odin-CLI • Odin-Web • Odin-Daemon • Odin-Api

2

Figure 1: Deployment diagram

.2 .2.1

Discussion of Alternate Designs Multitier architecture

The architectural style known as n-tier or multitier is an architecture in which presentation, application processing and data management functions are physically separated. This could work for our system (ntier is physically quite similar to microservices), with our Odin-Web component fulfilling the role of presentation, Odin-Daemon and Odin-CLI as processing and Odin-API as data management. The reason we did not go for this style is we felt the separation into more components was beneficial due to the increased cohesion and reduced coupling, resulting in a system that was easier to test and develop in parallel. Additionally, n-tier traditionally has a very unidirectional data flow, while we felt that the data flow of Odin is more bidirectional. .2.2

Pipeline architecture

A pipeline architecture consists of a chain of processing elements arranged in such a way that the output of one element is the input of the next. This was a viable architecture for Odin as we could arrange it so that the web app outputs to the web API, which outputs to the Daemon. The benefit of this is that the input of each component is well-defined. The largest problem with this is that this is has a strictly one-way flow of data - the data flows from the Web to the Daemon. Therefore there is no way for the users to get feedback, which is an essential part 3

of the system. Additionally, the components or processing elements are very tightly coupled, with each element depending absolutely on the element before it.

.3

System Interface Description

The interface of this system will initially be the user interface in Odin-Web, wherein the user will be able to develop their algorithmic models, import components, execute sessions and share their projects. However, eventually, the idea is to allow a RESTful API service wherein other applications can hook in to a model to get it’s output.

.4

Access Channel Requirements

Project Odin is meant to primarily cater for browser clients due to its large Design Space which makes it cumbersome tool to have to port to mobile application clients.

4

Description of Components .1 .1.1

Odin-CLI Technologies

The command line interface will be implemented in Python 3, using built-in classes and libraries to provide a usable interface. TCP sockets will be used for communication, with the interaction handled by Python’s standard libraries. The testing framework pytest will be used for testing purposes. .1.2

Structure

Figure 2: CLI Class diagram

5

.2 .2.1

Odin-Daemon Technologies

The Daemon will be implemented in C++, using the rapidJSON tool to facilitate communication between the CLI and using our own classes for the operations needed to perform calculations on n-rank matrices .2.2

Structure

Figure 3: Daemon Class diagram

6

.3

Odin-Web

The Web-Frontend serves as the main user interface for the program. It makes use of Angular 4 as a framework and uses MDbootstrap for all markup.

Figure 4: Web Class diagram

7

.4

Odin-API

The API serves as the web interface’s backend and is built around an Express framework. It handles all requests from the frontend as well as routing and communication with the CLI.

Figure 5: API Class diagram

8

.5

Expected interaction between services

Todo:complete Web and API sections of Activity diagram The following activity diagram demonstrates the expected interaction between our services.

9

User Interface Design .1

Description of the User Interface

The design will be implemented using Angular 4 as a framework for the Web frontend with tools such as MDBootstrap and D.js The proposed layout of the website will be broken down into the following pages: • Login and Registration • Home page • Projects (browsing) • Design Space • Packages (browsing and managing) • Profile

10

.2

Mockups

Will be expanded later - UI has not been mocked up or implemented.

Figure 6: Design Space Mockup

Figure 7: Projects Page Mockup

11

Figure 8: Packages Page Mockup

12

.3

Objects and Actions

.3.1

Projects

• View projects • Edit projects .3.2

Design Space

• Create projects • Add components • Link components • Add input • Save projects • Execute projects • Export projects .3.3

Packages

• View packages • Add packages to projects

13

Additional Material .1

Glossary of terms • Component - A project that is used in another project. • Model - A computational model built in the application. • Odin - This product. • Project - A computational model that has been shared. • User - A user that is using the application.

14

15

16