diogolcarvalho / spring-boot-api-rest Goto Github PK

Grupo CPDev

• Ademir Alves
• Aryel Anne
• Bianca Jesus
• Diogo Carvalho
• Fernanda Sena
• Leonardo Cajé

O PDS segue uma abordagem mista entre modelo cascata e modelo interativo-incremental adaptada do Scrum. Cada interação durava uma semana e tinha encontros semanais. A definição de pronto de cada interação era estabelecida com objetivo de controlar a qualidade do desenvolvimento.
Como padrão de projeto, foi utilizado o MVC (Model-View-Controller).
A aplicação foi construída com base nos princípios SOLID.

No contexto do projeto interdisciplinar o estudo de caso tem como objetivo desenvolver e implantar o SOCIELOO, um site centralizador de ONGs, instituições e projetos sociais da cidade de São Paulo, com o propósito de divulgá-las a possíveis doadores e voluntários e criar, assim, um ELO entre ONGs e a sociedade. O diferencial do site é a maior flexibilidade do usuário para a escolha de Projetos sociais com a localização e segmento de sua preferência, podendo favoritar, analisar e avaliar cada projeto.
O site foi concebido com a proposta de atender aos Objetivos de Desenvolvimento Sustentável (ODS), da ONU.

Cada requisito tem um identificador único de maneira que seja possível rastrear a necessidade do cliente com a implementação do software. O desenvolvimento se deu através de 5 Sprints. Abaixo, ficam listados os objetivos de cada Sprint:

• SPRINT 1: Criar funcionalidades relacionadas ao cadastro da ONG
• SPRINT 2: Finalizar as funcionalidades relacionadas às ONGs e ajustar recursos de acessibilidade ao site
• SPRINT 3: Finalizar as funcionalidades relacionadas às ONGs e dar início ao desenvolvimento do CRUD(Back-end) do usuário.
• SPRINT 4: Trabalhar com as funcionalidades do Usuário e começar a desenvolver as funcionalidades de Administrador
• SPRINT 5: Desenvolver as funcionalidades do sistema relacionado ao administrador

O Product Backlog será considerado concluido quando:

1. Os testes (ID 35) estiverem dando resultados satisfatórios e sem quaisquer erros ou problemas na execução da aplicação.

FRONT-END

• React

BACK-END

• Java

FRAMEWORKS

• Springboot

BANCO DE DADOS

• H2

APIs

• React Google Chart
• ViaCEP
• OpenStreetMap

PLUGINS

• VLibras
• Google Maps

Construímos uma plataforma que cadastra ONGs. Cada ONG cadastrada recebe sua Página de ONG, em que suas informações são divulgadas para o público do site. Usuários também podem se cadastrar para interagir com as ONGs, incluindo comentários nas Páginas de ONG e favoritando as ONGs de sua preferência. O administrador controla os fluxos do site e tem acesso a um painel com ONGs e usuários cadastrados, os comentários postados e a quantidade de vezes que uma ONG foi favoritada.
Portanto, implementamos um projeto que, atualmente, possui 5 CRUDs (ONG, Usuário, Admin, Comentários e Favoritos) e 34 classes.

O modelo de dominio (Larman, 2006 - classes conceituais ou classes de negócio) foi definido considerando as seguintes classes:

A visão lógica da arquitetura para API de Cliente é apresentada na figura abaixo. A visã lógica descreve como o código está organizado, as classes os pacotes e os relacionamentos entre eles.

A entidade Cliente foi identificada como um serviço (ERL, 2007 - serviço do tipo entidade) o contrado das operações de sistema (LARMAN, 2006, pag.140) foram definidas no diagrama abaixo.

classDiagram 
 class ClienteServicoI 
 <<interface>> ClienteServicoI 
 
 ClienteServicoI : +List<Cliente> consultaTodos() 
 ClienteServicoI : +Optional<<Cliente>> consultaPorCpf(String cpf) 
 ClienteServicoI : +Optional<<Cliente>> consultaPorId(Long id) 
 ClienteServicoI : +Optional<<Cliente>> save(Cliente c) 
 ClienteServicoI : +void delete (Long id) 
 ClienteServicoI : +Optional<<Cliente>> altera (Cliente c) 

O diagrama de sequência descreve como os varios componentes arquiteturais colaboram para manipular uma operação de sistema (exemplo para operação consultaTodos())

sequenceDiagram 
Usuario ->> APIClienteController: GET /api/v1/clientes 
APIClienteController ->> ClienteServiceI: consultaTodos ( ) 
ClienteServiceI ->> ClienteRepository: findAll ( ) 
ClienteRepository -->> ClienteServiceI: List[] 
ClienteServiceI-->> APIClienteController: List[] 
APIClienteController -->> Usuario: JSon[] 

Referencias

• [1] KRUCHTEN, Philippe. Reference: Title: Architectural blueprints—the “4+ 1” view model of software architecture. IEEE software, v. 12, n. 6, 1995.
• [2] RICHARDSON, Chris. Microservices patterns: with examples in Java. Simon and Schuster, 2018.
• [3] ERL, Thomas. SOA principles of service design (the Prentice Hall service-oriented computing series from Thomas Erl). Prentice Hall PTR, 2007.
• [4] LARMAN, Craig. Utilizando UML e padrões. 2aed., Porto Alegre: Bookman Editora, 2006 (pag. 147)