Documento de Arquitetura

Histórico de Versão

Data	Versão	Descrição	Autor(es)
21/03/2017	0.1	Criação do documento de acordo com o template do modelo RUP.	André de Sousa
22/03/2017	0.2	Seção 1	André de Sousa
23/03/2017	0.3	Início da secção 2 e secção 3	André de Sousa, Filipe Coelho, Emanoel Belchior, Guilherme willer, Igor Araujo, Vinicius Oliveira, Matheus Batista
23/03/2017	0.4	Seções 2, 3, 4, 5, 11	André de Sousa, Filipe Coelho, Emanoel Belchior, Guilherme willer, Igor Araujo, Vinicius Oliveira, Matheus Batista
24/03/2017	0.5	Reestruturação documento, revisão e alteração das seções 4, 5, 8	André de Sousa, Filipe Coelho, Guilherme willer, Igor Araujo, Matheus Batista
27/03/2017	0.6	Reestruturação e correções na seção 1.5	André de Sousa
30/03/2017	1.0	Liberação baseline	André de Sousa, Filipe Coelho, Emanoel Belchior, Guilherme willer, Igor Araujo, Vinicius Oliveira, Matheus Batista
01/04/2017	2.0	Revisão do Documento de Arquitetura	Lucas Mattioli e Victor Hugo
06/04/2017	2.1	Parágrafos Justificados	Emanoel Belchior
14/04/2017	2.2	Adiciona diagramas atualizados	André de Sousa
15/04/2017	2.3	Adicionado novo ator e casos de uso	Emanoel Belchior
18/04/2017	2.4	Revisão	André de Sousa

Sumário

1. Introdução
   1.1. Propósito
   1.2. Escopo
   1.3. Definições, acrônimos e abreviações
   1.4. Referências
   1.5. Visão geral
2. Representação da Arquitetura
3. Metas e Restrições da Arquitetura
4. Visão dos Casos de Uso
   4.1. Atores de Caso de Uso
   4.2. Descrições de Casos de Uso
5. Visão Lógica
   5.1. Pacotes de Design Significativos do Ponto de Vista da Arquitetura
       5.1.1. Classe
       5.1.2. Pacotes
6. Visão de Implementação
7. Visão de Dados
   7.1. MER - Modelo Entidade Relação
   7.2. DER - Diagrama Entidade Relação
8. Tamanho e Desempenho

---

1. Introdução

1.1 Finalidade

Este documento possui como finalidade a elucidação das questões relacionadas à implementação arquitetural do projeto Escola-X, desenvolvido nas disciplinas de Métodos de Desenvolvimento de Software e Gestão de Portfólios e Projetos de Software, que possui como cliente principal a diretoria da escola CEM 01 do Gama.

1.2 Escopo

Este artefato documenta a arquitetura a ser implementada no software e abrange assuntos relacionados à metas e restrições arquiteturais, visões de casos de uso, processos, implementação, dados e lógica além de questões de desempenho, tamanho e qualidade.

1.3 Definições, Acrônimos e Abreviações

Alguns dos acrônimos, definições e abreviações usados neste documento são:

• CEM 01 - Centro de Ensino Médio 01 do Gama (CG).
• DF - Distrito Federal.
• MDS - disciplina Métodos de Desenvolvimento de Software.
• GPP - disciplina Gestão de Portfólios e Projetos de Software.
• MVC - Arquitetura padrão Model View Controller.
• HTML - HyperText Markup Language, linguagem padrão para construção de páginas web.
• XML - Extensible Markup Language, linguagem de marcação usada para diversas finalidades de estruturação de ambientes visuais ou interfaces.
• SMS - Short Message Service.
• RoR - Ruby on Rails, framework de criação de aplicações web.

1.4 Referências

Este documento faz referência aos seguintes links e/ou documentos:

• Comparação navegadores

• -- http://www.laptopmag.com/articles/best-windows-browser

• -- http://www.makeuseof.com/tag/which-browser-is-best-edge-vs-chrome-vs-opera-vs-firefox/

• Linguagem Ruby

• -- https://www.ruby-lang.org/pt/

• Bootstrap

• -- http://getbootstrap.com/

1.5 Visão Geral

Este documento descreve os detalhes sobre as características arquiteturais do software Escola X a ser desenvolvido, especificando os problemas relacionados a arquitetura da solução em software. O documento é dividido da seguinte maneira: inicialmente é apresentada a arquitetura da solução, em seguida as metas e restrições desta arquitetura são descritas, depois são apresentadas diversas visões sobre elementos da arquitetura e por fim todos os recursos referentes ao tamanho, desempenho e qualidade do software. Durante o documento serão apresentados os diagramas de casos de uso, pacotes, classes e a representação diagramada da modelagem do banco de dados.

2. Representação da Arquitetura

O projeto Escola X utilizará a arquitetura MVC, que organiza o sistema em três partes distintas: Modelo, controle e visão.

A camada de modelo é o lugar onde os dados são estruturados, consultados e validados. Ela se conecta diretamente com a camada de controle pois a camada de controle que, através do input da camada de visão, irá definir quais dados serão consultados para que a camada de modelo faça conexão com a base de dados, e retorne sua resposta baseando-se nos dados analisados ou alterados. Um exemplo de classe da camada de modelo é a verificação de login, pois é uma ação requisitada por um ator que passa pela camada de visão, controle e, por fim, chega na camada de modelo para ser validada ou não.

A camada de visão é a responsável por todas as interações com o usuário e também fará contato com a camada de controle para definir quais informações serão mostradas para o usuário. As principais funções da camada de visão são mostrar a interface gráfica para os usuários e fazer a comunicação com a camada de controle. Um exemplo dessa camada é a interface do usuário na aplicação.

A camada de controle é a camada que faz a ligação entre usuário e os dados, tendo vital importância dentro da arquitetura de nosso sistema. Os principais métodos que serão implementados estão na camada de controle. Para que essa camada execute os métodos ela recebe os comandos passados pelo usuário através da camada de visão e manipula os dados recebidos da camada de modelo.

Fonte: http://abap101.com/wp-content/uploads/2011/08/mvc.png

O MVC em RoR segue o mesmo padrão da arquitetura MVC que outras linguagens utilizam, apesar de possuir outras funcionalidades. A model mantém a relação entre os objetos e o banco de dados e manipula validação associação, transação e muito mais. Esse subsistema é implementado na biblioteca ActiveRecord, que fornece uma interface de vinculação entre as tabelas em um banco de dados relacional e o código de programa em Ruby que manipula registros do Banco de dados. Por padrão o ActiveRecords usa algumas convenções para nomenclatura para descobrir como o mapeamento entre os modelos e tabelas do banco de dados devem ser criados, o Rails pluraliza os nomes das classes para encontrar as tabelas nos respectivos bancos de dados.

fonte: http://blog.ifuturz.com/ruby-on-rails/ruby-on-rails-mvc-learn-with-fun.html

fonte : http://guides.rubyonrails.org/active_record_basics.html

View é a representação dos dados em formato específico, gerada a partir da controller, esse subsistema é implementado pela biblioteca ActionView, que é uma API do Rails.

A Controller é utilizada para que seja possível realizar a conexão entre a tela onde o usuário consegue interagir com o software e os dados armazenados do programa, de modo que são realizadas ações relacionadas à manipulação desses dados do banco, como: listar, procurar, alterar, inserir ou deletar informações. Para realizar essas funções os controladores do rails recebem as requisições HTTP do browser direcionando para as views específicas, e, assim, executando os métodos solicitados.

3. Metas e Restrições da Arquitetura

O sistema a ser desenvolvido será suportado por navegadores web como Mozilla Firefox, Microsoft Edge e Google Chrome, sendo otimizado para este último por conta de possuir recursos, em sua maioria, superiores aos outros navegadores disponíveis no mercado, além de abranger a maior parte dos usuários de navegadores mobile e desktop.

