Carregar apresentação
A apresentação está carregando. Por favor, espere
PublicouRaphaella Hiza Alterado mais de 10 anos atrás
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
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.