Síntese dos resultados alcançados

Nos dias de hoje, existe uma grande preocupação com a qualidade do software, sendo a alta complexidade do mesmo considerada um fator indesejável. Sabendo que esta está diretamente ligada à produtividade dos recursos que trabalham na manutenção de software, onde eu me incluo, foi um fator de interesse e uma motivação extra ter realizado o projeto nesta área.

Esta área tem sido alvo de estudos constantes, tendo sido feito um investimento considerável no campo das métricas de avaliação, com o intuito de fornecer ferramentas que auxiliem a análise de complexidade de software, assim como a diminuição de complexidade resultante desse processo.

Estas métricas de avaliação visam proporcionar uma forma de medir a complexidade e também a efetividade de um sistema.

Neste contexto, foi escolhida para este projeto a métrica da complexidade ciclomática, que veio trazer uma abordagem baseada na teoria de grafos e que se adequava bastante bem ao propósito deste projeto. Não sendo este um processo fácil de realizar manualmente quando se está a lidar com software bastante complexo, como é o caso dos produtos da SISCOG, foi necessário implementar uma ferramenta que fizesse esta análise automaticamente e sem grande esforço por parte dos analistas- programadores. Esta ferramenta é apenas para ser usada internamente na SISCOG, não sendo por isso divulgada em código aberto.

Para este projeto foi então necessário realizar um estudo das temáticas inerentes à complexidade ciclomática, nomeadamente os testes de software, no qual foi abordado o papel dos testes na indústria de software e alguns dos seus tipos, como os testes de caixa branca e os testes de caixa preta, assim como uma parte da teoria de grafos que engloba todos os conceitos necessários para a complexidade ciclomática e o papel dos grafos de controlo de fluxo na sua medição.

No que toca à implementação da ferramenta, houve um certo cuidado em tentar modularizar os vários componentes do código, tornando o mesmo mais fácil de manter e compreender. Existem, contudo, ainda alguns componentes que precisam de ser revistos pois apresentam alguma complexidade.

O processo de utilização da ferramente é bastante simples, já que o utilizador apenas tem de invocar uma definição, que automaticamente analisa o código e constrói um relatório com os resultados. Neste relatório, é possível ver pelo grafo onde se concentram as partes mais complexas do

código, podendo depois o utilizador focar aí a sua atenção para proceder à análise na tentativa de reduzir a complexidade.

Nos desafios encontrados durante este projeto, o primeiro a destacar foi a escolha da linguagem LISP, pois era uma linguagem relativamente nova para mim e sendo esta bastante rica e flexível, acabou por colocar vários desafios durante o desenho e implementação da ferramenta.

Outro dos principais desafios deste projeto foi a utilização do code walker, pois a documentação do mesmo é praticamente inexistente, o que levou a que em alguns pontos, fosse necessário recorrer a uma abordagem de tentativa-erro para perceber como este funcionava e o que se podia extrair do mesmo. O code walker trouxe também outros desafios por causa da forma como este lê os vários operadores, macros e todas as definições especificadas no LISP, pois por vezes, este tem um comportamento diferente no caso destas estarem isoladas ou dentro de outras definições.

Na parte de implementação propriamente dita, o maior desafio foi validar a imensidão de caminhos possíveis capazes de ser gerados dentro das definições. Para contornar este problema, mais uma vez, foi necessário recorrer à uma abordagem de tentativa-erro, usando casos cada vez mais complexos para assim tentar cobrir o máximo de caminhos possíveis. Neste âmbito foi também necessário recorrer por vezes à especificaçãoo da linguagem para conseguir compreender a linguagem de uma forma mais completa.

Para avaliar os resultados desta ferramenta analisaram-se três casos de estudos, começando por uma definição pouco complexa e evoluindo posteriormente para casos mais complexos.

Sendo que o primeiro caso de estudo serviu apenas como introdução, pois a sua complexidade era baixa e o segundo caso de estudo foi usado por ser bastante rico sintaticamente e ter já alguma complexidade, o caso que se pode considerar verdadeiramente como o caso de estudo deste projeto é o terceiro.

Este caso foi escolhido por ser uma definição que já sofreu uma reformulação, podendo aí ser comparada a complexidade ciclomática antes e depois dessa intervenção. Se antes, a definição era bastante complexa e como se pode observar pelo seu grafo, existiam diversas condições encadeadas, o depois, reflete uma forte redução da complexidade pois, pelo mais baixo valor da complexidade ciclomática e pelo grafo mais simples, nota-se que já é uma definição mais fácil de compreender e de manter. Sendo que esta definição não sofreu alterações de comportamento durante a reformulação, pode-se concluir que existia uma maior complexidade que era desnecessária e que estava intimamente ligada a decisões tomadas pelo analista-programador.

Com esta análise e analisando todos os outros resultados deste projeto, pode-se concluir que então que software com complexidade ciclomática alta é difícil de compreender, difícil de manter e é geralmente sinal de modularização inadequada ou então da existência de muita lógica inserida na mesma definição.

Acabado este projeto, espera-se que com o uso da ferramenta, os analistas-programadores tenham uma nova ferramenta de suporte durante a análise do código produzido e que a equipa de testes possa utilizar a mesma como apoio na contabilização do número de casos de testes a desenhar.