Skip to content

Documento de Arquitetura

Matheus Roberto edited this page Oct 4, 2017 · 36 revisions

Histórico de Revisões

Data Versão Descrição Autor
25/08/2017 0.1 Criação do documento Leonardo Dos Santos
26/08/2017 0.2 Descrição de casos de uso : Manter Usuário Adrianne Alves, Leonardo Dos Santos , Matheus Roberto, Pedro Kelvin, Daniel Oda, Vinícius Cantuária, Mateus de Oliveira
26/08/2017 0.3 Descrição de casos de uso : Listar Projetos Adrianne Alves, Leonardo Dos Santos , Matheus Roberto, Pedro Kelvin, Daniel Oda, Vinícius Cantuária, Mateus de Oliveira
26/08/2017 0.4 Descrição de casos de uso : Ver Problemas Adrianne Alves, Leonardo Dos Santos , Matheus Roberto, Pedro Kelvin, Daniel Oda, Vinícius Cantuária, Mateus de Oliveira
27/08/2017 0.5 Introdução : Finalidade Adrianne Alves
28/08/2017 0.6 Introdução : Escopo Adrianne Alves
28/08/2017 0.7 Visão de casos de uso: Atores Mateus de Oliveira
28/08/2017 0.8 Descrição de casos de uso: Adicionando novos casos Adrianne Alves, Leonardo Dos Santos , Matheus Roberto, Pedro Kelvin, Daniel Oda, Vinícius Cantuária, Mateus de Oliveira
28/08/2017 0.9 Descrição de casos de uso: Finalizando últimos casos Adrianne Alves, Leonardo Dos Santos , Matheus Roberto, Pedro Kelvin, Daniel Oda, Vinícius Cantuária, Mateus de Oliveira
28/08/2017 0.10 Representação da Arquitetura Adrianne Alves, Pedro Kelvin, Daniel Oda, Vinícius Cantuária
28/08/2017 0.11 Restrições e Metas Arquiteturais Matheus Roberto, Pedro Kelvin, Vinícius Cantuária
28/08/2017 0.12 Restrições e Metas Arquiteturais: Adicionando mais conteúdo Matheus Roberto, Pedro Kelvin, Vinícius Cantuária
28/08/2017 0.13 Desempenho Adrianne Alves, Mateus de Oliveira
28/08/2017 0.14 Qualidade Mateus de Oliveira
28/08/2017 0.15 Diagrama de Caso de Uso Adrianne Alves,Matheus Roberto, Pedro Kelvin, Vinícius Cantuária
31/08/2017 0.16 Visão Lógica Adrianne Alves,Matheus Roberto, Vinícius Cantuária
31/08/2017 1.0 Revisão Geral Pedro Kelvin
02/09/2017 1.1 Modificando Casos de Uso Pedro Kelvin
12/09/2017 1.2 Excluindo Caso de Uso: Ver Problemas Pedro Kelvin
15/09/2017 1.3 Editando índices Pedro Kelvin e Matheus Roberto
19/09/2017 1.4 Descrição caso de uso Login Matheus Roberto
19/09/2017 1.5 Atualização do diagrama UC Leonardo Dos Santos
28/09/2017 2.0 Revisão Geral Adrianne Alves
04/10/2017 2.1 Correção da descrição do banco de dados e do tópico 5.2.1 Matheus Roberto

  1. Introdução
  2. Representação da Arquitetura
  3. Restrições e Metas Arquiteturais
  4. Visão de Casos de Uso
  5. Visão Lógica
  6. Desempenho
  7. Qualidade

1. Introdução

1.1. Finalidade

Objetiva-se por meio deste documento exibir, de maneira detalhada, a arquitetura a ser empregada na plataforma Falko. Isso porque, procura-se alcançar uma compreensão recíproca a todos os membros da equipe de desenvolvedores do projeto, a fim de que haja o entendimento da estrutura da aplicação, em termos de tecnologias utilizadas. Além disso, espera-se que os desenvolvedores e demais interessados sejam capazes de visualizar as consequências advindas da arquitetura escolhida.

