Data	Versão	Descrição	Autor
27/03/2016	1.0	Estruturação inicial do documento	Jônnatas Lennon Lima Costa
31/03/2016	1.1	Visão Geral, inicio Restrições	Eduardo Brasil
02/04/2016	1.2	Adição da seção 5.2	Vitor Nere
03/04/2016	1.3	Tamanho e Desempenho ,Qualidade	Eduardo Brasil
03/04/2016	1.4	Adições e alterações das seções 5.1, 7.1, 8.1	Jônnatas Lennon
03/04/2016	1.5	Adição da seção 1.4 e ajustes	Vitor Nere
03/04/2016	1.6	Revisão do documento	Hugo Martins

Este artefato detalha a arquitetura utilizada no desenvolvimento do sistema #PartiuFormar.

Este documento trata da implementação arquitetura do #PartiuFormar com base nos diagramas UML acerca dos casos de uso, diagramas de classe, além da visão lógica do sistema com o detalhamento da arquitetura MVC utilizada, no desenvolvimento.

Documento de Arquitetura de Software (RUP)

Diagrama de Casos de Uso

Esse documento está dividido nas seguintes seções:

1. Introdução
2. Representação da Arquitetura
3. Restrição de Arquitetura e Metas
4. Visão de Casos de Uso
5. Visão Lógica
6. Visão de Implementação
7. Visão de Dados
8. Tamanho e Desempenho
9. Qualidade

MVC padrão do Rails

Na representação acima mostra o funcionamento da arquitetura MVC aplicada no rails, a qual segue os seguintes passos, usuário digita _http://exemplo.com/bem-vindo .

1. O Browser faz uma solicitação para o URL /bem-vindo, o pedido atinge o Rails router.
2. O Router mapeia o URL para uma Controller, para a manipulação da solicitação.
3. O Model retorna dados para a ação da Controller.
4. A Controller, passa os dados para a View.
5. A View renderiza e retorna a página como HTML, de volta para o Browser.

A arquitetura definida:

O sistema deverá ser desenvolvido usando Ruby on Rails, que é uma framework escrito na linguagem Ruby e baseado no padrão de arquitetura MVC (Model-View-Controller), como já citado neste documento.

Para a persistência de dados será utilizado o SQLite3, devido a sua praticidade e estabilidade.

O caso de uso fundamental à arquitetura é:

UC 001 – MANTER USUÁRIOS

Os diagramas de sequência dos casos de uso, fornecem a visualização da comunicação entre as camadas.

O usuário interage com o sistema através da view, realizando alguma operação no sistema, a view solicita a controller a ação realizada, A controller processa as informações por meio da comunicação com a model e o datavase, que por sua vez se comunica com o banco de dados, que por conseguinte repassa o resultado da operação solicitada para a view.

Visão geral da arquitetura

O sistema #PartiuFormar é uma aplicação web construída de acordo com o modelo de arquitetura MVC (model-view-controller).

1. A camada de View é responsável pelo front-end, onde é estabelecida a comunicação entre o usuário e a aplicação. A comunicação acontece apenas com a _Controlle_r, através de requisições.

2. A camada Controller trata da parte que processa cada ação do sistema, como por exemplo, requisições do usuário. Didaticamente, pode ser entendida como uma ponte de ligação entre a Model e a_ View_, ou seja a Controller interpreta os eventos que acontecem na camada View, e opera os dados que estão na Model validando os mesmos, estabelecendo a comunicação com o database a qual fica com a responsabilidade de armazenar estes dados no banco de dados da aplicação.

3. A camada de Model representa os dados da aplicação, basicamente na camada Model ocorre o tratamento da escrita, validação e leitura dos dados. Estes dados devem estar descritos pelas regras de negócio do sistema. Assim a Model, armazena se necessário os dados no database, e se comunica com a Controller quando houver necessidade de exibição, e a Controller decidirar em qual view exibir os dados da Model .

4. Router esta camada é nativa do Rubi on Rails, a qual reconhece URLs e direciona a uma Controller especifica.

Representação da visão geral do PartiuFormar

Aqui encontra-se uma representação visual dos pacotes presentes neste projeto:

Como pode ser observado no diagrama abaixo, utilizamos o padrão Strategy para o calculo do IRA, isto ocorreu para dar maior flexibilidade ao código, este Strategy será aplicada na Grade curricular ao final do semestre, deste modo ao final do semestre em cada disciplina associada a grade aplica-se uma estrategia diferente para o calculo do ira com base na menção referente.

Utilizou-se também o padrão State para alternar os estados das menções referentes as disciplinas, assim uma disciplina pode ter 8 estados diferentes (cursando CC, trancamento TR, SR, II, MI, MM, MS, SS).

Para armazenar no fluxo as grades de semestres anteriores utilizou-se o padrão Memento, através deste padrão temos salvo as grades anteriores, para o calculo de um novo fluxo.

Tem-se também o facade para controlar o acesso do usuário no sistema, assim para um estudante apenas algumas funcionalidades serão exibidas, já na fachada do administrador todas as funcionalidades serão exibidas, para organizar melhor estas classes, criou-se dois pacotes diferentes o _StudentInterface _e o AdminInterface.

Representação do Diagrama de classes da Model.

Admin Iterface package

Student Interface package

As views são separadas em pastas, nestas pastas contem-se os arquivos utilizados para a renderização da views.

As controllers surgem por demanda, a medida que as classes de model são criadas, as classes de controller como o próprio nome diz funcionam como controladoras das requisições da View sobre os dados das models.

Diagrama de esquema do banco de dados, feito na ferramenta MySQL Workbench.

Para a implantação do partiuformar pode-se utilizar o Heroku, este é bem simples e facil de configurar.

O objetivo do #PartirFormar é fazer com que o máximo de usuários consigam acessar o app no menor tempo possível. todavia, os fatores de desempenho dependem do servidor em que o app esteja hospedado

Com a definição da arquitetura, houve uma independência proporcionada ao dividir em três partes principais a aplicação. O MVC também torna mais simples a manutenção do software, pois sua estrutura de arquivos torna fácil localizar trechos específicos de código, esse padrão arquitetural é a melhor solução para o modelo de aplicações web que propomos.