O projeto será implementado usando a linguagem de programação Ruby, versão 2.3.1, no framework de desenvolvimento Rails na versão 5.1.0 e terá comportamento responsivo, ou seja, o mesmo site da aplicação será otimizado para uso tanto em dispositivos móveis, quanto desktops, utilizando o framework de desenvolvimento front-end Bootstrap 3.

Para que o software funcione será necessária conexão com a internet e, para os responsáveis, será necessária a recepção de sinal de telefone para notificações via SMS.

O software por possuir uma base de dados pessoais bastante pertinente dos alunos deverá manter estes dados em segurança dentro da base de dados do sistema, assim como as credenciais de usuários se tornam necessárias para a filtragem de recursos dentro do aplicativo.

4. Visão dos Casos de Uso

Clique aqui para visualizar a imagem maior

Diagrama de casos de uso.

4.1 Atores de Casos de Uso

Ator	Descrição
Adm(Diretor)	O adm irá manter os dados do corpo docente, dos alunos e poderá consultar os dados dos alunos
Aluno	O aluno irá registrar sua entrada e saída e poderá consultar seus dados
Responsável	O responsável pode consultar os dados do aluno e será notificado da sua entrada e saída
Professor	O professor pode consultar dados dos alunos e gerar notificação
Secretário	O secretário pode registrar nota e consultar dados dos aluno

4.2 Descrições de Casos de Uso

Caso de uso	Descrição
UC01 - Manter alunos	Criar, alterar ou deletar um aluno.
UC02 - Registrar advertência	Registrar uma nova advertência para um aluno.
UC03 - Registrar suspensões	Registrar uma nova suspensão para um aluno.
UC04 - Registrar notificação	Registrar notificação para aluno.
UC05 - Manter Responsáveis	Criar, alterar ou deletar um responsável de um aluno.
UC06 - Consultar aluno	Fazer a busca pelo o histórico de um aluno.
UC07 - Visualizar número de faltas	Acessar o número de faltas de um determinado aluno.
UC08 - Visualizar Boletim	Acessar o boletim de um determinado aluno.
UC09 - Visualizar advertências/suspensões	Acessar o número de advertências/suspensões de um determinado aluno.
UC10 - Dar nota	Adicionar notas dos alunos.
UC11 - Registrar entrada/saída	Registrar a hora de entrada ou saída do aluno.
UC12 - Notificar os Responsáveis	Mandar SMS para os responsáveis após entrada/saída do aluno.
UC13 - Manter corpo docente	Criar, alterar ou deletar um membro do corpo docente.
UC14 - Fazer login	Acessar funcionalidades do sistema.

5. Visão Lógica

5.1 Pacotes de design Significativos do Ponto de Vista da Arquitetura

5.1.1 Classe

Clique aqui para visualizar a imagem maior

Diagrama de classe da Controller.

5.1.2 Pacotes

Clique aqui para visualizar a imagem maior

Diagrama de Pacotes.

6. Visão de Implementação

No pacote View ficarão todos os arquivos referentes a parte visual do software, que são os arquivos HTML e CSS. Em RoR a camada View é implementada na biblioteca ActionView que define modelos de apresentação para dados.

O pacote Model mantém o relacionamento entre os objetos e o banco de dados, fazendo as validações necessárias ao sistema. Em RoR a camada Model é implementada pela biblioteca ActionRecord que oferece uma interface de relacionamento entre as tabelas do banco de dados e o código do programa.

O pacote Controller é responsável por fazer a integração entre o pacote View e Model. Em RoR a camada Controller é representada pelo pacote ActionController que faz o controle de dados entre a ActionRecord e ActionView.

7. Visão de Dados

7.1 MER

Clique aqui para visualizar a imagem

7.2 DER

Clique aqui para visualizar a imagem

8. Tamanho e Desempenho

A escola CEM 01 do gama possui quase dois mil alunos, logo a quantidade de dados que devemos processar é extensa, pois, todos os dias, dois novos dados são inseridos em um curto período de tempo e os responsáveis são informados cada vez que esse evento ocorre, e assim a saída de dados também será extensa. Seu desempenho será determinado principalmente pelo aparelho que o sistema será usado e pelo navegador.