1.2. Escopo

Falko é uma plataforma desenvolvida para facilitar o processo de acompanhamento e gerência de projetos de desenvolvimento de software, que utilizam a metodologia ágil. Em termos técnicos, este documento abordará a arquitetura que será utilizada para a produção da aplicação, para que seja possível potencializar a assertividade do processo de desenvolvimento. Dessa forma, será exposta aqui toda a lógica de construção da plataforma, abordando os casos de uso, diagramas de classe, de pacote, informações técnicas a respeito do banco de dados, desempenho e qualidade.

2. Representação da Arquitetura

A arquitetura aqui exposta abrange dois diferentes ambientes a serem desenvolvidos para a plataforma Falko, isto é, o ambiente de controle de dados e negócios que é denominado API e o ambiente para interação com o usuário, caracterizado como frontend da aplicação.

Em relação à API será utilizado o framework Rails , que se baseia no modelo ou padrão arquitetural MVC, ele consiste em 3 camadas: Model, View e Controller (fig 1). A função principal da API será resguardar as informações mais relevantes e suas devidas regras de negócio, dessa forma, ao receber alguma requisição de dados por parte de aplicações exteriores, nesse caso a View, ela irá repassar os dados.

Em termos de frontend será utilizado o framework em javascript Vue, uma ferramenta eficiente para o desenvolvimento de Single-Page Applications. Nesse sentido, vue Js proporciona o desenvolvimento de componentes reativos, ou seja, pedaços de códigos reaproveitáveis formados por marcação, estilo e comportamento. Dessa forma, obtém-se maior facilidade para conectar elementos, como por exemplo, de html e javascript, na aplicação falko desempenhará o papel de unir a view à model, conforme apresentado na fig.2.

Fig 1

Fig 2

Para um melhor entendimento as camadas do MVC estão explicitadas a seguir:

2.1 Model

A partir de informações abstraídas do mundo real, a model é responsável pela representação e validação dos dados.

2.2 View

Interface responsável pela interação com o usuário, renderizando páginas, gráficos, informações, entre outros. Não possui o processamento lógico de dados.

2.3 Controller

Será a responsável por receber as requisições e interpretá-las, controlando a comunicação e os dados que serão fornecidos pela model para a view.

3. Restrições e Metas Arquiteturais

A aplicação Falko terá como base de sua arquitetura a utilização do framework Rails, que é baseado na linguagem de programação Ruby. Tal framework proporciona uma melhor manipulação e organização do projeto em termos de arquitetura de software. O banco de dados utilizado será o PostgreeSQL, para o armazenamento de dados dos usuários e demais informações a serem utilizada pelo Falko, o que faz o acesso à internet obrigatório para o uso da aplicação.

A utilização do modelo MVC que o framework Rails utiliza proporciona muitos benefícios. Isso por que mantém a integração entre os arquivos do projeto e facilita a manutenção no código, como por exemplo a inclusão de novas funções, mantendo a padronização da estrutura do projeto.

4. Visão de Casos de Uso

4.1. Atores

4.1.1 Gerente de Projeto

Esse ator tem acesso à todas funcionalidades do sistema, sem restrições de dados.

4.2. Descrição dos Casos de Uso

4.2.1 Login

Tem como objetivo fazer com que o cliente se identifique para o sistema, para que o sistema possa fornecer as informações corretamente a cada cliente.

4.2.2 Manter Usuário

Essa funcionalidade será responsável pela realização do cadastro do usuário, assim como a edição do seu perfil na plataforma, permitindo que ele visualize ou exclua os dados salvos no banco de dados. Dessa maneira, o mesmo poderá manter informações sobre os projetos com os quais está ou esteve envolvido e informações pessoais como nome, formação, telefone para contato e empresa a qual pertence.

