Skip to content

Time: FMF

Thiagohnc edited this page Jul 24, 2018 · 64 revisions

A equipe FMF (Fundação Mábio Farinho), popularmente conhecida como Mábio Farinho Foundation, foi fundada em 14 de Março de 2018 por 4 integrantes da UFRJ, com o intuito de desenvolver um software que facilite a manipulação de dados por algumas escolas do Brasil.

Integrantes do time

Lucas Rampazzo, Matheus Panno, Lucca Martins Félix e Thiago Henrique Coelho.

Objetivo

Permitir a customização de relatórios (fonte, layout, etc) criados pela plataforma I-Educar, além de produzir algumas templates para facilitar a customização segundo algum padrão (boletim, lista de chamada, etc).

Tarefa Data de Entrega Link
Reação 1 26/03 Link
Reação 2 28/03 Link
Canvas 26/03 Link
Reação 3 02/04 Link
Mapa mental 02/04 Link
Reação 4 30/05 Link
Reação 5 13/07 Link

Como funcionará a nossa ferramenta:

Visão inicial:

  • Produzir uma ferramenta capaz de gerar relatórios a partir de um banco de dados.
  • Personalizar os relatórios de acordo com o desejo do usuário.
  • Tornar a ferramenta flexível para acessar e gerar relatórios a partir de qualquer banco de dados.

Usuários da ferramenta

  • Usuário Final
    • Escolhe um modelo de relatório preenche a lista de informações requeridas para este modelo escolhido e recebe uma visualização ou gera o arquivo pdf deste relatório.
  • Modelador de relatórios
    • Cria um modelo de relatório ou seleciona um para editar.
    • Tem acesso a uma lista completa com todos os atributos disponíveis.
    • Escolhe um atributo e o posiciona no relatório.
    • Visualiza a lista de informações que será requerida ao usuário final para este modelo de relatório.
  • Especialista em BD
    • Responsável por criar um arquivo de consulta.
    • Para cada modelo, criará um arquivo de consulta necessário para realizá-la.
    • Para cada modelo criará um arquivo que contenha a consulta em SQL que pega os atributos, a partir do arquivo de consulta, necessários para retornar o valor específico da consulta.
  • Designer
    • Responsável por gerar templates HTML dos modelos existentes.
    • Para cada modelo, vários templates podem ser criados.

Glossário

  • Modelo de relatório: Como a ferramenta pode gerar vários tipos de relatórios diferentes, cada um deles será um modelo de relatório, ex: "Boletim", "Lista de Presença", etc.
  • Atributo: é um campo de uma tabela do BD. Na prática, o especialista em banco de dados irá criar um arquivo de consulta, onde ele promete retornar uma lista de atributos a partir de uma lista de parâmetros de consulta. Exemplo: retornar nome, idade e turma de um aluno a partir do número de matrícula.

Banco de Dados

Optamos por utilizar o clássico MySQL juntamente com a ferramenta gráfica MySQK Workbench, para facilitar a interação com e visualização das tabelas. Antes de mais nada, criamos um breve tutorial de como instalar o banco de dados para Linux aqui.

Mini-Minimundo

Nosso banco de dados é bem simples e modela os elementos básicos de um colégio, como alunos, turmas, provas, presenças e professores, bem como suas relações. Abaixo constam os modelos conceitual (entidade e relacionamento), relacional (lógico, com a visão das tabelas) e físico (script de criação das tabelas e população do banco).

OBS.: nossa ideia inicial da estrutura do banco não satisfaz o mínimo necessário para se gerar um relatório (boletim, por exemplo, faltavam algumas informações como semestre, notas, etc.) decentemente. Por conta disso, criamos um novo mini-banco sem formalidade nenhuma para fins de teste de resultados do software.

Modelo Link
Conceitual ER
Relacional Lógico
Físico 1 Script
Físico 2 Script

Consultas

Realizamos, também, algumas consultas teste para termos noção da profundidade das informações do banco.

OBS.: novas consultas foram realizadas com o novo banco.

Conectar Java ao BD

Beleza, agora que temos um banco criado, precisamos utilizá-lo em alguma aplicação, que no caso é uma aplicação Java. Um tutorial ensinando os procedimentos foi feito. Nele, há também um exemplo de consulta feita que é retornada em um result set.

Result Set

Result Set é o tipo de estrutura retornada quando realizamos uma consulta a algum banco de dados em Java. Documentamos como utilizá-lo.

Maravilha! Agora temos um banco pronto para uso. Mas como nós fizemos o uso dele para nossa aplicação? Como citado anteriormente, fazemos uso de um arquivo de consulta. Primeiramente, nós abrimos o arquivo e fazemos um tratamento de String em Java. Mas se os arquivos de consulta são feito previamente, como o Usuário Final teria a liberdade de escolher os parâmetros da consulta? Aqui é explicado como resolvemos isso.

Gerando relatório

Inicialmente, tentamos gerar o PDF utilizando a biblioteca PDF Writer, mas encontramos uma documentação extensa, complexa e nada amigável. Portanto, após apanhar bastante, resolvemos usar o clássico HTML como front-end da aplicação.

