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.

Apresentação em tema: "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."— Transcrição da apresentação:

1 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

2 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/).

3 Análise de qualidade sobre o código original

4 Análise de qualidade O código original não era satisfatório em: Extensibilidade; Reusabilidade; Decomponibilidade; Componibilidade; Compreensibilidade; Continuidade.

5 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;

6 Modelagem do projeto

7 Diagrama de Classes Original Nossa proposta

8 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;

9 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;

10 Diagrama de Sequência Definimos a implementação do sistema de votações baseada no seguinte diagrama de sequência:

11 Diagrama de Sequência O login de usuário, por sua vez, foi implementado seguindo a seguinte modelagem:

12 Qualidade do Sistema Fatores externos

13 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;

14 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);

15 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);

16 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;

17 Qualidade do Sistema Fatores internos

18 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;

19 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;

20 Testes

21 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);

22 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;

23 Conclusão

24 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;

25 Trabalho Final – Técnicas de Construção de Programas Guilherme Bender Jonas Calvi Meinerz Prof. Érika Cota Universidade Federal do Rio Grande do Sul