Documento de Arquitetura de Software

Versionamento

Data	Versão	Descrição	Autor(es)
14/11/2020	0.1	Criação do documento e adição do tópico de Introdução	Murilo Loiola
17/11/2020	0.2	Adição do tópico de Visão Geral na Introdução e Adição do tópico de Escopo	Murilo Loiola
18/11/2020	0.3	Adição do tópico de Tecnologias	André Goretti
18/11/2020	0.4	Adição do tópico de Metas e Restrições Arquiteturais	Murilo Loiola
18/11/2020	0.5	Adição do tópico de Visão Lógica, Visão de Dados, Visão de Casos de Uso	Murilo Loiola, Gabriel Tiveron, André Goretti
19/11/2020	0.6	Correção no tópico de tecnologias	Gabriel Tiveron
19/11/2020	0.7	Adição do diagrama de arquitetura geral	Gustavo Carvalho
19/11/2020	0.8	Adição do diagrama de pacotes geral	Gustavo Carvalho, Murilo Loiola
19/11/2020	0.9	Adição do tópico de Visão de Processos	Murilo Loiola
19/11/2020	0.10	Adição da descrição do diagrama de pacotes e descrição dos processos	Gustavo Carvalho, Murilo Loiola
20/11/2020	0.11	Adição de acrônimos e abreviações	Rodrigo Dadamos
20/11/2020	0.12	Adição de diagrama de classes focado nas mais relevantes	Rodrigo Dadamos
20/11/2020	0.13	Adição de diagrama de comunicação e da Visão de Implementação	Rodrigo Dadamos
20/11/2020	0.14	Revisão da visão da dados	Gustavo Carvalho, Rodrigo Dadamos
20/11/2020	0.15	Adicionando referências	Murilo Loiola
20/11/2020	0.16	Adição do estilo arquitetural	Rodrigo Dadamos
20/11/2020	0.17	Adição da visão de implantação	Rodrigo Dadamos

Introdução

Finalidade

Este documento fornece uma visão arquitetural abrangente do sistema, utilizando-se de um número de diferentes visões arquiteturais para descrever diferentes aspectos do sistema. Seu propósito é capturar e transmitir as decisões arquiteturais mais importantes que foram tomadas em relação ao sistema.

Escopo

Este Documento de Arquitetura de Software fornece uma visão arquitetural abrangente do sistema Diário da Saúde. O sistema em questão está sendo desenvolvido por alunos da UnB-FGA com o intuito de facilitar a comunicação entre paciente e profissional da saúde em grupos de acompanhamento de UBS.

Acrônimos e Abreviações

UnB: Universidade de Brasília
FGA: Faculdade UnB Gama
UBS: Unidades Básicas de Saúde
UML: Unified Modeling Language (Linguagem de Modelagem Unificada)
REST: Representational State Transfer (Transferência Representacional de Estado)
HTTP: HyperText Transfer Protocol (Protocolo de Transferência de Hipertexto)
JSON: JavaScript Object Notation (Notação de Objetos JavaScript)
AWS: Amazon Web Services
EC2: Amazon Elastic Compute Cloud
LAN: Local Area Network (Rede de Área Local)

Referências

Visão Geral

Este documento busca informar de maneira compreensiva a arquitetura geral, bem como prover links para especificações mais detalhadas, do aplicativo Diário da Saúde. O documento traz, primeiramente, uma visão geral do sistema no tópico de Representação Arquitetural, demonstrando uma relação de macro nível entre os módulos do sistema, onde também são descritas as tecnologias utilizadas. Em seguida, há o tópico de Metas e Restrições da Arquitetura, descrevendo os requisitos e objetivos que geram impacto significativo na arquitetura. Logo após, são descritas as visões pertinentes para a compreensão da arquitetura, sendo elas: Visão de Casos de Uso, Visão Lógica, Visão de Processos, Visão de Implantação, Visão de Implementação e Visão de Dados. Por último, o tópico de Qualidade.

Representação Arquitetural

Este documento apresenta a arquitetura como uma série de visões: Visão de Casos de Uso, Visão Lógica. Essas visões são descritas e detalhadas através de diagramas UML acompanhados de descrições curtas.

Estilos arquiteturais

Estilo arquitetural é uma forma de expressar a organização de uma estrutura e o conjunto pré-definido de subsistemas e suas responsabilidades.

