técnicas de construção de programas trabalho final: sistema de votação para o colegiado do...
TRANSCRIPT
Técnicas de Construção de
ProgramasTrabalho Final: Sistema de Votação para o Colegiado do Depto. de Informática Aplicada do Instituto de Informática.
Guilherme Bender e Jonas Meinerz
Trabalho Final
Trabalho desenvolvido por Guilherme Bender e Jonas Meinerz para a disciplina de Técnicas de Construção de Programas no semestre 2012/2 pela Universidade Federal do Rio Grande do Sul sob tutela da Prof. Erika Cota.
Os diagramas apresentados neste trabalho foram feitos utilizando a ferramenta open source StarUML (staruml.sourceforge.net/).
Os testes caixa-preta foram feitos utilizando o framework gratuito JUnit (junit.org/).
A programação foi realizada com o auxílio da IDE gratuita NetBeans (netbeans.org/).
Análise de qualidade sobre o código original
Análise de qualidade
O código original não era satisfatório em: Extensibilidade;
Reusabilidade;
Decomponibilidade;
Componibilidade;
Compreensibilidade;
Continuidade.
Análise de qualidade Mudanças propostas:
Adicionar ambiente gráfico;
Padronizar código;
Refatorar código repetido;
Documentar o código;
Salvar o estado atual do sistema;
Refatorar classes que não atendem aos princípios de OO;
Refatorar Switch-Cases muito extensos;
Refatorar classes com métodos sem código;
Programar utilizando a técnica TDD;
Tratar exceções;
Mudar o mecanismo de votação;
Modelagem do projeto
Diagrama de Classes
Original Nossa proposta
Diagrama de classes
As diferenças entre o diagrama considerado ideal pelos integrantes desse grupo e o diagrama apresentado no trabalho original eram demasiadas;
Refatorar o código original seria mais custoso e complexo do que construir um sistema completamente novo;
Decidimos que iniciariamos um novo sistema baseado no nosso diagrama de classes;
Diferenças entre o diagrama de classes e a implementação
Na implementação existe uma classe chamada “VotingSystem” que atua como gerenciador das votações e é a única classe com a qual a interface do sistema se comunica;
Modelamos no diagrama “Chief” e “Secretary” como classes derivadas de “FacultyMember”. Na implementação, porém, a única coisa que os distingue é o campo “role”;
Diagrama de Sequência Definimos a implementação do sistema de votações baseada no
seguinte diagrama de sequência:
Diagrama de Sequência O login de usuário, por sua vez, foi implementado seguindo a
seguinte modelagem:
Qualidade do SistemaFatores externos
Qualidade do sistema:Fatores Externos
Buscamos tornar fácil a interação do sistema com o usuário, produzindo uma interface intuitiva (implica em melhor facilidade de uso);
Nenhum processo executado pelo sistema é demorado ou requer qualquer tipo de espera do usuários (implica em melhor velocidade);
Adicionamos o salvamento do estado atual do programa, fazendo com que ele seja útil;
A partir da configuração atual do sistema, seria descomplicado fazê-lo rodar em um servidor web ou sincronizar as informações salvas pelo programa, para que usuários possam votar ao mesmo tempo;
Qualidade do sistema:Fatores Externos
Buscamos assegurar a corretude do programa com testes (automatizados ou não) e de fato o programa realiza as funções definidas em sua especificação;
Para aumentar a robusteza do sistema, tratamos as possíveis exceções e casos de “entradas indevidas”;
O sistema é extensível já que os módulos fazem verificações quanto à consistência dos parâmetros (embora às vezes isso seja redundante) e para adicionar novas funcionalidades basta extender o “gerenciador” (classe VotingSystem);
Qualidade do sistema:Fatores Externos
Não fizemos métodos realmente genéricos porque utilizamos todos os tipos de métodos genéricos cabíveis para montar o nosso sistema. A sua reusabilidade é questionável, visto que poucas coisas poderiam ser generalizadas. Todavia, os métodos que compõem este sistema são métodos reutilizados de bibliotecas confiáveis;
Os pacotes e classes do sistema são facilmente compatíveis com outros métodos pois são relativamente consistentes por si só (“relativamente” pois foram testados por testes de unidade);
Qualidade do sistema:Fatores Externos
Não existe nenhum procedimento que demande muito processamento e todos os procedimentos do sistema são executados em tempo real, portanto, é um sistema eficiente;
O sistema é portável para qualquer ambiente de execução, visto que roda sobre uma máquina virtual;
Qualidade do SistemaFatores internos
Qualidade do Sistema:Fatores Internos Padronizamos a nomenclatura das variáveis, classes e métodos do
código, utilizando somente a lingua inglesa e a mesma estrutura de nomenclatura;
Documentamos os métodos simples por si só, mantendo claro o seu procedimento de execução;
Documentamos os métodos um pouco mais complexos com comentários;
Descrevemos as intenções dos métodos seja por seu nome e explicamos as possibilidades de retorno com um cabeçalho. No cabeçalho, se necessário, é dada uma introdução de como aquele método opera;
Qualidade do Sistema:Fatores Internos Foram executadas refatorações usando o método original como
oráculo;
As funções possuem somente um ponto de retorno;
As cláusulas de fim de laços são bastante claras;
Utilizadas enumerações sempre que adequado;
Testes
Testes
Desenvolvemos vários testes antes mesmo da implementação (para as classes Voting e FacultyMember, por exemplo);
Utilizamos o framework “JUnit”;
O programa interpreta as entradas de I/O como strings, logo, não há problemas de incompatibilidade de tipo a serem testados (e se o programador tentar utilizar um tipo diferente, ocorrerá um erro de compilação);
Testes
Encontramos vários erros nos nossos códigos e também nos equivocamos em certas refatorações, porém a bateria de testes definida tornou fácil a constatação dos mesmos;
Na bateria de testes atual, o programa teve sucesso;
Todavia, execução é comprometida em alguns casos de falha de gravação e leitura de arquivos;
Conclusão
Conclusão
Foi possível implementar tudo que especificamos na etapa 1 do trabalho;
Houveram divergências entre a modelagem (etapas 2 e 3) e a implementação (etapa 4), o que nos fez ver que não é interessante que a modelagem pode nunca ter um formato “final” e que as etapas de modelagem e implementação são mais bem feitas se feitas simultâneamente;
A abordagem orientada a objetos facilitou o desenvolvimento do projeto, embora no início da implementação muitas vezes fazíamos trechos de códigos “estruturados”;
Trabalho Final – Técnicas de Construção de Programas
Guilherme Bender
Jonas Calvi Meinerz
Prof. Érika Cota
Universidade Federal do Rio Grande do Sul