Aqui é explicado o passo a passo de alguns fluxos de execução do software.

Ferramentas

Comunicação

Para marcar nossas reuniões, fazer comentários sobre o projeto, comentar sobre a aula, etc, utilizamos o Telegram , mas realizamos nossas reuniões efetivamente no Discord . Lá as sprints eram realizadas, algumas vezes usufruindo do recurso de compartilhamento de tela para não haver falhas de comunicação e, no Trello guardávamos nosso sprint backlog.

Desenvolvimento

A linguagem utilizada foi Java (além de bibliotecas gráficas como JavaFX) com a IDE NetBeans e, para o nosso banco de dados, utilizamos o clássico MySQL e MySQL Workbench . E, por fim, a ferramenta wkhtmltopdf foi crucial para que conseguíssemos converter templates HTML para o formato final PDF.

Sailboat

Como conclusão, resolvemos realizar a retrospectiva do barco à vela.

  • Riscos

    • Não rodar algo efetivamente: uma semana antes da entrega do projeto, nosso software ainda não estava integrado, apesar de os componentes estarem devidamente funcionais e testados, mas a impressão que passa se não houver algo rodando efetivamente é que nada foi feito.
  • Âncoras

    • Desmotivação: com o pouco tempo de desenvolvimento que tínhamos, perdê-lo tentando entender bibliotecas muitas vezes complexas era muito desmotivador.
    • Ferramentas novas: por mais que a documentação de alguma ferramenta estivesse clara, nada é como ter prática de como utilizá-la.
    • Arq Comp e BD: as disciplinas de Arquitetura de Computadores e Banco de Dados possuem uma carga de trabalho muito elevada, requerendo atenção semanal obrigatória, fazendo com que perdêssemos diversas sprints. Compensamos algumas juntando o backlog de duas em uma única sprint.
  • Ventos a favor

    • Luis: nos ajudou profundamente com suas motivações em momentos de desmotivações, se mostrou bastante flexível perante a impasses encontrados pelo grupo e ministrou muito bem o ensino do conteúdo dos métodos ágeis.
    • Competitividade e colaboração: consultar as wikis ou até mesmo pessoalmente outros grupos (fator colaboração) nos deu um norte quando estávamos perdido. Além disso, quando nos sentimos "deixados para trás" no quesito desenvolvimento, o fator competitividade foi crucial para que pudéssemos dar andamento ao projeto.
    • Brainstorm de protótipos: sem dúvida foi o maior momento de produção da equipe, quando percebemos que nos comunicar através de simulações de fluxo de execução com a explicitação do usuário facilitou o entendimento do problema pela equipe.

Nosso objetivo é único e claro: fornecer um software funcional que atendesse às necessidades das escolas públicas. Para isso, organizamos, em ordem temporal, os 3 objetivos que tivemos ao longo do processo, além da descrição do porquê resolvemos abandoná-lo ou adotá-lo.

  • Objetivos

    • iReport secundário: abandonamos rapidamente este objetivo, já que o iReport é um software bem sofisticado e desenvolvido por uma equipe profissional fortemente dedicada.
    • Gerar relatórios: abandonamos este por conta do tempo e não falta de conhecimento, pois com a estratégia do HTML, para gerar uma lista de presença, por exemplo, precisaríamos gerar HTML dinamicamente, o que era inviável para a situação.
    • Gerar um boletim: por fim, nos conformamos em gerar um boletim, cuja estrutura HTML é estática, isto é, uma quantidade fixa de páginas, bastando apenas substituir os parâmetros digitados pelo usuário, mas a estrutura do relatório em si é pré-definida.

Testes

Testes de Unidade

Foram feitos testes em JUnit para os métodos das classes modelo. Para tornar possível o teste de métodos privados, nós criamos métodos públicos específicos para teste (com essa especificação declarada em seu nome, inclusive), que tinham como única funcionalidade retornar os métodos privados.

Testes de Integração

Os testes de integração foram feitos ao longo de todo o desenvolvimento do projeto, sendo intensificados após sua conclusão.

Sprints

Sprint 1

  • Entender o funcionamento de um banco de dados e produzir um banco de dados de teste para ser utilizado durante o desenvolvimento da ferramenta.

Sprint 2

  • Entender como tratar o resultado de uma consulta de SQL em Java, leitura de arquivos em Java e como tratar uma requisição em SQL com passagem de parâmetros pelo usuário.

Relação de pontuação planejada pelo time vs Relação de pontuação real pós-Sprint

Gráfico referente à pontuação real

Sprint 3

Burndown

O que falta fazer? (Backlog)

  • HTML dinâmico para gerar relatórios com número indefinido de linhas
  • Gerar relatórios com mais de uma página
  • Menu de edição de relatórios
  • Estilizar as telas
  • Melhorar a experiência do usuário sobre como o PDF é entregue
  • Gerar pré visualização do PDF
  • Pré visualizar o template na tela de edição
  • Gerenciamento de seção para as escolas (login, senha)
  • Criar uma tela onde o usuário configure a conexão do banco de dados