Software Architecture Document
- 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. Design Patterns
- 11. Quality/Metrics
This document provides an overview of our software architecture. With several architectural views, it depicts different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made for the system.
This document describes the technical architecture of the Decksterous project, including the classes and use cases.
| Abbrevation | Description |
|---|---|
| API | Application programming interface |
| SRS | Software requirements specification |
| UC | Use case |
| VCS | Version control system |
| SPA | Single Page Application |
| BDD | Behaviour Driven Development |
| n/a | not applicable |
| tbd | to be determined |
| Title | Link |
|---|---|
| Blog | Decksterous Blog |
| SRS | Software Requirements Specification |
| UC Create new Decks | Create new Decks |
| UC Trade Items | Trade Items |
| UC Invite Friend | Invite Friend |
| UC Show Rankings | Show Rankings |
| UC Buy Shop Items | Buy Shop Items |
This document contains the goals and constraints as well as the logical, deployment, implementation and data views of our application.
The general architectural structure for Decksterous can be split into a frontend and backend. The frontend implements the user interface and the interaction with the backend functionalities. The backend instance will provide all client data needed. Additionally, the backend contains the complex game logic for handling player interaction to restrain "cheating". The following UML diagram gives a simple architectural overview over everything:
The frontend internally follows the MVVM pattern, which can be depicted as following. This pattern connects the View and the Model via two-way data bindings. Actual DOM manipulations and output formatting are abstracted away into Directives and Filters This pattern separates the View components again into a functional part (the ViewModel) and a purely representational part (View) while the model remains analogous to the back end.
The backend itself doesn't use a framework like that, we created an appropriate structure which is realized via TypeScript Classes and ES Models via these models we let them work with each other.
Angular and Nodejs communicate with each other with the help of the HTTP Client. Together they represent the controller of our architecture. The resulting templates of Angular create our view and MariaDB as our database maintains our models.
As mentioned in chapter two, frontend and backend are using the MVVM pattern. This is the way how a SPA is normally set up.
The desktop application is written in TypeScript (superset of JavaScript). Angular is structured for SPAs and therfore retrieves data from the backend.
- Model: Classes modelled after/by backend classes
- View: Activities
- ViewModel: Specific functionalities and network operations
The backend is also written with TypeScript. This contains all the core functionalities for our game logic and manages our models. It delivers data to the frontend applications to be displayed.
n/a
Our controller is built out of Angular and Node.js. The HttpClient makes communication between the frontend (Angular) and the backend (Node.js) possible.
To identify the user we generate a "JSON Web Token (JWT)" on login and add this to every request HEAD with x-access-token.
Login request body payload:
{
"name": "MyName"
"password": "MyPassword"
}Login sequence:
sequenceDiagram
participant Client
participant API
participant Database
Client->>+API: Login Request
API->>+Database: Get User
Database-->>-API: User Result
API->>API: Check Password
API-->>-Client: Send JWT
Client->>Client: Store Token
Any backend process with authentication needed:
sequenceDiagram
participant Client
participant API
Client->>+API: Any Request
API->>API: Verify Token
API->>API: Retrieve User Information
API->>API: Process Request
API-->>-Client: Any Response
Currently, we do not have a proper diagram which showcases both system class diagrams together because we could find a way to generate a class diagram out of the Angular components. You can view the seperated implementation in 8.3 Class Diagrams.
We use BDD and therefore "Gherkin" files for defining and running our tests. You can read up on some test scenarios in our Use Cases.
- Cucumber "Behaviour Driven Development (BDD)" tool
- Protractor "end-to-end (e2e)" test framework
- protractor-cucumber-framework for angular - Guide
- Chai assertion tests
"A common mistake that people make when trying to design
something completely foolproof is to underestimate the ingenuity
of complete fools."
~ Douglas Adams, 'Mostly Harmless'
Currently, there are no deployments. We are still developing the technologies and logic needed to fully interact with all functionalities. Until the first working prototype there are no deployments planned.
n/a
n/a
Since Angular is fully oriented about its import/export framework, the entry point of everything is app.module. Therefore everything needs to export to or import from AppModule. The diagrams are done by hand since tools to generate these diagrams do not really exist for an Angular environment and/or break.
Components and Features that are not yet implemented are displayed as simple objects with no attributes or methods.
Since we are working with Express.js our structure centralizes on the Routes, where Controllers, Middleware and Database Models come together.
n/a
n/a
n/a