4.2.3 Listar projetos

O usuário irá, por meio desta, visualizar todos os projetos que estão em andamento ou já foram concluídos. Entretanto, as informações e métricas expostas serão compactas, a fim de que demonstre uma visão geral do estado das suas aplicações.

4.2.4 Filtrar Métricas

Permite ao usuário selecionar quais são as métricas mais importantes a serem acompanhadas em seus projetos, de maneira que elas sejam apresentadas na dashboard. Dessa forma, não será necessário que o gerente aponte para um documento específico para visualizá-las.

4.2.5 Pesquisar projetos

A partir desta função o gerente poderá realizar a pesquisa de projetos específicos, dentre os cadastrados, facilitando e agilizando o processo de acompanhamento de produtividade.

4.2.6 Manter Projeto

Responsável por adicionar um projeto à aplicação, informando as informações necessárias para o gerenciamento. Além disso, o usuário poderá ter uma visão prévia dos que estão disponíveis e acessá-los para obter mais detalhes. O gerente poderá ainda, em caso de cancelamento de um projeto, excluí-lo da plataforma.

4.2.7 Integrar GitHub

Irá permitir ao usuário a obtenção de dados dos repositórios do GitHub que se deseja acompanhar.

4.2.8 Listar integrantes

Através desta função, o usuário poderá visualizar todos os membros de determinado projeto e informações sobre seu desempenho e produtividade como commits e issues resolvidas.

4.2.9 Exibir Métricas

Permite ao usuário verificar todas as métricas de determinado projeto, tais como: Issues, Burndown, Velocity, EVP e GPA. Entretanto, as métricas fornecidas dependerão do seu vínculo com a aplicação, condicionadas à integração ou não com o GitHub.

4.2.10 Expor Releases

Ao acessar a funcionalidade de exposição das releases o gerente de projetos terá acesso às informações relativas ao que deveria ser apresentado, à data da entrega e aos resultados obtidos em cada uma.

4.2.11 Gerenciar Sprint

Tem como objetivo iniciar uma nova sprint, adicionando-a ao sistema, com informações sobre o tempo de execução, objetivos a serem alcançados e comentários. O gerente poderá editar informações relacionadas ao tempo de duração, comentários e objetivos da Sprint. Além disso, o usuário poderá cancelar a sprint, através de uma justificativa. Entretanto, essa não poderá ser excluída pelo gerente, pois é necessária para o acompanhamento do desempenho e produtividade da equipe. Por meio desta funcionalidade o gerente terá à disposição todas as sprints criadas, a fim de observar o comportamento da equipe frente a determinada forma de condução expressa pelos objetivos e comentários de cada uma delas.

4.2.12 Ver Métricas de uma Sprint

O gerente terá acesso, por meio dessa função, às métricas referentes à sprint selecionada, como Burndown e Velocity, de acordo às características do seu projeto, no quesito de integração com o GitHub.

4.2.13 Revisar

O usuário terá à sua disposição a possibilidade de revisar uma sprint, visualizando informações sobre o seu desempenho, a fim de detectar possíveis problemas e comportamentos que tenham sido produtivos para a equipe.

4.2.14 Apresentar Retrospectiva

O gerente poderá acessar uma retrospectiva de sprints, por meio da qual irá acompanhar a evolução, observando os pontos bons, ruins e o que é possível aprimorar para os próximos ciclos.

4.2.15 Planejar

A funcionalidade tem como objetivo apresentar para o usuário como foi feito o planejamento de determinada sprint e as características do mesmo.

4.2.16 Ver Issues

Funcionalidade por meio da qual o gerente terá acesso às informações a respeito de todas as issues, estando elas abertas ou fechadas.

4.2.17 Atribuir Issues

Possibilitará ao gerente demandar a um indivíduo a solução de determinada issue.

4.2.18 Pontuar Issues

