Skip to content

Software Achitecture

1 INTRODUCTION

1.1 Purpose and coverage

The purpose of the document is presented, why it was made and for what purpose and to whom it is intended (implementation team or subcontractor of one's own company or who). List what things are described in the document; especially if the reader is not used to reading design documents. Determine the coverage of the design in relation to the definition. If the design does not cover the entire definition, it should be mentioned here (ie what other documents in the design phase exist, eg if the design of the user interface or database has been detached into its own documents).

1.2 Product and environment

The product is Tukko, Traffic Visualizer created by the IoTiude in 2023. Tukko is a full-stack web application that shows general data and hotspots about Finnish traffic.

Tukko is running on CSC (IT Center for Science) servers, where we have a Linux virtual machine instance. As a modern web application, Tukko will support modern browsers for all operating systems.

Duck Tape Solutions is introducing some new features to make Tukko even more accessible for wider audience and people with disabilites.

1.3 References

** EDIT THIS LATER?**

List references to other sources (documents, standards, manuals, style guides, etc.) in alphabetical order by reference. References include the name, version, date, and where they can be found. Examples include:

  • documents referred to (eg definition)
  • documents related to the system or its construction
  • additional information
  • (coding) style instructions.
  • If the design does not cover the entire specification, it is mentioned here. At the same time, it will be clarified what other documents at the design stage exist.
  • For example, the design of a database or user interface may have been detached as a separate document.

2. SYSTEM OVERVIEW

2.1 Hardware requirements

Our features wont affect the original Tukko hardware requirements. The original Tukko runs across 4 docker containers, taking about 140MiB of RAM when all four are running before too much logging has happened. MongoDB generates the most logs but has limits proportional to the RAM available on the hardware running the container.

CPU must be able to run virtualized software, which in 2023 should be most processors from the last decade.

2.2 Software requirements

This application runs in Docker containers, so you just need Docker installed to use it.

3. DESCRIPTION OF THE ARCHITECTURE

This is the most important point in the design document. The chapter contains things that everyone who implements the system needs to know and understand. The chapter describes (with reasons) e.g. design principles, technology choices, and software architecture in general. It is not necessarily advisable to subdivide into the chapters presented here, but to consider what is the most reasonable order of presentation in each case. For example, sections 3.1 and 3.2 should sometimes be combined.

uml diagram

3.1 Design principles

Our design principles prioritize a user-centered approach, ensuring Tukko is clear, accessible, and visually appealing across the UI and documentation. This is achieved through features that improve data visualization, user interface accessibility, and search functionality, while maintaining a balance between aesthetics and usability. A solid technical foundation is established through automated testing, server performance monitoring, and well-maintained development documentation.

3.2 Software architecture, modules and processes

We are prioritizing features that can be integrated without requiring fundamental changes to the core architecture. The original software architecture of Tukko is as follows:

Frontend

REACT

https://react.dev/

React is a very popular JavaScript framework that allows developers to create more complex and scalable web applications.

VITE

https://vitejs.dev/

Vite is a powerful development server. It has multiple features that make development easy, such as live reload, module bundling and so on.

When building an web application, Vite also makes some performance improvements by converting your entire project into basic HTML, JavaScript and CSS.

NGINX

https://nginx.org/en/

Nginx is an HTTP server that can serve your website to the world. The frontend that Vite builds gets fed to a container running Nginx, which then serves our web application.

Backend

NODE.JS WITH EXPRESS

https://nodejs.org/

https://expressjs.com/

Node.js is a JavaScript runtime, meaning you can run JavaScript code on your computer like you would a regular program. More commonly JavaScript is limited to running in browsers.

With Express, you can create a server that runs Node.js, and is a very popular solution for APIs. Tukkos backend will serve Digitraffic data to our frontend, and Express is a good tool for that.

MONGODB

https://mongodb.com/

MongoDB is an object-based database solution and is built and used with JavaScript. You might see a theme here, it's just JavaScript all the way down. The structure of a MongoDB database is much more flexible as opposed to the more common relational databases.

REDIS

https://redis.io/

Redis is another database solution team IoTude used in the original Tukko. The benefit of Redis over MongoDB is that it supports in-memory storage. This gives massive improvements in looking up data from the database. Each datapoint is also relatively small compared to hardware of today, so quite a bit of data can be stored at once.

Redis is used over MongoDB when the user asks for live data and more recent archival data, but older data is transferred to MongoDB.

General technologies

TYPESCRIPT

https://typescriptlang.org/

TypeScript is a superset of regular old JavaScript. The code is practically the same, and in a minimal setup can literally be the same as JavaScript code.

The benefits of TypeScript though allow developers to debug their code easier, trust their code, and avoid the more careless bugs, as giving your code types lets your tools tell you when you are doing something wrong.

DOCKER

https://docker.com/

Docker is used to containerize everything. Frontend is its own container, while each element of the backend gets their own containers.

How containerization helps, is that it avoids the problem of "it works on my machine", meaning if a developer has tested the container locally, it will also work on our servers.

Docker also makes the stack more secure, as Docker allows the administrator to create strict and secure configurations on how accessible each container is to the public. Our backend for example is completely inaccessible to the outside world, but the frontend can still communicate with it.

3.3 Database Architecture

Original Tukkos database is fairly simple, as it is just one database that holds everything. MongoDB supports objects as it's model, so the following is a paste of the used interface in Tukkos original code to show the structure.

interface Sensor {
  stationId: number,
  name: string,
  shortName: string,
  timeWindowStart: string,
  timeWindowEnd: string,
  measuredTime: string,
  unit: string,
  value: number
}

interface Station {
  id: number,
  tmsNumber: number,
  dataUpdatedTime: string
  sensorValues: Sensor[]
}

interface StationData {
  id?: ObjectId,
  dataUpdatedTime: string,
  stations: Station[]
}

3.4 Error and Exception Procedures

Update later

Error and exception procedures at the general (architecture) level. Chapter 4 describes in more detail at the module level. The texts of the error messages should be attached at the latest during design (it would be better to think about them already at the definition stage). The following types of error handling are taken into account: * general error handling rules * common error handling modules * Recognition of error messages * saving error messages (to memory, to disk) * grouping of error messages (severity, user or system) * error message texts. Action in abnormal situations is part of the specification document, but a position must be taken at the latest in the design. For example, how the system behaves in the event of a power outage: "get up itself" or "get stuck". .

4. FINISHED COMPONENTS AND SPECIAL TECHNICAL SOLUTIONS

** Update after we finish each feature **

If there are finished parts, ie external components, then such are described: * where they are obtained * where they are placed * use * other essentials (so that someone else can compile or add the application). If some things differ from the usual working methods of the project. "Solutions that deviate from standard industry practice" that a person in the industry might not immediately guess. For example, the following, if necessary: * security, safety * backups * recoveries * maintainability * flexibility * portability or portability. Especially if there is some special or unusual way to do something. Implementing tools can also be mentioned here, if it is indeed important to tell already at this (design) stage (rare and not recommended, for example B compiler version 2.77 which supports D library 4.56). The project plan contains detailed information on the implementation tools. For example, can a program automatically recover from power outages or operating system "crashes"?

5. Rejected solutions/ideas

Edit later

Considered, but rejected, solutions should be recorded with their rationale in an appropriate chapter or section with dates. Thus, the next reader of the document sees that something has been thought about as well. Also, if you are reading a design document yourself in six months, it may be difficult to remember what things have been considered when making the system.

At the end of the project, the rejected solution options are collected at the end of the project plan

6. IDEAS FOR FURTHER DEVELOPMENT

Features

  • Downloadable offline map

  • The user will be able to use map in some areas without proper internet connection.

  • Realtime traffic updates

  • The user can plan for the best timing and route according to the realtime updates so that traffic jams could be reduced.

  • Social integration

  • Users can share their route with friends or travelmates in another car.

  • Parking availability information

  • Voice commands

  • Emergency service integration

  • In case of accidents, the user will be asked whether he needs emergency service or not. The emergency service will be auto connected if the user makes no response.

Original Source http://www.cs.tut.fi/ohj/dokumenttipohjat/pohjat/suunnittelu/hytt_drsuunnittelu.doc

Thank you for original authors!