Documento de Arquitetura

Histórico de Revisão

---

Data	Versão	Descrição	Autor(es)
25/08/2017	1.0	Abertura do Documento	Caio Oliveira de Moraes, Cleber José de Castro Júnior, Iago Neres Oliveira, Igor Guimarães Veludo, Lucas Pereira de Andrade Macêdo, Lucas Siqueira Rodrigues, Matheus Rodrigues do Nascimento.
03/09/2017	1.1	Adição da Introdução, Objetivo, Escopo, Visão geral e parte da Representação arquitetural	Lucas Pereira de Andrade Macêdo
05/09/2017	1.2	Adição da visão de casos de uso	Lucas Siqueira Rodrigues
05/09/2017	1.3	Adição das metas e restrições de arquitetura e correções de coesão textual no tópico 1.3	Lucas Pereira de Andrade Macêdo
05/09/2017	1.4	Adição do primeiro tópico das visões arquiteturais do sistema	Lucas Pereira de Andrade Macêdo
06/09/2017	1.5	Adição de diagrama descritivo no tópico 2 e correções no tópico 3.3	Cleber José de Castro Júnior
07/09/2017	1.6	Correções e alterações textuais nos tópicos 1.2, 2 e 4	Lucas Pereira de Andrade Macêdo
07/09/2017	1.7	Modificações no tópico 3.1	Cleber José de Castro Júnior
08/09/2017	1.8	Adição sumário e referência bibliográficas	Caio Oliveira de Moraes
08/09/2017	1.9	Adição da Visão de implementação	Lucas Pereira de Andrade Macêdo
08/09/2017	2.0	Revisão textual do documento corrigindo erros relacionados ao português	Lucas Pereira de Andrade Macêdo
08/09/2017	2.1	Revisão no tópico 3.3	Cleber José de Castro Júnior
10/09/2017	2.2	Revisão no tópico 3.3	Caio Oliveira de Moraes
11/09/2017	2.3	Adição diagrama de camadas	Caio Oliveira de Moraes
11/09/2017	2.4	Adição do diagrama de casos de uso	Lucas Siqueira Rodrigues
12/09/2017	2.5	Correção no diagrama de casos de uso	Lucas Siqueira Rodrigues
23/09/2017	2.6	Correção no diagrama de camadas	Caio Oliveira de Moraes
24/09/2017	2.7	Atualizações gerais no documento com base nas decisões arquiteturais tomadas após um maior entendimento dos requisitos e da plataforma Mapas Culturais	Lucas Pereira de Andrade Macêdo
25/09/2017	2.8	Correção no diagrama de camadas	Caio Oliveira de Moraes
26/09/2017	2.9	Atualização no diagrama de casos de uso	Lucas Siqueira Rodrigues
26/09/2017	3.0	Atualização da descrição de casos de uso	Matheus Rodrigues do Nascimento
26/09/2017	3.1	Melhoria do texto do tópico Visão lógica	Lucas Pereira de Andrade Macêdo
27/09/2017	3.2	Atualizações do tópico visões arquiteturais	Cleber José de Castro Júnior
11/12/2017	3.3	Adicionando o metabase na arquitetura	Cleber José de Castro Júnior
11/12/2017	3.4	Atualização no tópico 5.1	Lucas Siqueira Rodrigues

Sumário

1. Introdução
2. Representação Arquitetural
3. Visão de casos de uso
4. Metas e restrições da arquitetura
5. Visões Arquiteturais
6. Referências bibliográficas

1. Introdução

---

1.1. Objetivo

O documento visa apresentar as principais características arquiteturais da aplicação QueroCultura, com intuito de esclarecer como será modelada a arquitetura do sistema. Cada tópico formalizará e explicará decisões tomadas com base nos requisitos do sistema.

1.2. Escopo

Este documento destina-se a aplicação QueroCultura, sistema desenvolvido por alunos das disciplinas de Métodos de Desenvolvimento de Software[MDS] e Gestão de Projetos e Portfólios[GPP] da Universidade de Brasília - Campus Gama[FGA-UNB].

1.3. Visão geral

O documento é disposto de acordo com três visões de arquitetura, sendo elas: a visão dos casos de uso, a visão lógica e a visão da implementação.

2. Representação arquitetural

---

O padrão arquitetural da aplicação será o MVT(Model - View - Template) tendo em vista que ela será implementada através do framework Django que é escrito e faz uso da linguagem de programação Python, contando também com um "API connection" responsável pela comunicação com a API Mapas Culturais que fornecerá dados para alimentação da aplicação QueroCultura . O banco de dados usado será o MongoDB que é NoSql e orientado a documentos, que será utilizado para salvar os dados necessários para os indicadores, dados esses que serão utilizados pelo Metabase, após serem processados pelo mesmo serão gerados os gráficos da aplicação.

Descrição das camadas de dados do MVT:

