Técnicas de Construção
de Programas
Trabalho 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 Sistema
Fatores 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 Sistema
Fatores 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