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