• Model - Está camada é responsável por gerir, modelar e persistir os dados tendo como principais funções controlar o estado dos dados, responder a instruções para mudança de estado dos dados, cuidar das regras de negócio da aplicação e controlar as transações com o banco de dados da aplicação.
• View - É a camada encarregada de interpretar entradas vindas de outros sistemas ou da interface do próprio sistema(Template), distribuindo comandos que geram atualização, busca de dados ou requisições em outras partes do próprio sistema ou de outro sistema que esteja sendo consumido fazendo uso das classes definidas na camada de modelo(Model), tais comandos podem ser utilizados pela camada de visualização(Template) para realizar interação do usuário com sistema atendendo suas demandas de busca, visualização de dados, e afins.
• Template - Camada incumbida de ser a interface do sistema sendo responsável por toda a comunicação entre usuário e aplicação, contém por trás de suas telas um uso intenso das camadas View e Model(De forma indireta) que podemos considerar como o "coração" e o "corpo" do sistema respectivamente. É composta de HTML, CSS e javascript, havendo possibilidade do uso de outras tecnologias menos conhecidas. Na maioria dos casos todas as tecnologias usadas nesta camada do sistema são voltadas a iteração com o usuário procurando gerar uma interface agradável, bonita e fácil de usar, um fluxo de dados leve visando um tempo de resposta curto, entre outros requisitos que uma camada de apresentação deve ter para ser considerada excelente.

Descrição da camada "API connection":

• "API connection" - Cuidará da comunicação com a API Mapas Culturais, gerando encapsulamento das transações e disponibilizando as outras partes do sistema os dados provenientes da API Mapas Culturais que necessitam para realizar suas funções dentro do contexto de processamento de dados, geração de indicadores e afins. Tem iteração direta com a camada View e indireta com as demais através da camada View.

Descrição da camada "Metabase":

• Metabase - Camada responsável por processar as informações salvas no mongoDB, e gerar os gráficos utilizados no projeto. O metabase utiliza do banco postgres para salvar as informações respectivas à ele.

Figura 1 - Diagrama de Camadas.

3. Visão de casos de uso:

---

3.1. Atores:

Figura 2 - Diagrama de Atores.

Ator	Descrição
Cidadão	O cidadão pode visualizar o mapa em tempo real, visualizar indicadores de projetos, espaços, eventos, museus, bibliotecas e agentes.
Sistema	O sistema será responsável por atualizar os dados obtidos na API Mapas Culturais e refiná-los.

3.2. Diagrama de casos de uso:

Figura 3 - Diagrama de Casos de Uso.

3.3. Descrição dos casos de uso:

• UC01 Visualizar o mapa de atualizações culturais em tempo real: Essa funcionalidade permite o usuário visualizar o mapa do Brasil em tempo real de acordo com edições que acontecerem em eventos, agentes, espaços e projetos da plataforma mapas culturais

• UC02 Requisitar dados brutos para o sistema: Essa funcionalidade tem o objetivo obter os dados brutos que são coletados das várias instâncias segregadas dos Mapas Culturais e mantê-los atualizados.

• UC03 Atualizar dados refinados do sistema: Essa funcionalidade tem o objetivo manter os dados que forem refinados, para serem utilizados nos outros casos de uso.

• UC04 Visualizar indicadores de projetos: Essa funcionalidade permite ao usuário visualizar informações relacionadas aos projetos.

• UC05 Visualizar indicadores de espaços: Essa funcionalidade permite ao usuário visualizar informações relacionadas aos espaços.

• UC06 Visualizar indicadores de eventos: Essa funcionalidade permite ao usuário visualizar informações relacionadas aos eventos.

• UC07 Visualizar indicadores de museus: Essa funcionalidade permite ao usuário visualizar informações relacionadas aos museus.

• UC08 Visualizar indicadores de bibliotecas: Essa funcionalidade permite ao usuário visualizar informações relacionadas as bibliotecas.

• UC09 Visualizar indicadores de agentes: Essa funcionalidade permite ao usuário visualizar informações relacionadas aos agentes.

• UC10 Visualizar indicadores mistos: Essa funcionalidade permite que o usuário visualize um indicador de uma combinação de categorias.

4. Metas e restrições de arquitetura

---

O sistema será funcional em navegadores de internet que tenham suporte as tecnologias HTML5, CSS3, JavaScript 1.8.x entre outras. O Ambiente de desenvolvimento será o terminal de uma distribuição Linux com o auxílio de editores de texto, neste ambiente faremos uso da linguagem de programação Python junto ao framework Django além de tecnologias e ferramentas que nos permitam gerar uma interface agradável ao usuário, como por exemplo CSS e JavaScript. A aplicação só será funcional com conexão ativa a internet não sendo possível acessá-la offline, as funcionalidades serão implementadas por meio da comunicação com uma API que irá interagir com o sistema por meio de requisições para atualização e requisição de dados a base.

