1. Introduction and Goals
1.1. Requirements Overview
The LoMap system is a software solution that allows the citizens of a city to share places of interest with other users. These places are part of a map, and the users can give feedback about them to other users.
The LoMap system must accomplish the following requirements:
-
Users must be able to add locations of different categories, including bars, restaurants, shops, sights and monuments.
-
Users must be able to show the locations in a map window.
-
Users must be able to add review scores, comments and pictures about added places.
-
Users must be able to manage the information that is accessible with other users, which can be part of their friends or a group of friends.
-
The information about the places of each user should not be fully centralized.
-
The privacy of each user should be respected as much as possible without interfering with other aspects of the application such as the performance.
-
Users must be able to see places of their friends.
-
Users must be able to filter the places they see in the map by friends or category.
1.2. Quality Goals
| Quality Goal | Description |
|---|---|
Usability |
Non technical users must be able to use the app easily. Aesthetics must be familiar and understandable to them. |
Privacy |
Users can control the data that is shared with the app thanks to SOLID principles and the use of pods. |
Efficiency |
There must be a medium point between privacy and efficiency (all the information may not be stored inside the pods due to decreases in performance). |
Testability |
The application should be able to go through different test and complete them successfully. |
1.3. Stakeholders
| Role/Name | Contact | Expectations |
|---|---|---|
Deployment city/ Client |
Brussels City Hall |
Have a functional application that adds value to the community, obtaining a benefit for local businesses and tourism. |
Responsible company |
HappySw |
Development of a generic project expandable to other cities. |
Main beneficiaries |
Public users |
Have an easily accessible and useful consultation and discovery service for premises or businesses. |
Side beneficiaries |
Businesses benefited |
Obtain greater visibility and approach to the public, especially to the tourists of the city. |
Project managers |
Subject teachers |
Development by the students of a functional application that meets the established criteria and can serve as a prototype for a real service. |
Developers |
Lomap_es4a team |
Carrying out a serious project with a view to the future in which to develop your potential and show your technical skills. |
2. Architecture Constraints
2.1. General constraints
| Constrains | Description |
|---|---|
Arc42 |
It will be the base template followed for the documentation. |
Git & GitHub |
A version control management system has to be used so that the software can be versioned and all developers have access to the project. GitHub is a tool that has to be used so the professors can evaluate the project. |
2.2. Technology conventions
| Constrains | Description |
|---|---|
SOLID |
The use of pods to store the user’s data is mandatory. |
Web |
The developed software solution must be accesible by the users through a web application so the project has to be deployed in a server. |
2.3. Group conventions
| Constrains | Description |
|---|---|
Capacity |
The group must have between 5 and 8 members (5 members in this case). |
Meetings |
One scheduled meetings per week is mandatory. It will take place during the lab sessions More meetings can be arranged. |
Time Restriction |
This project has to have an approximate duration of one semester. |
3. System Scope and Context
3.1. Business Context:
The main components that the LoMap system interacts with are: Maps API, POD.
The final user has a POD and uses the LoMap system to save and share maps. The LoMap system can also access the user’s POD to store information.
3.2. Technical Context:
The components of the application use certain technologies and communicate with eachother using different channels. The LoMap application will be programmed mostly using TypeScript and the React framework. The Pod will be a SOLID POD. The connections that happen between LoMap and the user’s device follow the https protocol and the connection between the user’s device and the SOLID PODs follow the https protocol, so the information is secure. LoMap will use a Google Maps API, and the connections will use http.
4. Solution Strategy
4.1. Technology decisions
We decided to use this programming language because it’s one of the most suitable to develop web apps. Like JavaScript, it provides all the capabilities that a language used for the web and it helps the developers by being statically typed. Our team has experience with Java, so a statically typed language is easier to use and understand for us.
The docker containers can be used during development as they provide a uniform enviroment to run the application.
We will use either WebStorm or Visual Studio Colde develop our project, each member of the development team can choose to work with either one of them.
Some members of the team will use Github IDEs such as Github Destopk, Github Kraken or native Github
4.2. How are the quality goals going to be reached?
Our interfaces will be intuitive and easy to use for anyone thanks to using the React framework.
The essential information will be stored in SOLID PODs providing a strong privacy.
The performance will be smooth, by using the SOLID PODs correctly and not using a REST API.
The team will test the app manually and automatically with automated jest tests.
5. Building Block View
5.1. Whitebox Overall System
- Motivation
-
The diagram shows the external components that interact with the application: the user and its pod.
- Contained Building Blocks
| Black boxes | Description |
|---|---|
LoMap |
Application which extracts data from the pod, obeying the user. |
User’s pod |
The place where user’s private data is stored. |
Maps' API |
Service that will allow us working with maps. |
5.2. Level 2
- Motivation
-
The diagram shows the inner structure of the "LoMap" component.
- Contained Building Blocks
| Black boxes | Description |
|---|---|
Frontend |
Application user’s interface. |
Solidapi |
It contains all the functionality related with pod’s management. |
6. Runtime View
6.1. Login
6.2. Map view
6.3. New point/Map saved
7. Deployment View
7.1. Development Diagram
While in development, the LoMap system will be run in the developer’s computer. The system will be deployed in the developer’s computer using a Docker image which contains the necesary programs to run the application as a standalone application. As it is shown in the diagram, the SOLID PODs, as well as the Maps API, are not part of the LoMap system. While the application is being developed, there is a Docker image that runs the webapp. This will not be the case when the application is deployed.
7.2. Deployment Diagram
While in deployment the application will run in GitHub pages on another repository. The users will connect to GitHub pages to access the application, for the most part through the user’s device. The webapp is the part of the system that the users will interact with.
7.3. Legend
The following image is a legend that can be useful to understand the information shown in the diagrams.
8. Cross-cutting Concepts
8.1. Domain Concept
User: This represents a client of the application. They can add other users as Friends, and they have a map to mark their favourite places too. We get their information through the POD.
Map: This represents the users' map. It contains the markers made by the user.
Mark: This class represents the Marker that represents the location of a place.
Comment: This represents a comment made in a marked location by a certain user with all his information including the posting time and rate of the user.
Location: This contains the longitude and latitude of the Marker.
8.2. Technical Decisions
The technical decisions taken were explained in more detail in the section 04 of the documentation titled 'Solution Strategy'. For further information about the technical decisions, please check the section 04 Solution Strategy.
9. Design Decisions
| Desing Decision | Advantages | Disadvantages |
|---|---|---|
TypeScript |
Versatile language to program web applications. |
Neither of us has experience with its use. |
React |
Very used javascript library. Easy to learn and use. Reusable components. |
We have never worked with a library like this. |
Not using REST API |
Less latency. Easier to develop. Lighter application. |
Higher coupling in the application. Lack of backend |
10. Quality Requirements
10.1. Quality Tree
10.2. Quality Scenarios
| Quality requirement | Quality scenario | Priority |
|---|---|---|
Usability |
Our app has to be easy to use for every kind of user, even for a non-experienced one. The views must be clear and intuitive, and the user has to be able to browse fluently through the entire application. In addition, the required mechanisms to ease the users use of the app must be implemented. |
High |
Privacy |
Giving the users the control of the information saved and shared, we guarantee that there won’t be personal leaks. This is a result of the use of pods and a very cared system of terms and privacy options. |
Medium-high |
Efficiency |
The conection and browsing speed must be fast enough to keep the users' attention and to not bore them, giving a fluent experience through the app. |
Medium-high |
Testability |
The application should be able to go through different test and complete them successfully. Besides, the app has to be prepared for all kind of logical uses by the user |
Medium-low |
Some of these quality attributes have been checked with the following load tests:
-
4 load peaks of 100 users, each 40 seconds:
-
1 user per second, through 3 minutes:
-
3 series of 1, 5 and 10 users per second during 60 seconds, each other:
-
normal app use (20 users for 30 seconds):
11. Risks and Technical Debts
11.1. Risks
11.1.1. Organizational Risks
-
GitHub is a very powerful tool when used correctly. As the developers tasked with developing the LoMap system do not have a lot of experience using GitHub in a professional work environment, it could become an issue. If not used correctly, Git and GitHub could become a liability and could delay development.
-
If the number of meetings is insufficient the team may have difficulties understanding what their responsibilities are and it could pose coordination problems.
-
If the number of meetings greater that the necesary amount, the team may lose time they could spend developing the system.
11.1.2. Technological Risks
-
If the team does not properly understand the technologies used, the system may not satisfy the quality goals.
11.1.3. Technical Debt
-
There is no REST API, which means there is no backend. This is something that may hinder future development. Not having a REST API also means that the application will not be able to be used through requests to the REST API.
-
There is no database, this means that there is no possibility to store useful information centrally. This might be useful for future growth of the application.
-
The code could be better organized, currently a change may require to update various files. In the future the application may need to be refactored to lower its coupling.
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.