O arquivo do programa JUDE é para a Plataforma Java (Sun J2SE 1.4 no mínimo), independentemente do sistema operacional. Após descompactá-lo, para rodá-lo em sistemas tipo Unix (qualquer distribuição de Linux, Mac OS X, Solaris, FreeBSD, HP-UX etc.), conceda-se permissão de execução do script jude e o execute. Em sistemas de Redmond, execute o script jude.bat.

E, a propósito de algo que foi comentado pela Prof. Aline, convido os colegas a darem uma olhada em algo que escrevi em meados do ano passado: Curiosidades sobre testes de software.

• Artigo publicado originalmente em simaringa.com

Engenharia de Software

Ele já funciona e calcula corretamente o valor de FP de seu projeto (isto foi conferido pela professora), podendo ser utilizado normalmente, porém com algumas ressalvas. Existe pelo menos um bug conhecido que permanece nessa versão 1.0: ao fechar a janela dos ajustes de complexidade e abri-la novamente, alguma variável ainda não identificada está sendo acumulada, fazendo com que o cálculo seja modificado. Por enquanto, o jeito é clicar em Arquivo > Novo projeto, para zerar tudo.

Ficamos receosos de publicar o código-fonte do programa, por vergonha, pois foi feito com a maior pressa para ser entregue em um dia. Apenas depois foi anunciado que poderia ser entregue posteriormente, mas daí já estava praticamente tudo feito. Mesmo sendo desenvolvido com POG, mudamos de idéia, então distribuímos o programa sob os termos da GNU General Public Licence, versão 3, tal como publicada pela Free Software Foundation.

Download

O programa funciona em qualquer sistema operacional, contanto que esteja instalado o Java Runtime Environment 1.6.0 (“Java 6 JRE”) ou mais recente.

Binários (Java bytecodes)

Java Web Start

É a maneira mais ágil de executar o programa, se o ambiente de sua máquina estiver devidamente configurado. Clique aqui e mande abrir com o Java Web Start.

A maneira mais ágil de executar o programa seria clicar neste link, porém o servidor onde o arquivo se encontra ainda não está configurado corretamente para associar o arquivo com o Java Web Start. Contudo, ainda é possível utilizá-lo: basta salvar o pequeno arquivo em sua máquina como PontosPorFuncao.jnlp e abri-lo com o Java Web Start. Uma alternativa ainda pode ser, através do seu terminal de comandos (p. ex., se for no Gnome: Aplicações / Acessórios / Terminal; se for no Windows: Iniciar / Executar / cmd), digitar:
javaws http://blog.daltux.com/dist/PontosPorFuncao/launch.jnlp

Tradicional (JAR)

• PontosPorFuncao_1.0_dist.7z – 179kB, comprimido com o 7-zip.

Se o seu ambiente de trabalho estiver devidamente configurado para abrir arquivos JAR com a Máquina Virtual Java, abra o diretório descompactado. A partir daí, geralmente, basta um clique duplo sobre o ícone do arquivo launch.jar para executar o programa. Contudo, se isso não ocorrer, verifique com seu distribuidor do sistema operacional como fazer isso.

Código-fonte

• PontosPorFuncao.tar.gz – 366kB, projeto para NetBeans 6.

De acordo com Roger S. Pressman¹, o teste de software pode tão somente mostrar a existência de bugs, mas nunca pode garantir que eles não existem. Mais grave que isso: “Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto” e “Um teste bem-sucedido é aquele que revela um erro ainda não descoberto”. Os objetivos dos testes na realidade devem ser bem contrários ao “ponto de vista comumente defendido em que um teste bem-sucedido é aquele em que nenhum erro é encontrado”.

Eis um parágrafo bastante elucidativo do mesmo autor:

À medida que os resultados de teste são reunidos e avaliados, uma indicação qualitativa da qualidade e da confiabilidade do software começa a vir à tona. Se erros graves, que exijam modificação de projeto, forem encontrados com regularidade, a qualidade e a confiabilidade do software são suspeitas, e testes adicionais são indicados. Se, por outro lado, as funções do software parecerem estar funcionando adequadamente e os erros encontrados forem facilmente corrigíveis, pode-se tirar uma entre duas conclusões: (1) a qualidade e a confiabilidade do software são inaceitáveis; ou (2) os testes são inadequados para revelar erros graves! Finalmente, se a atividade de teste não descobrir nenhum erro, não há dúvida de que a configuração de teste não foi suficientemente elaborada e que erros estão escondidos no software. Esses defeitos serão por fim descobertos pelos usuários e corrigidos pelo desenvolvedor durante a fase de manutenção (quando o custo por correção pode ser de 60 a 100 vezes o custo por correção durante a fase de desenvolvimento).

O mais curioso de tudo é que Pressman não chega a esse ponto mas, se os testes devem encontrar erros, podemos deduzir que os bugs são inerentes ao software. Então, enquanto alguns desenvolvedores sentem-se frustrados ao ter que fazer testes e principalmente ao constatar erros, devemos sempre considerar a atividade de teste como algo construtivo. Afinal, embora não prove que o software seja desprovido de erros, a condução de testes auxilia muito para indicar a qualidade do software como um todo, se cumpre as especificações e requisitos de desempenho e confiabilidade.

¹ PRESSMAN, Roger S. Engenharia de software. Trad. José Carlos Barbosa dos Santos. São Paulo: Pearson Makron Books, 1995. p. 786-790.

Post scriptum (10 mai. 2008)

Eis um engraçado post sobre o assunto, de Nerdson não vai à escola: “Testem, macacos, testem!”