O padrão MVT vai nos proporcionar uma organização, manutenibilidade e reutilização de código que é essencial levando em consideração que a equipe é grande e tem conhecimentos variados, nos conduzindo a conclusão de que seguir um padrão é imprescindível para o sucesso do projeto. Por todos esses motivos acreditamos que o MVT é adequando a nossas demandas de aprendizagem e desenvolvimento, como os conceitos de boas práticas de programação, o conhecimento mais a fundo da linguagem de programação, entre outras necessidades.

5. Visões arquiteturais

---

5.1. Visão lógica

Pode-se repartir a visão lógica em quatro fardos sendo eles: Model, View, Template e "API connection" que controla as transações com a API MapasCulturais.

• Model - Será a representação das entidades que fazem parte do sistema ou seja classes de indicadores, gerenciando toda parte da comunicação com o banco de dados da aplicação desde a persistência até busca de dados.

• "API connection" - Contará com as classes que farão a comunicação da aplicação com as APIs dos Mapas Culturais encapsulando as operações e oferecendo ao resto da aplicação acesso aos dados que requisitarem.

• Template - Responsável pela iteração com o usuário, conterá as telas de apresentação dos indicadores, tela de apresentação do mapa de atualizações em tempo real e as demais páginas do sistema.

• View - Vai ser incumbida de gerenciar e fazer a comunicação entre as camadas do sistema, alimentar o banco de dados da aplicação através da camada Model, receber dados brutos da "API connection" refinando-os para melhor utilização, e apresentar informações através da camada Template.

Destacando que como estamos utilizando o framework Django temos disponível os "Django Applications", os apps do django não são exatamente aplicações web no sentido que estamos acostumados, no django uma aplicação web está mais proxima de um "Django Project", no entanto é possível ter um projeto com apenas um aplicação django, mas não é algo muito usual. No nosso "Django Project" QueroCultura vamos criar "Django Applications" para os casos de uso UC05 até o UC11 além do UC01, cada app vai possuir uma estrutura como a descrita a cima.

5.2. Visão de implementação

Para realizar a implementação do projeto desenvolveremos aplicativos Django para os casos de uso do sistema que envolvem indicadores, teremos uma estrutura MVT juntamente com uma "API connection" dentro de cada aplicativo.

Descrição da distribuição das camadas do MVT e da nossa "API Connection" nos aplicativos Django:

• Arquivo models.py - Implementando a camada Model temos o arquivo models.py, que é o lugar onde gerenciamos e executamos transações com o banco de dados além de definimos as entidades, regras de negócio e validações do app.

• Arquivo api_connection.py - Implementando nossa camada "API connection" teremos o arquivo api_connection.py, que é onde cuidamos de toda a comunicação entre o app e a API que alimenta o sistema, a comunicação é feita através de requisições, o resultado das solicitações é capturado por componentes da "API connection" e repassado a camada solicitante.

• Pasta templates - Guardará nossos arquivos .html, os arquivos podem ser divididos em partes que desempenham funções especificas e juntados com a ferramenta template extending disponibilizada pelo Django, os demais arquivos usados como os .css ficam em uma pasta separada chamada static que é destinada somente a arquivos estáticos. Toda nossa interface de usuário é implementada nessa pasta.

• Arquivo views.py - Implementado a camada View temos o arquivo views.py, que é onde implementaremos a interação entre as camadas Template, "API connection" e Model, além do cálculo de indicadores e alimentação do banco de dados através da camada Model.

Pode ocorrer reutilização de código entre os apps do sistema, no entanto existem poucas semelhanças entre o código de requisição e geração da maioria dos indicadores, além do que, nossa intenção é manter o acoplamento entre os apps o mais baixo possível e alta coesão, para que a implementação de um não seja pré-requisito ao funcionamento de outro nos permitindo futuras ampliações do sistema sem grandes alterações nas funcionalidades já implementadas, tendo em vista que a plataforma Mapas Culturais trabalha com instâncias municipais que crescem em número a cada dia, sendo dificíl prever as abstrações futuras para novos indicadores.

O mapa de atualizações será uma excessão ao padrão dos outros apps pois ele tem como requisito representar com pontos temporários novos registros ou atualizações que ocorram na plataforma Mapas Culturais do Ministério da Cultura. Tendo em vista tal requisito, exclusivamente para o mapa teremos uma controller Javascript e Ajax, que fará requisições de verificação nos registros da plataforma Mapas Culturais em pequenos intervalos de tempo passando dados diretamente para camada Template. Assim, o mapa representará um fluxo de tempo real simulado com algum pequeno delay das reais alterações da plataforma MinC.

5.3. Diagrama de Classes

6. Referências bibliográficas

---

Documentação oficial do Django disponível em : https://docs.djangoproject.com/pt-br/1.11/ Acesso em : Dia 03 de setembro de 2017

Página "Padrões Arquiteturais MVC x Arquitetura Django da wiki de fga-gpp-mds disponível em: https://github.com/fga-gpp-mds/00-Disciplina/wiki/Padr%C3%B5es-Arquiteturais Acesso em: Dia 05 de setembro de 2017