Considerando o desenvolvimento incremental e a modelagem de interfaces de subsistemas, o estilo arquitetural utilizado é uma adaptação do N-Camadas, junto a uma adaptação do padrão arquitetural MVC, com N igual a 4. Para a comunicação entre as camadas de backend e frontend é utilizado o estilo REST.

Camadas

Aplicação mobile - camada frontend onde os dados são apresentados para o usuário final atuando como a camada de view do MVC. É sua responsabilidade disponibilizar as funcionalidades e apresentar os dados para os usuários. As requisições são feitas em estilo REST com o uso dos verbos HTTP (GET, POST, DELETE, PUT).
Controller - camada backend que recebe as requisições do frontend (através das routes). É sua responsabilidade disponibilizar os endpoints em estilo REST que serão consumidos pelo frontend. As respostas às requisições são em formatos JSON.
Model - camada backend que comunica com a controller e com o banco de dados. É sua responsabilidade implementar os modelos fazendo a comunicação com o banco de dados.
Banco de dados - camada de persistência dos dados. Sua responsabilidade é armazanar e garantir o acesso adequado aos dados.

O estilo N-Camadas permite a alteração dos dados independentemente da sua representação, assim como permite alterar a representação independentemente dos dados. Dessa forma, os dados podem ser apresentados de maneiras diferentes e de forma sincronizada. Nota-se uma tendência de acoplamento entre as controllers e as models no backend.

Tecnologias

Back-End

Node.js: é um ambiente de execução JavaScript server-side, sem dependência com navegadores web. Sua utilização apresenta vantagens como alto fator de escalabilidade, taxa de transferência e flexibilidade.

Front-End

React Native: é um framework JavaScript para aplicações mobile desenvolvido pelo Facebook. Ele é utilizado para desenvolver aplicações móveis de forma nativa, permitindo aos desenvolvedores levar a aplicação para sistemas Android e iOS simultaneamente.

Banco de Dados

MongoDB: é uma ferramenta de banco de dados não relacional. Utiliza documentos semelhantes ao JSON par organizar os dados, oferecendo alta variedade e flexibilidade.

Outros

Docker: é uma ferramenta que utiliza virtualização de SO para entregar software em pacotes chamados contêineres. Os contêineres são isolados uns dos outros e possuem seus próprios softwares, bibliotecas e arquivos de configuração. Está sendo utilizado tanto no back-end quanto no front-end, com o objetivo de facilitar o desenvolvimento em grupo.

Metas e Restrições Arquiteturais

Restrições

É necessário ter conexão com a Internet para utilizar o aplicativo;
A aplicação oferecerá suporte para Android e iOS;
O escopo proposto deve ser terminado até a data estipulada para entrega;
O software deve ser desenvolvido utilizando as tecnologias mencionadas anteriormente;

Metas

Usabilidade: o software deve ser de fácil utilização, com foco em aprendibilidade e simplicidade, buscando atender ao público (maioria de idade avançada) para o qual o software está sendo desenvolvido;
Segurança: o software deve garantir a segurança dos dados dos usuários.
Manutenibilidade: o software deve ser de fácil modificação posterior a finalização do trabalho, facilitando continuação;

Visão de Casos de Uso

Neste tópico há uma descrição da visualização dos casos de uso da arquitetura de software. Aqui são descritos cenários e/ou casos de uso que representam uma funcionalidade significativa para o sistema.
Os casos de uso deste sistema estão listados abaixo. Aqueles destacados em negrito possuem impacto significativo na arquitetura e são descritos posteriormente neste mesmo tópico.

UC01 - Cadastro/Login
UC02 - Visualizar lista de grupos
UC03 - Acessar grupo
UC04 - Visualizar informações do grupo
UC05 - Responder formulário
UC06 - Editar perfil
UC07 - Gerenciar pacientes
UC08 - Adicionar pacientes
UC09 - Excluir pacientes
UC10 - Gerar relatório
UC11 - Gerar relatório individual
UC12 - Gerar relatório geral
UC13 - Criar grupo
UC14 - Criar formulário
UC15 - Escolher perguntas

Casos de uso - Paciente

Casos de uso - Profissional da Saúde

Descrição dos casos de uso significativos

UC01 - Cadastro/Login: este caso de uso ocorre quando o usuário realiza o cadastro ou login no sistema. Como há permanência de dados, o cadastro precisa ser realizado somente uma vez para cada usuário. É importante notar que o paciente e o profissional da saúde compartilham este caso de uso, sendo necessário a diferenciação (realizada pelo próprio usuário) para qual tipo de ator a conta se refere durante o cadastro.
UC02 - Visualizar lista de grupos: este caso de uso ocorre assim que o usuário loga no aplicativo. A tela inicial apresenta a lista de grupos aos quais o usuário pertence (no caso de paciente) ou que o usuário possui (no caso de profissional da saúde).
UC03 - Acessar grupo: este caso de uso é exclusivo para o ator profissional da saúde e ocorre quando o usuário seleciona algum grupo específico da lista de grupos. Serão apresentadas informações do grupo e diferentes ações a serem tomadas para gerenciamento dos membros.
UC05 - Responder formulário: este caso de uso é exclusivo para o ator paciente e consiste em responder o formulário de determinado grupo. É importante notar que é possível responder o formulário tanto a partir da lista de grupos, quanto a partir da seleção de um grupo específico.
UC07 - Gerenciar pacientes: este caso de uso é exclusivo para o ator profissional da saúde e consiste em gerenciar os pacientes de um grupo qualquer. É possível adicionar ou remover pacientes.
UC10 - Gerar relatório: este caso de uso é exclusivo para o ator profissional da saúde e consiste em gerar um relatório dos dados obtidos a partir dos formulários. É possível gerar um relatório geral do grupo ou selecionar um paciente específico para obter um reltório individual.
UC13 - Criar grupo: este caso de uso é exclusivo para o ator profissional da saúde e consiste em criar um novo grupo. Não é possível criar um grupo sem adicionar um formulário.
UC14 - Criar formulário: este caso de uso é exclusivo para o ator profissional da saúde e consiste em criar o formulário de um grupo. O formulário é customizável a partir de uma gama de questões pré-existentes.

Visão Lógica

Neste tópico há uma descrição das principais classes e pacotes que compõem o sistema. As descrições estão posicionadas logo após os diagramas de Classe e Pacotes.

Diagrama de Classes

O diagrama de classes sem métodos e atributos colapsados pode ser visto no diagrama de classe completo.

Principais classes

Person: a classe Person representa o usuário do sistema. Duas outras classes herdam dela, a classe Patient e a classe HealthProfessional. Essa estrutura de herança foi estabalecida devido a semelhança que as duas classes filhas possuem entre si, facilitando a modularização. Na classe pai estão descritos os atributos e métodos que ambas as classes filhas compartilham, enquanto em cada uma das classes filhas estão descritos os atributos e métodos exclusivos daquele tipo de usuário.
Group: a classe Group representa os grupos. Os grupos são contituídos de vários usuários do tipo Patient e estão associados a um único Form.
Form: a classe Form representa os formulários de perguntas de cada grupo.
Question: a classe Question representa as perguntas existentes no sistema. Esta classe é uma interface, de forma que seu comportamento é definido de acordo com as classes filhas. As classes filhas são as perguntas registradas no sistema e que constituem um formulário.
Report: a classe Report representa os relatórios individuais ou gerais.

Diagrama de Pacotes

Camada Mobile: a camada de frontend é composta pelos diretórios Context, Routes, Pages, Services e Components. O primeiro, respectivamente, é responsável por prover informações e contexto para toda a aplicação. O segundo tem como papel definir os caminhos de acesso do usuário às várias telas da aplicação. O diretório Pages guarda as telas da aplicação. O diretório Services contém os scripts com as regras de negócios e métodos como os de requisições HTTPs. Por último, a pasta Components guarda arquivos responsáveis por renderizar partes específicas, normalmente repetidas, das telas.
Camada Backend : a camada do backend é onde se encontra o projeto da API feita em Node.Js e Express. Ele segue uma estrutura MVC. A pasta index é o diretório que guarda o código iniciliazador da aplicação e é a partir dele que todos os outros códigos são inicializados. Routes é o diretório que guarda os arquivos de rotas da aplicação, por onde passam todas as requisições http feitas à API. Controllers é a pasta que onde se encontram os arquivos de "ações", que são responsáveis por recuperar os dados do banco atráves das models. Os scripts de controller são utilizados dentro dos arquivos de routes.
Camada Mongo: A camada do Mongo é onde ficam os arquivos de configuração do banco de dados MongoDB.

