Software Achitecture
1 INTRODUCTION
1.1 Purpose and coverage
This document provides a summary of each technology that is used. At this point this document was writtend for Gate 1 and some information is missing because we have not yet started to implementation procress fully. From 4. to forward you will find only instructions that have not been modified at this stage.
1.2 Product and environment
Tukko operates on CSC (IT Center for Science) servers, utilizing a Linux virtual machine instance. While Ubuntu 20.04 has been our choice for the virtual machine, Ubuntu 22.04 is also compatible and can be used as an alternative base.
1.4 References
2. SYSTEM OVERVIEW
2.1 Description of the application area
Our product is Tukko, short for Traffic Visualizer. Tukko is a full-stack web application that shows general data and hotspots about Finnish traffic. During this project we will build different features to the tukko base that was providet for us.
2.2 The integration of the system into its environment
2.3 Hardware environment
Tukko application is distributed over several Docker containers, consuming a moderate amount of memory when initially launched. Among these components, MongoDB is notable for producing the majority of logs, though its logging capacity is effectively constrained by the memory capacity of the hosting hardware. For the system to efficiently manage this virtualized environment, the processor must support virtualization technology.
2.4 Software Environment
Since the full stack is containerized with Docker, the only requirement for your environment is compatibility with Docker.
2.5 Key boundary conditions for implementation
In developing Tukko, we operate within a framework shaped by boundary conditions that span legal compliance, intellectual property rights, data security, quality assurance, and user-centric features.
2.6 Agreements and Standards
Our cloud infrastructure is tailored to meet GDPR and other relevant data protection standards, ensuring the safeguarding of personal data. We rigorously respect intellectual property laws to prevent copyright violations, while our data management practices are fortified with strong encryption to maintain data integrity and confidentiality. Security is a priority, with regular vulnerability scans and adherence to ISO/IEC/IEEE 29119-1:2022 standards for manual testing processes, ensuring our software's reliability and quality. You can read more from table of requirements
3. DESCRIPTION OF THE ARCHITECTURE
Deployment Diagram
3.1 Design principles
Our traffic visualizer design is guided by performance and usability. We also want to ensure our application is user-friendly.
3.2 Software architecture, modules and processes
Frontend
React is a popular open-source JavaScript library for building user interfaces, particularly for single-page applications where you need a fast, interactive user experience. This is used beacuse it was originally requested by Combitech and original Tukko that we are working with uses it.
Backend
Node.js is an open-source, cross-platform, JavaScript runtime environment that executes JavaScript code outside a web browser. Express.js is a fast, unopinionated, minimalist web framework for Node.js. Tukko's backend will serve digitraffic data to Tukko's frontend and Express is the best tool for that.
MongoDB is an open-source, document-oriented NoSQL database designed for ease of development and scaling. It stores data in flexible, JSON-like documents, meaning fields can vary from document to document and data structure can be changed over time. Given that MongoDB natively supports JSON, it serves as an excellent database choice for Tukko, especially considering that Digitraffic data is in JSON format
Redis is an open-source, in-memory data structure store, used as a database, cache, and message broker. It supports various data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams. In Tukko, redis is used over MongoDB to acces live data and also newer archived data, but MongoDB itself transfers the older data.
TypeScript is an open-source programming language that is a superset of JavaScript, adding optional static typing and other advanced features to the language. TypeScript's advantages include easier debugging, increased confidence in code, and fewer trivial bugs, thanks to its type system that enables tools to alert developers about potential errors.
Docker is an open-source platform that automates the deployment, scaling, and management of applications inside lightweight, portable containers. Docker encapsulates an application and its dependencies into a container that can run on any Linux or Windows-based system, ensuring consistency across environments and significantly reducing the "it works on my machine" syndrome.
3.3 Database Architecture
Our database structure is quite straightforward, consisting of a single database that encompasses all data.
Example, not the final one
3.4 Error and Exception Procedures
CSC Servers manage errors efficiently by adjusting the distribution of virtual computing resources as needed. Additionally, certain error handling mechanisms are still under development, or we are uncertain whether they will be implemented at all.
4. MODULE / CATEGORY / PROCESS DESCRIPTIONS / No editing from here on
The reading structure of this chapter is designed according to the architecture of the program: If a one-level breakdown is sufficient, the method presented here is used (4.1 Module X, 4.2 Module Y…). For example, if a program is divided into packages that contain multiple categories, you should make a separate section for each package, with each category described in the subsections. Things common to all classes in a package are described at the beginning of the chapter, and if the package has an interface, it is also described here. In large-scale projects, a separate design document is written for the internal structure of each package or subsystem. Each module describes its function, interfaces with other parts, interface and implementation aspects. The technical details must be explained in such detail that the description can be used to test the module as a black box test.
4.1 Module X (each module has its own section 4.i)
4.1.1 Overview
Module name: Module type: (class, function, process, package, subsystem, library) Overview: A brief description of the module - why it exists, what it does. Customers: which / what type of parts of the system need the services of this part (in the case of a general purpose component this item is missing). Dependencies and interfaces to other modules: Briefly describe how a module takes advantage of other modules and services in its environment (can often be combined with an overview).
4.1.2 Interface in general
The services provided by the module and the common features of the interface functions (eg error handling) are described in general terms. In some cases, it is useful to give examples of using the module by describing the communication between the client and the module, for example as an event sequence diagram. Mention is also made here of any Standard and similar definitions that may appear outside the interface, possible capacity restrictions and their modification, status information stored by the module, etc.
4.1.3 Interface Functions
Each interface function is described separately in its own subsection: * Function name * Function parameters and return value * Action: what the function does * Prerequisites: describes what the state of the program must be before calling the function. * Post-conditions: describes the state of the program after the function call (eg side effects). * Error situations: exceptions and other error situations, operation when preconditions do not apply when called
4.1.4 Implementing the module
If necessary, instructions for implementation may be provided, for example: * Thoughts on the implementation of the internal data structures of the module. * Thoughts on the algorithms used. * Known potentially reusable components. * If the module is complex, pseudocode, activity diagrams, etc. can be used. If necessary, a separate module design document can be made.
4.1.5 Error handling
Describes error and exception handling at the module level.
5. FINISHED COMPONENTS AND SPECIAL TECHNICAL SOLUTIONS
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"?
6. SOLVED SOLUTIONS
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
7. FURTHER DEVELOPMENT IDEAS
Gather useful ideas that come to mind along the way, but which are not planned or implemented in this project; for example due to lack of time, lack of money, lack of resources or skills and competences. For example, ideas for further development should be numbered to make it easier to refer to them later. The date and the name (letters) of the proposer will help in the follow-up, especially if the source is outside the project, if after one year the project unexpectedly receives funding for further development. At the end of the project, this chapter is collected at the end of the project plan. The ideas for further development can also be presented as a separate appendix, which can be appended to other project documents if necessary.
7. IDEAS FOR FURTHER DEVELOPMENT
Gather useful ideas that come to mind along the way, but which are not planned or implemented in this project; for example due to lack of time, lack of money, lack of resources or skills and competences. For example, ideas for further development should be numbered to make it easier to refer to them later. The date and the name (letters) of the proposer will help in the follow-up, especially if the source is outside the project, if after one year the project unexpectedly receives funding for further development. At the end of the project, this chapter is collected at the end of the project plan. The ideas for further development can also be presented as a separate appendix, which can be appended to other project documents if necessary.
8. ITEMS STILL OPEN
The figure is unofficial and should no longer be at the end of the project. This can be used to mark issues that are open during the life cycle of the document, ie that need to be resolved, so that they can be clarified before the document is finally completed.
Original Source http://www.cs.tut.fi/ohj/dokumenttipohjat/pohjat/suunnittelu/hytt_drsuunnittelu.doc
Thank you for original authors!