Skip to content
This repository has been archived by the owner on Mar 31, 2022. It is now read-only.

Latest commit

 

History

History
113 lines (90 loc) · 7.71 KB

SAD.md

File metadata and controls

113 lines (90 loc) · 7.71 KB
Raw

Software Architecture Document

Table of Contents

  1. Introduction
  2. Architectural Representation
  3. Architectural Goals and Constraints
  4. Use-Case View
  5. Logical View
  6. Process View
  7. Deployment View
  8. Implementation View
  9. Data View
  10. Size and Performance
  11. Quality

1. Introduction

1.1 Purpose

This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.

1.2 Scope

This document describes the technical architecture of the TaskHub project, including the structure of classes, modules and dependencies.

1.3 Definitions, Acronyms and Abbreviations

Abbrevation Description
API Application programming interface
REST Representational state transfer
SRS Software Requirements Specification
UC Use Case
VCS Version Control System
n/a not applicable

1.4 References

Title Date Publishing organization
TaskHub Blog 2020-12-03 TaskHub Team
Repository on GitHub - Code 2020-12-03 TaskHub Team
Repository on GitHub - Docu 2020-12-03 TaskHub Team
UC Assign Student 2020-12-03 TaskHub Team
UC Assign Teacher 2020-12-03 TaskHub Team
UC CreateAClass 2020-12-03 TaskHub Team
UC CreateTask 2020-12-03 TaskHub Team
UC EditSolution 2020-12-03 TaskHub Team
SRS 2020-12-03 TaskHub Team

1.5 Overview

This document contains the Architectural Representation, Goals and Constraints as well as the Logical, Deployment, Implementation and Data Views.

2. Architectural Representation

Architecture

3. Architectural Goals and Constraints

We are dividing the Frontend,Backend and Database. That we can swap each component very easily.

Database

For the Database we use Postgre, because we used that in the Past and are familiar with it.

Backend

For the Backend we use a Node.js Server with ExpressJS and Sequelize to generate an REST API.

Frontend

For the Frontend we use Angular to build our Webapp and connect to the REST API to get our Data.

4. Use-Case View

Use Case

5. Logical View

Backend The Backend is split into the different API endpoints, allowing for easy understanding. For every endpoint, there is a router class, a service class and some interfaces. The router class handles the incoming requests and sends the responses and the service class is used for accessing the database and performing other checks, such as authorization.

Frontend The components in the frontend are divided into "pages" and "components" with pages being the angular components that build a whole page and components being small template components that can be used on different pages when needed

6. Process View

  • When the user opens our page, the angular application is downloaded to the user's computer. By clicking through the pages, the application performs HTTP requests to our backend to load the required data.
  • If the user wants to add another product, the backend performs a callout to one of our crawling instances, causing it to fetch the required product details.
  • The nightly crawling process is centrally triggered from one crawler load balancing instance. This instance sends requests to the normal crawler instances, distributing the crawling tasks across all available instances.

7. Deployment View

Deployment View

8. Implementation View

n/a

9. Data View

Database View

10. Size and Performance

n/a

11. Quality

1.1 Design Patterns

Design patterns are proven solution templates for recurring design problems in software architecture and software development. Here you can see a detailed documentation of our design patterns. In the following you cann se which design patterns are used by our framewroks.

1.1.1 Express.js

  • Singleton: This pattern ensures that there is exactly one object of a class.
  • Prototype: With this pattern, new instances are created on the basis of templates. The template is copied and adapted to new requirements.

1.1.2 Angular

  • Observers: It belongs to the behavioural patterns category and is used to transfer changes to an object to structures that are dependent on this object.
  • Dependency injection: It is a design pattern in object-oriented programming and regulates the dependencies of an object at runtime.

1.2 Metrics

We are planning to use Jenkins as an continuous integration tool to ensure a high quality of our development process. Whenever there is a new commit to a pull request or the master branch it automatically builds the project and executes all tests. The Jenkins build result will be displayed beside each commit on Github.

  • Reducing the amount of Bugs/Issues/Code Smells raised by Codacy. Here you can see an overview.