Utilizando-se desta funcionalidade o usuário poderá atribuir valores às issues de acordo a critérios próprios.

4.2.19 Notificar Usuário

Utilizando Data Science, a função avisa o usuário caso a história do projeto esteja sem alterações por um determinado período de tempo.

4.2.20 Planejar

O aplicativo utiliza Data Science para realizar alguns planejamentos com base no passado do projeto, aprendendo assim com o mesmo.

4.2.21 Acompanhar revisão

Essa funcionalidade dará ao gerente um feedback das issues requisitadas, mostrando aquelas que já foram finalizadas e as que estão em andamento.

4.3. Diagrama de Casos de Uso

5. Visão Lógica

5.1. Visão Geral

5.1.2. Diagrama de Pacotes

O diagrama de pacotes do projeto utiliza a arquitetura MVC(Model-View-Controller), sendo assim, ele é dividido da seguinte forma:

A descrição das pastas expostas se dão da seguinte forma:

App : A pasta nomeada App engloba os principais diretórios do sistema, como por exemplo, os documentos referentes ao MVC - Model, View e Controller.

DB: Abrange os arquivos de configuração do banco de dados, o que inclui a representação das tabelas através das migrations.

Config: Todas as configurações do programa ficarão nesse pasta. Nela ficará a descrição de como o programa irá se comportar.

Test: Haverá três divisões de validação do projeto: da model, view e da controller. Esses testes de validação ficarão nesta pasta.

5.2. Pacotes de Design Significativos no Ponto de Vista da Arquitetura

5.2.1. View(Visão)

A importância desse pacote advém da sua relação direta com o usuário do sistema, isso porque inclui toda a parte visual do mesmo. Em termos de arquitetura, o sistema utilizará o vue que utiliza arquivos com extensão .js, responsáveis por definir a forma como os dados serão expostos.

5.2.2 Model(Modelo)

A pasta denominada modelo trará o conceito de abstração à situação apresentada no mundo real, identificando as entidades a serem utilizadas na aplicação. Ao se tratar da Falko, uma situação em que isso ocorre está na identificação da classe gerente que deverá fornecer nome e Rg como dados de identificação obrigatórios, por exemplo. Além disso, a modelo deverá garantir a comunicação com o banco de dados.

5.2.3 Controller(Controladora)

A controladora será responsável por gerenciar os dados e os comportamentos da aplicação. Ela fará a ligação do modelo com a visão.

5.2.4 Database(Banco de Dados)

Neste pacote haverá as configurações e o estado do banco de dados. Nela estará o responsável por manter, em tabelas, e fazer as alterações dos dados quando necessário.

5.2.5 Test (Teste)

A aplicação de testes durante a implementação de uma aplicação é de extrema importância, por esse motivo, haverá no projeto uma pasta teste a fim de englobar os arquivos desenvolvidos para tal atividade. Isso garantirá, por exemplo, que o gerente não armazene dados incorretos de login, ou que o mesmo não deixe de cadastrar informações relevantes.

6. Desempenho

O sistema, quando integrado com o github, irá coletar um grande volume de dados a serem analisados, dessa forma, a aplicação deve ser capaz de suportá-los e processá-los simultaneamente, estando sujeito à adição de novos dados. O desempenho também dependerá da velocidade da internet do usuário, assim como da capacidade de processamento do aparelho que estará utilizando o sistema através do navegador.

7. Qualidade

O software descrito deve ser compatível com os principais sistemas operacionais, e sua interface de usuário deve ser projetada de maneira que seja autoexplicativa, sendo assim desnecessário treinamento para utilização do sistema.

Falko

Cronograma Versão 3


Acesso à aplicação


Equipe

Release 02

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Sprint 6

Sprint 7

Sprint 8

Sprint 9

Release 01

Gerenciamento do Projeto

Artefatos de Desenvolvimento

Encerramento

Clone this wiki locally