Phase 1

Phase 1

Goals

The Software Laboratory project is comprised by the analysis, design and implementation of an information system for task management, inspired by the Trello application. Its development is divided into 4 phases, with incremental requirements published before the beginning of each phase.

Domain

• A user is characterized by, a unique number,a name and an unique email.

• A board represents a project or similar activity, and is composed by a set of tasks. Each board has an unique name and a description and is associated to one or several users. The name comes from the analogy with a physical board, containing pinned cards describing tasks.

• Each board is divided into a sequence of lists, which correspond to columns on a physical board. Each list represents a phase in the execution of a task (e.g. "to do", "doing" and "done"). The relative position of a list in a board can change, however a list always belongs to the same board. A list has a name, which must be unique in the board.

• Each list contains a sequence of cards. A card represents a task and is always associated to the same board. A card must always be inside a list, except if it is archived. A card can be moved between lists of the same board. Each card is characterized at least by: a name, a description, the creation date and the task's conclusion date.

Phase 1 requirements

Development of the backend service, the backend service must expose an HTTP API for frontend client applications, the API should provide the following functionalities:

User Management

• Create a new user, given the following parameters

  • name - the user's name
  • email - the user's unique email.

  Returns the user's token and the user’s identifier.

• Get the details of a user.

Board Management

• Creates a new board, given the following parameters

  • name - unique name for the board.
  • description - board description.

  Returns the board unique identifier.

• Add a user to the board.

• Get the list with all user available boards.

• Get the detailed information of a board.

• Creates a new list on a board, given the following parameters

  • name - list name.

  Returns the list unique identifier.

• Get the lists of a board.

• Get detailed information of a list.

• Creates a new card in a list, given the following parameters

  • name - the task name.
  • description - the task description.
  • dueDate (opcional) - the task's conclusion date.

  Returns the card unique identifier.

• Get the set of cards in a list

• Get the detailed information of a card

• Moves a card, given the following parameter

  • lid - the destination list identifier.

NOTE: For all operations that require authentication, a user token must be sent in the Authorization header using a Bearer Token. This token is generated at user creation, and consists of a UUID string (you can use UUID class from java.util package for ID generation). Students should decide which functionalities require authentication and authorization.

Non-functional requirements

The backend must be developed with Kotlin technology. To handle/receive HTTP requests, the HTTP4K library must be used. The body serialization/deserialization should be done using the kotlinx.serialization library- You can see a functional usage example of both libraries here. The data that are specific to the application, which can be created, altered and deleted must be stored in a Postgres database. Tests run using data stored in memory, not the database.

The following non-functional requirements will be highly valued.

• Readability.
• Testability, including on machines not belonging to the development team.

Guidelines about design and implementation

At the beginning of the development, the server application should store the data in memory and the solution should start with 4 files:

• tasksServer.kt - file that constitutes the entry point to the server application
• tasksWebApi.kt - implementation of the HTTP routes that make up the REST API of the web application
• tasksServices.kt - implementation of the logic of each of the application's functionalities
• tasksDataMem.kt - access to data, stored in memory.

The dependencies between these are as follows:

tasksServer.kt -> tasksWebApi.kt -> tasksServices.kt -> tasksDataMem.kt                                                               

During the development of this phase other files can (and should) be created, in order to structure the code in a more logical and readable form. Solutions with large code files are highly discouraged.

Report and HTTP API Documentation

• The phase 1 delivery must include a technical report, in the docs repository folder, using the following template.

• It also has to include the HTTP API documentation required for a frontend client application to use this API. This documentation should not include any information about the internal backend implementation. Students are encoraged to follow OpenAPI specification.

Delivery date

The project must be delivered until April 2 (end of week 5), via the creation of a 0.1.0 tag on the GitHub repository.