Diagrama de comunicação

Uma importante interação entre objetos é a interação entre Profissional de Saúde e o Grupo descrita no Diagrama de Comunicação:

Visão de Processos

Neste tópico há uma descrição dos principais processos que ocorrem durante a utilização do sistema. Para acompanhar a descrição dos principais processos, seguem os Diagramas de Sequência pertinentes.

Diagramas de Sequência

Principais processos

showAll(): processo responsável por retornar conjuntos de informações, a depender do argumento fornecido (sobrecarga). É muito utilizado durante todo a execução do aplicativo, principalmente para apresentar todos os grupos ao qual o usuário está atrelado.
getAllPatients(): processo responsável por retornar lista de pacientes pertecentes a um grupo. Muito utilizado pelo usuário profissional da saúde para gerenciar os membros de um grupo.
getQuestions(): utilizado durante a criação e o acesso a formulários, retorna as questões que um determinado formulário possui.
sendAnswers(): processo essencial para a principal função da aplicação: manter contato entre paciente e profissional da saúde. Este processo recebe e salva as respostas de cada paciente para que o profissional da saúde possa realizar uma avaliação posteriormente.

Visão de Implantação

O aplicativo mobile fica hospedado na Google Play Store disponível para download no celular do usuário com sistema operacional Android. O aplicativo comunica-se com o backend atráves da internet com uma conexão wireless ou conexão móvel (3G/4G). O backend fica hospedado em uma instância EC2 da AWS com servidor ubuntu. A base de dados também fica hospedada na instância Amazon EC2. A comunicação do backend com a base de dados é feita pela rede local (LAN).

Diagrama de Implantação

Visão de Implementação

Após a autenticação, pacientes podem responder as questões dos formulários dos grupos aos quais pertencem, fornecendo os dados para a geração de relatórios individuais. Profissionais de saúde, após a autenticação, podem gerenciar grupos e gerar relatórios individuias e gerais. Uma representação de como esses importantes componentes do sistema são conectados pode ser vista no diagramas de componentes.

Diagrama de Componentes

Visão de Dados

Neste tópico há uma descrição do modelo de persistência de dados utilizado no sistema, representando como os modelos são persistidos no banco de dados não-relacional MongoDB.

Modelo Grupo

Formato dos dados

_id
- Tipo: Number;
- Obrigatoriedade: Sim.
groupName
- Tipo: String;
- Obrigatoriedade: Sim.
idForm
- Tipo: Number.
idUBS
- Tipo: Number;
- Obrigatoriedade: Sim.
users
- Tipo: Array de dados do tipo Number;

Exemplo

  {
    "_id":1,
    "groupName":"Grupo de Hipertensos",
    "idForm":1,
    "idUBS":1,
    "users":[12,23,56,12]
  }

Modelo Profissional da Saúde

Formato dos dados

_id
- Tipo: Number;
- Obrigatoriedade: Sim.
name
- Tipo: String;
- Obrigatoriedade: Sim.
password
- Tipo: String.
- Obrigatoriedade: Sim.
cpf
- Tipo: Number;
- Obrigatoriedade: Sim.
role
- Tipo: String;
- Obrigatoriedade: Sim.

Exemplo

 {
   "id":1,
   "name":"Ipsolum",
   "password":"76bb1ff3699e0af3750e9fa119dea44e",
   "cpf":1234567890,
   "role":"healthProfessional",
 }

Considerando o paradigma de orientação a objetos, temos a descrição do comportamento das entidades do sistema utilizando o DE-R e para definir as regras de negócio entre as entidades temos o Diagrama Lógico.

Qualidade

Usabilidade: a interface, conforme descrito anteriormente, segue uma estilização simples e intuitiva, utilizando fontes e cores adequadas. Estas definições podem ser visualizadas no documento de Identidade Visual.
Segurança: cada sessão do usuário recebe um token temporário, utilizado para realizar a autenticação do usuário e resgatar dados privados do banco.
Manutenibilidade: todo o desenvolvimento do projeto foi documentado no repositório do grupo: Diário da Saúde. O fácil acesso a documentação facilita na compreensão e apoia a manutenibilidade do código.