1. Introduction and Goals
1.1. Requirements Overview
We use solid for this application and design a decentralized chat that allows people to communicate people and not share this personal data.
We develop this system to allow users to keep his personal data save in this computer so the data doesnt need to go to a server.
1.2. Quality Goals
| Goal | Scenarios |
|---|---|
Privacy |
The app should give to the user the capability that the user controls all its information |
Availability |
The app should always be available, should always work, and should not depend if there is internet conection or not |
Usability |
The app should be easy to use for the user, easy to interact with, and intuitive, so the users doesn’t need to think so much about what to do and how to do that |
1.3. Stakeholders
-
Jose Emilio Labra Gayo: He should know the architecture and be convinced of it, and he also needs to know the doumentation about the project.
-
Teamwork: Needs to know everything about the project and have the power to take decissions of how the project is gonna be manage.
-
Client: The client just needs to know how the application works.
| Stakeholder | Description | Expectations |
|---|---|---|
Jose Emilio Labra Gayo |
Supervisor |
This client expects improving our knowledge in solid and develop a funcional decentralized chat application |
Teamwork |
Group developing the application |
Develop a functional application that allow us to pass the course |
Client |
People that is going to use the application |
Have the possibility to chat with another people keeping his data save |
2. Architecture Constraints
2.1. Technical Contraints
| Constraint | Explanation |
|---|---|
The application must be decentralized |
Our goal is to have a decentralized chat, that consists in having separated personal data from apps. |
Browser-independent |
The application must be browser independent, need to test the application in the most popular ones, at least. |
Github |
The project is open source, hosted in a Github repository, which helps a lot. |
Language |
The application must, at least, be developed in English, as we are a students of the english group. |
Testing |
We need to develop tests as much as we can. |
3. System Scope and Context
3.1. What are the goals of the system?
The goal is to create a decentralized chat app based on the solid specifications. The system will be based on a decentralized architecture where data storage is separated from the app. Users can store their chat data in their own pods. The app will allow a user to share pictures, videos or other kinds of files with other friends through the chat. A user can also get notifications when some friend wants to chat with him. Users can have groups of friends with whom they may want to chat and it will be possible to have group chats where all members receive the messages.
3.2. Business Context
We will have two users (at least) sending and receiving messages, while in the background, RDF will be sharing chat details. The data that the users will exchange will be kept in PODs.
-
Sender: User of the application that sends a message to other user.
-
Receiver: User in the application that receives a message from other user.
-
Pod: Each user has a POD where the messages are stored.
-
DeChat App: Decentralized chat application through which people is chatting.
3.3. Technical Context
As the architecture of DeChat is SOLID, we’ll be using WebID to communicate between users and friends. In addition, SOLID uses WebSockets, RDF…
Furthermore, we are using a lot of other technologies for building the application as Angular, Javascript… The main purpose of building this is allowing the users of SOLID to communiate between them, and for doing that we used the mentioned WebID’s, and also some other libraries as RDF.
4. Solution Strategy
| Decision made | Solution approach | Reason why | Extrenal references |
|---|---|---|---|
Working with SOLID |
As we saw in class we should follow the SOLID specifications in order to develop the proyect correctly. |
We need to follow the SOLID specifications in order to make our chat as decentralized as possible where data storage is separated from the app, to start working with SOLID we can check the second link. |
|
Programming language |
Given the assignment description and its requirements, we decided to use javascript as the programming language. |
We chose javascript because, for us, it makes it easier when dealing with certain things (following SOLID specifications) like callbacks that we may face during the development of the decentralized (one of the main goals) chat. |
|
Organizational decisions |
We, as a team, have decided to try to work in an incremental way as a team, trying not to leave everything for the last days and with active comunication. At first, nobody is going to take care of anything specific, but as the development process advances this may change. |
We come from IPS, a subject where we learned how to work in a team efficiently, we are trying to apply the same principles here. |
|
ANGULAR+SOLID |
We decided to use ANGULAR and a SOLID generator to initially develop the application. |
We researched some information and realized that ANGULAR makes it easy to build applications with the web, specially with the given constraints. Also, another main reason why we chose ANGULAR is the SOLID generator (see links at the right), that makes it easier to follow the SOLID specifications. |
|
Testing with cucumber |
TDD and acceptance tests will be implemented using cucumber |
As we saw in class, this testing tool is based on user stories, something we already where familiar with and can make things easier |
Cucumber, for testing. How to setup cucumber in angular project (from scratch). Integrating cucumber in angular project (our case). |
5. Building Block View
The Building Block view shows the decomposition of the system statically.
We have several views, but the main important ones are the one for login in and the one for chatting. It is important to highlight that if we want to access to the chatting view, first we must go through the login in one. For reaching this, we decompose the system in small pieces (as we are using angular) to create a big application.
In the first level of our application we can find the components, the model and the different services of the system, this is because we are using a MVC model, so this allow us to distribute the responsabilities of the system in different parts.
In the second level we find the main components of our application, the chat component, the login component, the card componenet (or profile component) and finale the settings component. There are many more small components that works with those components.
5.1. Whitebox Overall System
-
Components: This block is the presentation of the web and what the user is go to see when he navigate through the application. Here we can find html, css and ts files.
-
Services: This block manages the communication between the view of the of the application and the model.
-
Model: This block manages all the parts of the system.
6. Runtime View
In this document we will show you the main runtime views of the application in different scenarios.
6.1. Log in
-
First, the user must enter it’s personal ID and password
-
After that, the application will ask the server to approve the login request made by the user
-
Finally, if the server approves the login the user will access to the chat, but if the server denies the login the user won’t access to it
6.2. Register
-
First, the user must choose between getting registered via Inrupt or Solid Community
-
After that, they will fulfill the registration form with their personal data
-
Finally, they can login in with their account
6.3. Chat with friends
The chat is used for chatting between users, better said, between friends.
Selection of the partner to whom you will send a message
Sequence of a chat
-
First User_1 sends a message to User_2
-
The application of the User_1 posts its message on the pod of the User_2
-
The application of the User_2 requests the received messages that contains its pod, so the pod makes the messages available for the application
-
Finally User_2 reads the received messages from the application
7. Deployment View
The deployment view is very easy to describe in a decentralized chat because we are just focusing in the interaction between the users and SOLID providers
8. Cross-cutting Concepts
In this section we are oging to describe the main ideas and concepts that are applied in the system.
Domain Concepts
-
Client: the decentrlized chat running on the user’s browser. It gives to as just the functionality.
-
Message: is a piece of text that is used to communicate between users, expressed in turtle syntax for RDF.
-
Pod: it could be called as user repository, following the SOLID specification, and it stores the messages exchanged.
User Experience
The user should use the application in an easy way as with other chat application, with no problems or any difference. There are two main reasons for this: * Facilitate the migration from other chat systems easy for any kind of user. * Prove that it is posible to have the very same services that we currently enjoy using the SOLID system
Architecture and design patterns
Nowadays, the decentrlized chat is an Angular-based system, therefore following the Model View Controller architectural pattern. However, all our application would not store any of the user’s data. It will access it via SOLID pods.
Persistency
We have achieved the persistence using the RTC and turtle (.ttl) files. Thus, making use of the standard already in place in SOLID, and allowing the interaction of the decentralized chat and the SOLID chat system.
Session handling
The session is managed using the SOLID session itself, as it is the platform that is in charge of storing the user’s data.
Communication
Two chats would not communicate directly. For that, we will need SOLID pods, which are the ones storing the messages. The application provides a realtime notification daemon to allow users to talk fluently.
9. Design Decisions
| Sections | Decisions |
|---|---|
Programming language |
We are going to use TypeScript, html and css to develop our app and JavaScript for the tests. |
Implementation |
We are going to use the design patter Model View Controller (MVC). |
Cucumber |
We decided to use Cucumber to develop the acceptance tests. |
Platform |
We are going to develop the app using angular. |
10. Quality Requirements
10.2. Quality Scenarios
| Reference | Quality attribute | Scenario | Priority |
|---|---|---|---|
1 |
Performance / efficiency |
The user will send and receive messages as fast as possible |
High, high |
2 |
Scalability |
If the number of users increased, the system must be available and the perfomance mustn’t be affected |
High, low |
3 |
Interoperability |
The system must exchange, without any lost data, all the messages between the users |
Medium, low |
4 |
Managability |
The administrators of the application will manage the application as easy as possible |
Medium, low |
5 |
Security |
If a user is not included in a specific chat, the system won’t allow him to know anything about the messages of that chat |
High, medium |
6 |
Availability |
The system must be available/accessible at any time |
High, medium |
7 |
Usability |
The system must be intuitive and easy to use for the user |
High, medium |
9 |
Maintainability |
The system will support changes, without affecting the usability of the system |
Medium ,low |
10 |
Testabiliy |
The system developers will use their own "special" accounts and POD’s where to test any system functionality |
Medium, low |
11. Risks and Technical Debts
This is something completely new for all of us, so we may need to spend quite some time in order to start managing everything correctly.
We are not experts on angular since we are not used to use typescript in this kind or level , and apply this language to the SOLID requirments its gonna be difficult.
When two people are online they should be able to establish real time communication, during the development process we may have to deal with some problems we have never faced before using javascript
We may face some problems with the messaging system of the application, problems like… what happens when we send a message to someone who is not online? where do we keep that message so it does not get in conflict with the main goal (decentralization) and gets delivered once the other client connects?
We never did any acceptance test so we have to get used to work with Cucumber.
12. Glossary
| Term | Definition |
|---|---|
SOLID |
SOlid LInked Data is a proposed set of conventions and tools for building decentralized social applications based on Linked Data principles. Solid is modular and extensible and it relies as much as possible on existing W3C standards and protocols. |
POD |
Personal Online Data. Your POD is your personal storage space, PODs are like secure USB sticks for the Web, that you can access from anywhere. When you give others access to parts of your POD, they can react to your photos and share their memories with you. You decide which things apps and people can see. |
User |
Is an entity that has authority to use an application or uses PODs. |
Stakeholder |
Is a person who affects, is affected or can contribute to the system and its architecture. |
User Profile |
It have all the information about the user: name, surname, phone number, etc… |
Asciidoctor |
Is a fast text processor and publishing toolchain for converting AsciiDoc content to HTML5, DocBook 5 or 4.5, EPUB3, PDF and other formats. Asciidoctor is the leading implementation of the AsciiDoc syntax, first introduced and implemented in the Python-based AsciiDoc project. |
Functional Requirements |
They state what the system must do operating within normal parameters, so as to assure the design is adequate to make the desired product and the end product reaches its potential of the design in order to meet user expectations. Functionality does not determine architecture. |
Quality Attribute Requiremennts |
Also called non-functional requirements, they annotate or qualify functional requirements. They influence the architecture: Availability, modifiability, usability… . |
Quality Attribute Scenarios |
They Describe a certain event (triggered by a person or a system) of the system and a measurable response to that event. They must be testeable and should be prioritized. |
Angular |
Angular is a platform that makes it easy to build applications with the web. Angular combines declarative templates, dependency injection, end to end tooling, and integrated best practices to solve development challenges. Angular empowers developers to build applications that live on the web, mobile, or the desktop. |
Test coverage |
It is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. A program with high test coverage, measured as a percentage, has had more of its source code executed during testing, which suggests it has a lower chance of containing undetected software bugs compared to a program with low test coverage. |
Cucumber |
It is a tool that supports Behavior Driven Development. Cucumber give us the opportunity to write tests that anybody can understand. It is based on user stories. |
User stories |
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template: As a < type of user >, I want < some goal > so that < some reason >. |
Gherkin |
Gherkin is a human-readable language for system behaviour description, which uses indentation to define the structure of the document (spaces or tabs). Each line starts with one of the keywords and describes one of the steps. We use it to describe our user stories. |
Travis |
It is a distributed continuous integration service used to test software projects hosted at GitHub. |
About arc42
arc42, the Template for documentation of software and system architecture.
By Dr. Gernot Starke, Dr. Peter Hruschka and contributors.
Template Revision: 7.0 EN (based on asciidoc), January 2017
© We acknowledge that this document uses material from the arc 42 architecture template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke.