Documento de Arquitetura

1. Introdução

Esse documento apresenta uma visão acerca da arquitetura de software que será empregada para que o desenvolvimento da aplicação Bring to Me apresente resultados satisfatórios.

1.1 Finalidade

Este documento apresenta uma visão geral da Arquitetura do software a ser produzido de modo a estabelecer um padrão de projeto que possibilite os desenvolvedores do Bring to Me terem uma melhor noção da arquitetura a ser desenvolvida além de demonstrar ao grande público aspectos relevantes da aplicação.

1.2 Escopo

Neste documento serão explicitadas as principais partes da arquitetura proposta para o desenvolvimento da aplicação web denominada Bring to Me. A arquitetura é apresentada a partir de uma série de paradigmas que são formas de ver a arquitetura, seja essa visão lógica, por caso de uso ou por modelo de dados, todas irão dar visões diferentes do que se espera do desenvolvedor para a construção do software. O documento de arquitetura também serve como base para eventuais decisões que causarão grande impacto ao projeto.

1.3 Visão Geral

Nesse documento é apresentada a representação da arquitetura, suas metas e restrições. No fim do mesmo, há um comparativo das diferentes visões referentes a parte técnica (visão de casos de uso, a visão lógica e a visão de implementação)

2. Representação da Arquitetura

O Bring to Me possui uma proposta de arquitetura desenvolvida em três camadas: Model, View e Controller

A camada Model (Modelo): Essa camada é a que possui os primeiros pensamentos referentes solução do problema a ser resolvido, apresentando informações pré-estabelecidas, tais como as atributos inerentes a cada classe.
A camada Controller (Controladora): Essa camada é responsável por gerenciar a maneira que se comunicarão as camadas View e Model. Essa comunicação é feita por meio de solicitações dos usuários, as quais são efetuadas na camada View. A controller faz todas as operações necessárias para retornar o resultado desejado ao usuário.
A camada View (Visão): Essa camada têm a função de exibir, de forma gráfica, tudo que o usuário precisa saber para usar a aplicação da melhor forma, não havendo necessidade de entrar em contato com o código-fonte e com uma visão mais técnica.

Na imagem abaixo pode ser vista a estrutura de comunicação estabelecida entre as camadas.

3. Metas e Restrições de Arquitetura

O produto possui algumas restrições referentes a arquitetura, restrições essas criadas pela equipe de desenvolvimento de forma que melhor atenda as necessidades tanto da aplicação como da equipe. As restrições são:

Será desenvolvido na linguagem de programação Ruby on Rails, Ruby 2.3.0 e Rails 4.2.6;
Deve utilizar um Banco de Dados do tipo relacional, sqlite3;
Por se tratar de uma aplicação web, quando o produto atingir um certo grau de maturidade ele sera publicado na rede, de modo que o usuário só terá acesso ao mesmo quando estiver online.
O emprego do padrão MVC (Model, View e Controller) é uma meta de desenvolvimento do Bring to Me. Essa abordagem prevê a produção do software frente a três camadas que possuem comunicação pré definida. Utilizando o MVC, há uma garantia de que o código seja melhor modularizado, o que torna o desenvolvimento mais fácil e organizado, evitando possíveis overheadas.

4. Visão Lógica

A aplicação Bring to Me terá como base a estrutura MVC, isso significa que o usuário só terá contato com a view. fará a ligação entre ele e o software. A partir dessa interação, o resultado da mesma servirá de insumo para que as controllers tomem conta dos devidos procedimentos, as chamadas ações lógicas que resultarão em alterações na camada model que por sua vez, servirá para o retorno de informações.

4.1 Visão Geral

Como já foi citado, a estrutura utilizada MVC, sendo que na imagem abaixo é possível obter uma visão geral do projeto como um todo a partir de suas camadas. As três principais camadas stão dentro da pasta app são elas: model, view e controller, que corresponde ao desenvolvimento e produção do software. Os outros pacotes são gerados a partir da forma de trabalho default da plataforma Ruby on Rails, como a de teste. No pacote db o subpacote e arquivos de migrate responsáveis por gerar as migrações da aplicação, ou seja, inserir as devidas colunas nas tabelas do banco de dados. No pacote config têm-se o arquivo route que fará os redirecionamentos, ou seja, gerenciar as rotas da aplicação como um todo, no que tange as urls. O pacote lib tem como função alocar as bibliotecas serão construídos conforme o desenvolvimento do projeto.

4.2 Pacotes no Ponto de Vista da Arquitetura

4.2.1 Model

O pacote da model serve para fornecer as características iniciais de cada entidade do software. Cada model possuirá uma controller que fará com que os atributos inicialmente inseridos dentro do contexto da model sejam manipulados, além dos próprios atributos servirem de insumo para operações mais lógicas dentro da aplicação.

4.2.2 Controller

O pacote da controller terá a responsabilidade de executar as decisões lógicas do software. Cada controller deve ser ligada a uma model, e seus métodos precisam ter o nome exatamente igual a view que ele é associado.

4.2.3 View

Como dito anteriormente, a camada de visão é responsável por estabelecer uma interação com o usuário final. Com isso, a view acaba sendo um dos pacotes mais importantes de nossa arquitetura, além de pertencer a uma das três camadas principais da aplicação. No padrão da plataforma usada (rails) cada model possui um subpacote dentro do pacote de views sendo que as controllers fazem os devidos procedimentos para cada interação.

4.2.4 Database

Este pacote têm como característica de subpacote mais importante o migrate, que como já dito, conterá os arquivos que promoverão as mudanças da aplicação no banco de dados.Há também um arquivo seed que têm como principal objetivo persistir alguns objetos no banco de dados, serve como um pequeno parser

4.2.5 Test

No pacote test, como o nome sugere, são alocados os arquivos de testes, organizados por subpacotes similares aos contidos na pasta app, porém sem um pacote para views. Os testes para models são chamados unitários, já os testes das controllers são chamados de testes funcionais.

5. Visão de Casos de Uso

Os casos de uso que servem para dar uma melhor visão da arquitetura são:

7. Visão de Dados

Neste modelo é apresentado um modelo que representa as entidades e relacionamentos no banco de dados. Ao longo das iterações, conforme o produto é evoluido esse modelo se tornará mais complexo e robusto

Modelo de Banco de Dados

8. Visão de Implantação

A aplicação será executada em um computador pessoal operando o Sistema Operacional Debian Jessie. Como aplicação Rails, será utilizado uma máquina virtual Vagrant como ambiente de execução da aplicação, onde será executado um arquivo .deb contendo a aplicação.

Para executar o arquivo .deb no computador, deve ser criado um pacote contendo o código que iniciará a aplicação e automatizará a instalação.

Para a utilização do banco de dados pela aplicação, deve ser instalado o Banco de Dados SQlite e executado o script para a criação do banco de dados e popular as entidades.

A Figura abaixo mostra a visão de implantação descrita: