SOFTWARE PARA CÁLCULO DA COMPLEXIDADE CICLOMÁTICA EM CÓDIGO-FONTE PL/SQL

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO BACHARELADO SOFTWARE PARA CÁLCULO DA COMPLEXIDADE CICLOMÁTICA EM CÓDIGO-FONTE PL/SQL KARINE TREVISANI CUNHA BLUMENAU /1-27

2 KARINE TREVISANI CUNHA SOFTWARE PARA CÁLCULO DA COMPLEXIDADE CICLOMÁTICA EM CÓDIGO-FONTE PL/SQL Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciências da Computação Bacharelado Prof. Alexander Roberto Valdameri, Mestre - Orientador BLUMENAU /1-27

3 SOFTWARE PARA CÁLCULO DA COMPLEXIDADE CICLOMÁTICA EM CÓDIGO-FONTE PL/SQL Por KARINE TREVISANI CUNHA Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Prof. Alexander Roberto Valdameri, Mestre - Orientador, FURB Prof. Everaldo Artur Grahl, Mestre FURB Prof. Ricardo Alencar de Azambuja, Mestre FURB Blumenau, Junho de 2006.

4 Dedico este trabalho à minha família e a todos os amigos verdadeiros, que de alguma maneira estiveram presentes e souberam me compreender durante todo este período.

5 AGRADECIMENTOS Primeiramente à Deus, sem o qual com certeza esta caminhada não seria possível. À minha maravilhosa família, que sempre foi o alicerce da minha vida, pelo apoio e pelas cobranças contínuas. Ao meu querido esposo Manoel Debert, por toda compreensão e paciência, e por sempre estar ao meu lado, disposto a me animar para seguir meus objetivos. Aos meus colegas de trabalho que foram essenciais para sanar minhas dúvidas, questionar meus pontos de vista e estiveram sempre dispostos a me ajudar. Ao meu orientador, Alexander, pelo apoio e dedicação, que foram subsídios primordiais para a conclusão deste trabalho.

6 O degrau de uma escada não serve simplesmente para que alguém permaneça em cima dele, destina-se a sustentar o pé de um homem pelo tempo suficiente para que ele coloque o outro um pouco mais alto. (Thomas Huxley)

7 RESUMO Este trabalho apresenta o desenvolvimento de um aplicativo que analisa códigos-fonte escritos na linguagem PL/SQL e calcula a métrica da complexidade ciclomática. Esta métrica ajuda a avaliar o grau de manutenibilidade dos códigos, ou seja, o quão fácil ou complexa é a manutenção deste código. A complexidade ciclomática faz seu cálculo baseado na quantidade de caminhos linearmente independentes que podem ser percorridos ao longo do código. Quanto maior o resultado da métrica, mais complexo é o código analisado e mais difícil é realizar manutenções neste código. Palavras-chave: Complexidade ciclomática. Manutenibilidade. PL/SQL.

8 ABSTRACT This paper presents the development of an application that it analyzes source-code written in the PL/SQL language, and it calculates the measure of its cyclomatic complexity. This measure helps us to evaluate the level of code maintainability, that is, how easy or complex it is to maintain this code. The calculation of the cyclomatic complexity is based on the amount of linearly independent paths the code can be run through. The greater the measure is, the greater is the complexity of the code analyzed and the greater is the effort to maintain this code. Key-words: Cyclomatic complexity. Maintainability. PL/SQL Language.

9 LISTA DE ILUSTRAÇÕES Figura 1 - Divisão das métricas segundo Sommerville...17 Figura 2 - Divisão das métricas segundo Pressman...17 Figura 3 - Notação de grafo de fluxo...25 Figura 4 - Ramos, nós e regiões...25 Figura 5 - Condição composta...26 Figura 6 - Grafo do programa exemplo...29 Figura 7 - Diagrama de caso de uso...38 Figura 8 - Diagrama de classes...40 Figura 9 - Diagrama de atividades...41 Figura 10 - Tela Principal...49 Figura 11 - Tela de Resultado...49 Figura 12 - Opção de ajuda na versão console...50 Figura 13 - Resultado na versão console...51

10 LISTA DE QUADROS Quadro 1 - Principais operadores básicos...24 Quadro 2 - Medidas básicas da Ciência do Software...24 Quadro 3 - Fórmula da complexidade ciclomática...27 Quadro 4 - Escala de complexidade ciclomática...28 Quadro 5 - Programa exemplo em PL/SQL...29 Quadro 6 - Caminhos possíveis do exemplo...30 Quadro 7 - Estrutura básico de códigos PL/SQL...31 Quadro 8 - Caracteres da linguagem PL/SQL...32 Quadro 9 - Exemplo IF simples...33 Quadro 10 - Exemplo IF - THEN - ELSE...33 Quadro 11 - Exemplo IF - THEN - ELSIF...33 Quadro 12 - Exemplo LOOP básico...34 Quadro 13 - Exemplo LOOP FOR...34 Quadro 14 - Exemplo LOOP WHILE...35 Quadro 15 - Cenários do Caso de Uso...39 Quadro 16 - Validação dos arquivos...43 Quadro 17 - Leitura recursiva de diretórios...44 Quadro 18 - Limpeza dos comentários...45 Quadro 19 - Uso do método StringTokenizer...46 Quadro 20 - Lógica de subprogramas...47 Quadro 21 - Cálculo da complexidade ciclomática...48

11 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO MOTIVAÇÃO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA MÉTRICAS DE SOFTWARE Classificação Métricas de Produto TESTE DE SOFTWARE Tipos de teste MANUTENIBILIDADE Ciência do Software NOTAÇÃO DE GRAFO DE FLUXO COMPLEXIDADE CICLOMÁTICA Exemplo aplicado A LINGUAGEM PL/SQL A linguagem TRABALHOS CORRELATOS DESENVOLVIMENTO DO SOFTWARE REQUISITOS PRINCIPAIS DO PROBLEMA TRABALHADO ESPECIFICAÇÃO DO SOFTWARE Diagrama de Caso de Uso Diagrama de Classes Diagrama de Atividades IMPLEMENTAÇÃO DO SOFTWARE OPERACIONALIDADE DA IMPLEMENTAÇÃO RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES...54 REFERÊNCIAS BIBLIOGRÁFICAS...55 ANEXO A Códigos utilizados para exemplificar o funcionamento do software...57

12 11 1 INTRODUÇÃO Quando uma empresa de desenvolvimento de software ou uma equipe atinge uma determinada maturidade, é imprescindível procurar uma forma de medir esta maturidade, seja para o desenvolvimento, seja para a manutenção dos módulos dos sistemas. Esta é uma das premissas de se realizar medições. O objetivo principal de realizarmos medições no tocante ao desenvolvimento de um software é obter níveis cada vez maiores de qualidade, considerando o projeto, o processo e o produto, visando à satisfação plena dos clientes ou usuários, a um custo economicamente compatível. (FERNANDES, 1995, p. 25). No campo da Engenharia de Software, estas medições são chamadas métricas. As métricas são importantes para estimar projetos, melhorar os esforços de desenvolvimento e selecionar ferramentas, entre outros. Segundo Möller e Paulish (1993, p. 15), os princípios para a origem da aplicação de métodos quantitativos para o desenvolvimento de software foram estabelecidos em Havia quatro tendências preliminares desta tecnologia que ocorreram naquele tempo e que evoluíram para as práticas das métricas utilizadas hoje, as quais são: a) estimativa de custo de um projeto de software: desenvolvida em meados de 1970, sua aplicação visa estimar o trabalho e o tempo gastos para se desenvolver um software, baseando-se em fatores como a quantidade de linhas de código necessárias para a implementação; b) garantia da qualidade do software: visa à identificação de informações que não estão disponíveis durante os vários ciclos de vida de um software; c) métricas da complexidade do software: surgiram em meados de 1970, e se caracterizam por serem fáceis de obter, pois podem ser extraídas por meios automatizados; d) processo de desenvolvimento do software: à medida que os projetos tornaram-se

13 12 maiores e mais complexos, surgiu a necessidade de controlar o desenvolvimento dos mesmos. O processo de controle incluiu a definição do ciclo de vida do projeto, com maior ênfase no gerenciamento e controle dos recursos utilizados. Os profissionais da época, a partir do aparecimento destas tendências, começaram então a utilizar as métricas com o propósito de melhorar o processo de desenvolvimento do software. A partir de então, as métricas passaram a ser mais utilizadas no gerenciamento de projetos. Conforme DeMarco (1989, p. 3), não se pode controlar o que não se pode medir. Porém, este controle depende de alguns pré-requisitos importantes que devem ser observados (FERNANDES, 1995, p. 81): a) os objetivos que se desejam atingir devem estar bem definidos, e a partir de então definir qual a melhor métrica para atingir estes objetivos; b) as métricas escolhidas devem ser simples de entender; c) as métricas devem ser objetivas, visando minimizar o julgamento pessoal na análise dos resultados; d) as métricas devem ser efetivas ao custo, ou seja, o valor da informação obtida com o emprego da métrica deve ser maior do que o custo para coletar, armazenar e calcular as métricas; e) as métricas devem ser informativas, a ponto de fornecerem dados que possibilitem avaliar acertos e ações, ocorridas no passado, no presente ou no futuro. Neste sentido, este trabalho aborda uma métrica que tem como objetivo mensurar parcialmente a manutenibilidade dos códigos-fonte desenvolvidos na linguagem Procedural Language/Struct Query Language (PL/SQL). Manutenibilidade é a métrica que caracteriza a facilidade de modificação ou adaptação de um software. A métrica da manutenibilidade é muito importante, pois a manutenção de sistemas tem sido um dos grandes desafios da

14 13 engenharia de software, pelo fato de corresponder a até 70% dos custos de um sistema (GRUBB, 2003 apud WEBSTER et al, 2004). Conforme Webster et al. (2004, p. 1), embora a manutenção de sistemas seja uma das atividades mais crítica e longa do ciclo de vida do software poucos estudos foram realizados nesta área. Há algumas métricas que se propõe medir a manutenibilidade de um código como um de seus resultados. Um exemplo é a métrica de Análise por Pontos de Função (FPA). Nesta técnica o tamanho de um software é medido por fatores externos ao código como: tamanho do processamento e complexidade técnica dos fatores de ajuste. O cálculo é efetuado a partir dos pontos de função, que são os dados ou transações do sistema. Porém, segundo Ambler (1998, p. 184), A contagem de pontos é uma habilidade que poucas pessoas possuem, e é um processo que consome tempo, até mesmo para pessoas que têm experiência nisto. 1.1 OBJETIVOS DO TRABALHO O objetivo deste trabalho é desenvolver um aplicativo para cálculo da métrica de complexidade ciclomática de códigos-fonte PL/SQL. Os objetivos específicos do trabalho são: a) identificar as quebras de fluxo dos códigos-fonte PL/SQL para bancos de dados Oracle; b) gerar o resultado da métrica acompanhado de uma explicação sobre o nível da complexidade do software. 1.2 MOTIVAÇÃO Atualmente, cada vez mais empresas, tanto de desenvolvimento, quanto empresas que

15 14 possuem uma área de desenvolvimento de software estão buscando uma maneira de mensurar os códigos-fonte de seus aplicativos. Elas já assumiram o fato de que para prover software de qualidade, estes devem passar por uma série de verificações. Entre estas verificações está o nível de manutenibilidade. Considerando a importância da manutenção e os poucos trabalhos realizados nesta área, este trabalho implementa um aplicativo que calcula uma das métricas mais específicas para manutenibilidade: a complexidade ciclomática. Este aplicativo analisa as informações de códigos-fonte codificados em PL/SQL, que embora não seja uma linguagem orientada à objetos (OO), ainda é muito utilizada pelas empresas. Em pesquisa realizada foram encontrados trabalhos com características similares para as linguagens Delphi e Java. 1.3 ESTRUTURA DO TRABALHO No primeiro capítulo apresenta-se a contextualização do tema proposto, através de uma descritiva introdutória do trabalho. Também são apresentados os objetivos principais e específicos, bem como a motivação para a realização deste. O segundo capítulo mostra a fundamentação teórica em que o trabalho está baseado, abordando em seus sub-capítulos assuntos como: métricas de software, manutenibilidade, notação de grafo de fluxo, teste de software, complexidade ciclomática, linguagem PL/SQL, além de citar os trabalhos correlatos a este. Na seqüência, o terceiro capítulo apresenta a especificação e implementação da ferramenta. São apresentados também os requisitos necessários, a operacionalidade do sistema e os resultados obtidos. Por fim, as conclusões obtidas com a execução deste trabalho, bem como sugestões para a continuidade do mesmo, são apresentadas no último capítulo.

16 15 2 FUNDAMENTAÇÃO TEÓRICA Este capítulo apresenta a revisão bibliográfica sobre os temas abordados neste trabalho. Destacam-se as métricas de software, métricas de produto, teste de software, manutenibilidade, notação de grafo de fluxo, complexidade ciclomática e a linguagem PL/SQL. 2.1 MÉTRICAS DE SOFTWARE As métricas de software podem ser definidas como métodos de determinar quantitativamente a extensão em que o projeto, o processo e o produto de software têm certos atributos. Isto inclui a fórmula para determinar o valor da métrica como também sua forma de apresentação e as diretrizes de utilização e interpretação dos resultados obtidos no contexto do ambiente de desenvolvimento de software. (FERNANDES, 1995, p. 81). Em termos gerais, a métrica de um software propõe-se a obter um valor numérico para alguns atributos de um produto ou de um processo do desenvolvimento deste software. Tendo estes valores, torna-se fácil efetuar comparações entre eles, ou com algum padrão existente, podendo-se assim tirar conclusões sobre a qualidade do produto ou processo analisado. Desde 1970 até os dias atuais, o processo de medição de software vem aprimorando-se. À medida que as métricas eram calculadas com base nos softwares, foi verificada a necessidade de controlar este processo. Foi então que além da aplicação da métrica, estabeleceu-se também o gerenciamento da mesma. Este gerenciamento, segundo McDermid (1993, p. 12/5), é dividido em três partes interligadas que são: a) planejamento da medição: esta etapa visa a elaboração de planos para criar e aplicar, bem como, especificar a maneira de validação e como será garantida a qualidade dos resultados; b) organização da execução da medição: esta etapa busca prover recursos humanos,

17 16 treinamento, instrumentos, acomodações e ambiente para que a medição possa ser realizada; c) controle e supervisão da execução da medição: visa o gerenciamento dos recursos e pessoal, bem como garantir que o processo esteja de acordo com o plano proposto. Além das premissas de como gerenciar o processo de coleta de métricas, é importante que a métrica escolhida seja uma métrica útil. Uma métrica útil é reconhecida por quatro características básicas: ela é mensurável, independente, explicável e precisa. a) mensurável: quando não houver uma indicação mensurável, obviamente, o indicador não pode ser qualificado como métrico; b) independente: indica que não sofre influência consciente da equipe do projeto; c) explicável: para que seus resultados possam ser analisados por todos da mesma maneira, sem permitir duplas interpretações; d) precisa: a ponto dos resultados gerarem a confiança necessária para que sejam tomadas ações para a melhoria do software analisado Classificação Conforme Sommerville (2003, p. 468), as métricas podem ser de controle ou preditivas. As métricas preditivas geralmente estão atreladas ao produto, exemplo: a complexidade ciclomática de um módulo; enquanto as métricas de controle dizem respeito ao processo de software, como por exemplo: esforço (homens/dia). Tanto as métricas de controle, quanto as preditivas podem influenciar na tomada de decisões sobre o gerenciamento, como mostra a figura 1.

18 17 Processo do Software Produtos de software Medições de controle Medições preditivas Decisões de gerenciamento Fonte: adaptado de Sommerville (2003). Figura 1 - Divisão das métricas segundo Sommerville Quando Pressman (1995, p. 61) cita as categorias das métricas, ele as divide conforme a figura 2. Técnicas de Qualidade de Produtividade Orientadas ao Tamanho Orientadas à Função Orientadas ao Ser Humano Fonte: adaptado de Pressman (1995). Figura 2 - Divisão das métricas segundo Pressman a) de produtividade: concentram-se na saída do processo de engenharia; b) de qualidade: são coletadas antes que o software seja entregue ao cliente, para verificar o quanto dos requisitos definidos foi atendido; c) técnicas: concentram-se nas características do software para proporcionar maior qualidade do projeto e do código;

19 18 d) orientadas ao tamanho: calculam medições diretas do software e do processo pelo qual ele é desenvolvido; e) orientadas à função: são medidas indiretas do software e do processo de desenvolvimento; f) orientada ao ser humano: compilam informações sobre a maneira do desenvolvedor trabalhar e suas percepções sobre a eficiência das ferramentas e métodos. Ainda em termos de classificação, Kan (1995, p. 83) fala que as métricas de software podem ser divididas em três categorias: a) métricas de produto: podem ser obtidas a partir do próprio produto, como tamanho, complexidade e nível de qualidade; b) métricas de processo: quando utilizadas podem ajudar na melhoria do processo ainda na fase de desenvolvimento ou de manutenção. Exemplo: a eficiência da detecção de erros durante a fase de desenvolvimento; c) métricas de projeto: buscam medir as características da fase de execução do projeto, como o número de programadores e a produtividade, por exemplo. Dentre esta gama de divisões e classificações, a complexidade ciclomática, foco deste trabalho, segundo Sommerville (2003, p. 472), está classificada como uma métrica de produto Métricas de Produto Conforme já foi mencionado, as métricas de produto são métricas baseadas no próprio software. Também conhecidas como métricas de qualidade, elas têm como objetivo definir os requisitos, prever e controlar a qualidade do produto.

20 19 As métricas de produto podem ser divididas em duas classes (SOMMERVILLE, 2003): métricas dinâmicas, que são coletadas a partir da execução de um programa e não são abordadas neste trabalho, e métricas estáticas, que são coletadas a partir das representações do software, como o programa e a documentação. Esta última ajuda a medir a complexidade e a facilidade de manutenção e compreensão de um software. Algumas métricas estáticas de produto propostas por Sommerville (2003, p. 472) são: a) fan-in/fan-out: fan-in calcula o número de funções que chamam outras funções, fan-out calcula o número de funções que são chamadas por uma determinada função; b) tamanho do código: é a medida do tamanho do código de um software; c) complexidade ciclomática: é a medida da complexidade de controle de um determinado software; d) extensão dos identificadores: é a medida do comprimento médio dos identificadores distintos de um programa; e) profundidade das declarações condicionais aninhadas: é a medida da profundidade das declarações da condição de teste (IF) aninhadas em um programa; f) índice fog: é a medida do comprimento médio de palavras e sentenças em documentos. 2.2 TESTE DE SOFTWARE A crescente visibilidade do software como um elemento do sistema e os custos de atendimento associados com uma falha são forças motivadoras para o teste rigoroso e bem planejado. Não é raro que uma organização de desenvolvimento de software gastar entre 30 a 40% do esforço total do projeto no teste. (PRESSMAN, 2002, p. 429). O processo de teste de software, ou verificação e validação como citam alguns autores, tem o objetivo de mostrar se o software está de acordo com as especificações e se ele realiza

21 20 todas as funções solicitadas pelo cliente de modo satisfatório. Este processo, não deve ser incluído apenas no final do desenvolvimento, ele deve vir acompanhando cada uma das etapas, por meio de inspeções e revisões do código. E sua complexidade tende a aumentar proporcionalmente ao tamanho do projeto e do número de pessoas envolvidas no desenvolvimento. Segundo Wikipédia (2006), as falhas nos softwares são inevitáveis, e significa dizer que o funcionamento do programa não está de acordo com o esperado. Quando ocorre um erro, as causas podem ser as mais diversas, como por exemplo: a) especificação errada ou incompleta; b) especificação com requisitos impossíveis de serem implementados, devido a limitações de hardware ou software; c) erro do programador ao interpretar a especificação; d) simples desatenção Tipos de teste Como é comum o acontecimento de erros, cabe ao responsável pela qualidade do software escolher a melhor maneira de detectar e corrigir estes erros. Sommerville (2003, p. 377) sugere algumas técnicas de teste, as quais são divididas em três tipos: testes para detecção de defeitos, testes de integração e testes orientados à objetos. Neste trabalho são detalhados os testes para detecção de defeitos. Os testes para detecção de defeitos têm por finalidade encontrar defeitos latentes em um sistema antes de ele ser entregue, ou seja, tem por objetivo fazer com que o sistema opere de modo incorreto, de modo a expor um defeito existente. Isto enfatiza um fato importante sobre os testes e demonstra a presença e não a ausência de defeitos no programa.

22 21 A seguir são apresentados dois testes de detecção de defeitos, segundo Pressman (2002, p. 436): a) teste de caixa branca: por vezes chamado teste caixa de vidro, utiliza a estrutura de controle do projeto procedimental para derivar os casos de teste. Estes casos gerados pelo teste de caixa branca permitem que todos os caminhos independentes de um módulo tenham sido testados pelo menos uma vez, exercita todas as decisões lógicas e executa todos os ciclos em seus limites; b) teste de caminho básico: é uma das técnicas de teste de caixa branca, que permite ao projetista de casos de teste originar uma medida da complexidade lógica de um projeto procedimental (Pressman, 2002, p. 437) e utilizar esta medida como guia para definir um conjunto básico de caminhos de execução. Neste contexto, uma das métricas de software que ajuda a originar esta medida de complexidade é a complexidade ciclomática, foco deste trabalho. 2.3 MANUTENIBILIDADE A manutenibilidade de um software pode ser definida como o processo de modificação de um produto de software ou sistema após sua implantação, com o intuito de adaptá-lo, melhorá-lo ou corrigi-lo. Pode ser quantificada, geralmente, como o tempo requerido para revisar um software a fim de encontrar e eliminar um erro. A norma ISO/IEC (ABNT, 1996) classifica os atributos de qualidade de software em seis características, dentre elas está a manutenibilidade: a) funcionalidade: refere-se à existência de um conjunto de funções que satisfazem necessidades e suas propriedades específicas. Tem como subcaracterísticas: adequação, acurácia, interoperabilidade, conformidade e segurança de acesso;

23 22 b) confiabilidade: capacidade de o software manter seu nível de desempenho, sob condições estabelecidas, por um determinado tempo. Tem como subcaracterísticas: maturidade, tolerância a falhas, recuperabilidade e conformidade; c) usabilidade: esforço necessário ao uso do produto de software, bem como o julgamento individual de tal uso, por um conjunto de usuários. Suas subcaracterísticas são: inteligibilidade, apreensibilidade, operacionabilidade, atratividade e conformidade; d) eficiência: relacionamento entre o nível de desempenho do software e a quantidade de recursos utilizada, sob condições estabelecidas. Suas subcaracterísticas são: comportamento em relação ao tempo, comportamento em relação aos recursos e conformidade; e) manutenibilidade: esforço necessário para fazer modificações específicas no software. Tem como subcaracterísticas: analisabilidade, modificabilidade, estabilidade, testabilidade e conformidade; f) portabilidade: habilidade do software para ser transferido de um ambiente para outro. Suas subcaracterísticas são: adaptabilidade, capacidade de instalação, conformidade, capacidade de substituição e coexistência. Dentre as características citadas, a manutenibilidade tem um foco especial neste trabalho, pois a métrica implementada servirá como base para a avaliação desta característica. As métricas que se propõe a medir a manutenibilidade são muito importantes, pois segundo Grubb (2003 apud WEBSTER et al, 2004), a manutenção de sistemas tem sido um dos grandes desafios da engenharia de software e pode chegar a representar ¾ do custo total do sistema. Uma forma de minimizar os custos com manutenção após o desenvolvimento é controlar a manutenibilidade durante o desenvolvimento. [...] E a forma usual de medir características específicas de um projeto de software é a utilização de métricas integradas ao processo de desenvolvimento. (SOUZA, 2005, p. 9, grifo nosso).

24 23 Atualmente, existem alguns modelos para medição da manutenibilidade de um software. Muitos deles envolvem aspectos da engenharia de software, como a qualidade e especificação dos requisitos, rastreabilidade e complexidade do sistema. A este último dá-se maior ênfase, tendo em vista que a maior parte do tempo de manutenção é utilizado na compreensão do software (GIBSON, 1989 apud SOUZA, 2005, p. 10). Algumas métricas já existentes buscam focar seus cálculos na medição da manutenibilidade, sendo a ciência do software e a complexidade ciclomática as mais utilizadas. Porém, a dificuldade não está em encontrar estas métricas, mas sim, em selecionar a mais adequada às necessidades do projeto. Por isso é importante conhecer as premissas e os resultados obtidos com cada uma destas métricas Ciência do Software A métrica de Halstead (1977 apud BRUSAMOLIN, 2004, p. 13), também conhecida como ciência do software, foi elaborada por volta de 1977 e ainda hoje é utilizada para se derivar a manutenibilidade do software. A ciência do software usa um conjunto de medidas primitivas que pode ser derivado depois que o código é gerado, ou estimado assim que o projeto está completo. Para compor estas medidas, Halstead, em seus estudos, considera que qualquer código é composto de operadores e operandos: a) operadores: - básicos: os quais os principais são apresentados no quadro 1, - palavras-chave, - especiais: nomes de procedimentos e funções; b) operandos: identificadores de variáveis e constantes

25 24 Operadores Básicos - Operador de subtração, que é usado para subtrair um número de outro. + Operador de adição, que é usado para somar dois valores. / Operador de divisão. * Operador de multiplicação. ** Operador de exponenciação. Ele eleva um número à potência de outro. = Operador de igualdade. Ele compara dois valores para saber se eles são idênticos := Operador de atribuição. < Operador menor do que. Verifica se um valor é menor do que outro Operador menor do que ou igual. Verifica se um valor é menor do que ou igual a <= outro. > Operador maior do que. Verifica se um valor é maior do que outro. Operador maior do que ou igual. Verifica se um valor é maior do que ou igual a >= outro. Operador de desigualdade. Ele compara dois valores para saber se eles são <> idênticos 1995, p. 757). Quadro 1 - Principais operadores básicos Baseado nesta teoria são geradas as medidas mostradas no quadro 2 (PRESSMAN, n1 é o número de operadores distintos. n2 é o número de operandos distintos N1 é o número total de ocorrências de operadores. N2 é o número total de ocorrências de operandos. Quadro 2 - Medidas básicas da Ciência do Software A partir destas medidas Halstead desenvolveu expressões para o cálculo do comprimento global do programa, o volume mínimo potencial para um algoritmo, o volume real, o nível do programa, o nível da linguagem, entre outras medidas. 2.4 NOTAÇÃO DE GRAFO DE FLUXO Antes de efetuar a análise mais detalhada do cálculo da complexidade ciclomática, uma das métricas citadas no capítulo 2.3, faz-se necessária uma pequena introdução da notação de grafo de fluxo. Em se tratando da representação do módulo de um software através de grafos, existe

26 25 uma notação específica para cada estrutura lógica de controle, como mostrado na figura 3 (PRESSMAN, 2002, p. 438). Fonte: adaptado de Pressman (2002). Figura 3 - Notação de grafo de fluxo Estas estruturas quando utilizadas em conjunto, podem apresentar nós, regiões e ramos, como mostra a figura 4. Ramo 1 2 Nó 4 R2 3 6 R3 5 R1 Região 7 R4 8 9 Fonte: adaptado de Pressman (1995). Figura 4 - Ramos, nós e regiões Um nó representa uma ou mais instruções procedimentais. Os arcos do grafo,

27 26 denominados ramos, representam o fluxo de controle e as áreas delimitadas pelos ramos e nós, são denominadas regiões. Quando são encontradas condições compostas em um processo procedimental, a geração de um grafo torna-se um pouco mais complicada (PRESSMAN, 1995, p. 796). Uma condição composta ocorre quando um ou mais operadores booleanos (OR, AND...) são utilizados em uma instrução de condição. Cada nó que contém uma condição é denominado nó predicativo, e é caracterizado por possuir um ou mais ramos que se originam nele, conforme figura 5. Fonte: adaptado de Pressman (2002). Figura 5 - Condição composta 2.5 COMPLEXIDADE CICLOMÁTICA Esta métrica foi desenvolvida por McCabe (1976 apud SOMMERVILLE, 2003, p. 384) para indicar a testabilidade e manutenibilidade de um software, medindo os caminhos linearmente independentes do código fonte. É a métrica mais largamente utilizada das métricas de produto da classe estática (VANDOREN, 1997). Esta métrica tem como resultado um único número que pode ser comparado com o resultado de outros programas, independente da linguagem em que foram codificados, apesar disso, geralmente é utilizada

28 27 em conjunto com outras métricas (MCCABE, 1994 apud VANDOREN, 1997). O resultado desta métrica define o número de caminhos independentes no conjunto base de um programa e nos fornece um número mínimo de testes que devem ser realizados para que todos estes caminhos tenham sido testados pelo menos uma vez. Um caminho independente é qualquer caminho ao longo do módulo que apresenta pelo menos uma nova condição ou um novo conjunto de comandos de processamento (PRESSMAN, 2002, p. 438). Estes caminhos podem ser gerados a partir da representação de um grafo fortemente conectado com uma única entrada e uma única saída. O valor da complexidade ciclomática (CC) de um dado grafo pode ser calculada conforme é mostrado no Quadro 3. CC = E N + p onde: E = número de arestas do grafo; N = número de nós do grafo; p = número de componentes conectados ao grafo, ou seja, o número de entradas e saídas do fluxo de execução. Fonte: Vandoren (1997) Quadro 3 - Fórmula da complexidade ciclomática Pela regra da métrica, só podem existir uma única entrada e uma única saída, portanto p, logicamente, é sempre igual a 2. Por isso, muitos autores costumam apresentar a fórmula desta maneira: CC = E N + 2. No que diz respeito à testabilidade de um software, depois de encontrar o valor da complexidade ciclomática para um software, o próximo passo será criar casos de teste para testar todos os caminhos, ou seja, o número mínimo de casos de teste requerido para testar todos os caminhos do programa é igual a complexidade ciclomática. (SOMMERVILLE, 2003, p. 385). No aspecto da manutenibilidade do software é interessante que após o cálculo seja observado o Quadro 4, para saber um parecer sobre a complexidade daquele código-fonte.

29 28 Neste quadro é apresentada uma escala para a medição. Complexidade Ciclomática Avaliação do Risco 1-10 programa simples, sem muito risco programa mais complexo, risco moderado programa de risco elevado maior que 50 programa incompreensível, risco muito alto. Fonte: Vandoren (1997) Quadro 4 - Escala de complexidade ciclomática Em resumo, uma complexidade ciclomática baixa indica que o programa é de fácil compreensão e que uma alteração que se faça necessária tem um risco mais baixo em relação a programas mais complexos. A complexidade ciclomática pode ser aplicada em diversas áreas como na análise do nível de risco ou do crescimento do mesmo durante o desenvolvimento. Na análise dos riscos, durante o processo de manutenção, pode ser utilizada no planejamento dos testes do software. Neste caso, uma complexidade alta, requer grande número de testes. O valor da complexidade pode ser diminuído se o módulo for quebrado em sub-módulos menores, menos complexos Exemplo aplicado No quadro 5, é apresentado um exemplo simples de um trecho de um programa codificado em PL/SQL. Este trecho mostra a leitura de uma tabela do banco de dados através de um cursor, e conforme o código do departamento, o número do malote é alterado. DECLARE V_NEW_MALOTE NUMBER; CURSOR C_EMP_SELEC IS(

30 29 SELECT NM_COLAB,CD_DEPART,CD_SECAO FROM EMP WHERE CD_DIRETORIA = 5); V_REGISTO C_EMP_SELEC%ROWTYPE; BEGIN FOR V_REGISTRO IN C_FUNC_SELEC LOOP IF V_REGISTRO.CD_DEPART = 16 THEN V_NEW_MALOTE := 4578; ELSIF (V_REGISTRO.CD_DEPART = 14 AND V_REGISTRO.CD_SECAO = 1) THEN V_NEW_MALOTE := 7548; ELSE V_NEW_MALOTE := 2689; END IF; UPDATE EMP SET NR_MALOTE = V_NEW_MALOTE WHERE NM_COLAB = V_REGISTRO.NM_COLAB AND CD_DEPART = V_REGISTRO.CD_DEPART AND CD_SECAO = V_REGISTRO.CD_SECAO; END LOOP; END; Quadro 5 - Programa exemplo em PL/SQL A partir deste código, conforme a notação de grafo de fluxo, pode-se montar o grafo apresentado na Figura 6. Figura 6 - Grafo do programa exemplo Ao efetuar o cálculo da complexidade ciclomática baseado no programa exemplo, usando a fórmula simplificada tem-se CC = E N + 2, ou seja, E é igual ao número de

31 30 arestas/ramos do grafo, neste exemplo 9. E N é o número de nós presentes, neste caso 7. igual a 4. Tem-se: CC = , então, a complexidade ciclomática do programa apresentado é No exemplo apresentado, os caminhos linearmente independentes possíveis estão apresentados no quadro 6. Caminho Caminho Caminho Caminho Quadro 6 - Caminhos possíveis do exemplo Estes seriam os caminhos que os casos de teste deveriam contemplar para garantir que cada condição tenha sido testada pelo menos uma vez. Na prática, conforme Pressman (1995, p. 795), o cálculo do caminho básico ou da complexidade ciclomática, pode ser levado a efeito sem o uso da notação de grafos. Eles apenas servem como uma ferramenta muito útil para entender o fluxo de dados e ilustrar a abordagem. 2.6 A LINGUAGEM PL/SQL Segundo D Ávila (2006), a linguagem SQL surgiu em Junho de 1970, quando a IBM desenvolveu um projeto de sistema de gerenciamento de banco de dados relacional, neste projeto a linguagem recebeu inicialmente o nome de Structured English Query Language (SEQUEL). No final da década de 70, a Oracle começou a desenvolver produtos similares e introduziu a primeira implementação de SQL comercialmente disponível. A linguagem SQL pura, de acordo com Oracle (2005), é uma linguagem interativa que tem como principal objetivo pesquisar, recuperar e formatar dados de forma simples. Em função destas limitações, a Oracle desenvolveu uma linguagem procedural, baseada no SQL,

32 31 incrementando várias funcionalidades encontradas nas linguagens procedurais, como por exemplo, declaração de variáveis, controle de fluxo e cursores. Isto permitiu que várias frases SQL pudessem ser processadas ao mesmo tempo, surgindo o SQL procedural ou PL/SQL A linguagem A estrutura básica de um bloco PL/SQL é apresentada no quadro 7. DECLARE -- Bloco de declaração (opcional) BEGIN -- Programa propriamente dito EXCEPTION -- Bloco de exceções (opcional) END Quadro 7 - Estrutura básico de códigos PL/SQL Cada seção apresenta suas características, conforme segue: a) seção de declaração: a primeira seção do bloco é chamada de declaração. Ela é opcional, porém se a seção executável utilizar variáveis, constantes, cursores e exceções, estas devem ser declaradas nesta seção antes de serem usadas por algum comando; b) seção de execução: esta segunda seção é o coração do bloco, pois contém os comandos que serão executados. Estes comandos devem seguir as regras da linguagem SQL e devem obrigatoriamente terminar com ponto e vírgula; c) seção de exceção: na terceira seção podem ser incluídos comandos para tratar eventuais erros que venham a ocorrer na execução do programa. A linguagem PL/SQL é formada pelos caracteres apresentados no quadro 8:

33 32 Quadro 8 - Caracteres da linguagem PL/SQL É bom ressaltar que a linguagem é caso insensitivo, ou seja, letras maiúsculas e minúsculas têm o mesmo valor. Com estes caracteres, podem ser montados diversos identificadores, que podem ser variáveis, constantes, cursores, pacotes, procedimentos, funções, registros, tabelas ou palavras reservadas. Estes identificadores devem começar com uma letra, não podem conter espaços, podem conter os caracteres ($, _, #) e podem ter o tamanho máximo de 30 caracteres. Conforme Dollar (2001, p. 17), como em todas as outras linguagens, o compilador PL/SQL ignora os comentários, porém é uma boa prática utilizá-los para melhorar a legibilidade. Existem dois tipos de comentário em PL/SQL: o comentário de linha e o de bloco. O comentário de linha é feito colocando-se dois hífens (--) no início da linha a ser comentada. E o comentário de bloco é feito delimitando o bloco desejado com os seguintes caracteres /* */. Segundo Kochhar, Gravina e Nathan (2000, p. 16-8), toda unidade PL/SQL compreende um ou mais blocos de instrução. Estes blocos podem ser inteiramente separados ou aninhados um dentro do outro. As unidades básicas conhecidas são: blocos anônimos e subprogramas. Os subprogramas englobam procedimentos e funções. O foco deste trabalho, no que diz respeito à linguagem PL/SQL é identificar e contar as estruturas de controle que caracterizam uma quebra no fluxo lógico das instruções. Conforme Kochhar, Gravina e Nathan (2000, p. 19-3), o PL/SQL possui dois tipos de estruturas de controle: construções condicionais com a instrução IF e estruturas para controle LOOP. A- Z! $ * { } ', / a- % ( ) ; '' # & [ ] : <>? - A instrução IF permite que o PL/SQL execute ações de modo seletivo com base em

34 33 condições. Existem três formatos de instruções IF (KOCHHAR, GRAVINA e NATHAN, 2000): a) IF THEN END IF, conforme quadro 9;... IF v_nome = MARCELO THEN v_cargo := GERENTE ; v_depto := 7; v_salario := sal * 0.20; END IF;... Quadro 9 - Exemplo IF simples b) IF THEN ELSE END IF, conforme quadro 10;... IF v_data_conclu > v_data_prev THEN v_flag := Atrasada ; ELSE v_flag := Adiantada ; END IF;... Quadro 10 - Exemplo IF - THEN - ELSE c) IF THEN ELSIF END IF, conforme quadro IF v_comeco > 100 THEN v_comeco := 2 * v_comeco; ELSIF v_comeco >= 50 THEN v_comeco := 0.5 * v_comeco; ELSE v_comeco := 0.1 * v_comeco; END IF;... Quadro 11 - Exemplo IF - THEN - ELSIF As instruções de LOOP repetem uma instrução ou seqüência de instrução várias vezes. São três os tipos de LOOP existentes (KOCHHAR, GRAVINA e NATHAN, 2000): a) LOOP básico: conjunto de instruções entre as palavras-chave LOOP e END

35 34 LOOP. Neste tipo de loop, a instrução é executada pelo menos uma vez e é necessário que seja incluída a instrução EXIT, ou o loop se torna infinito. Um exemplo desta instrução é apresentado no quadro 12; DECLARE v_nro_ordem item.nro_ordem%type := 100; v_contador NUMBER(2):= 1; BEGIN LOOP INSERT INTO item(nro_ordem, seq) VALUES (v_nro_ordem, v_contador); v_contador := v_contador + 1; EXIT WHEN v_contador > 50; END LOOP; END; Quadro 12 - Exemplo LOOP básico b) LOOP FOR: tem a mesma estrutura geral do loop básico, porém este tem uma instrução antes da palavra LOOP que determina quantas vezes o ciclo de instruções deve ser repetido. Ele executará exatamente a quantidade de vezes definida na instrução. No quadro 13 é apresentado um exemplo desta instrução; DECLARE v_nro_ordem item.nro_ordem%type := 100; BEGIN FOR i IN LOOP INSERT INTO (nro_ordem, seq) VALUES (v_nro_ordem, v_contador); END LOOP; END; Quadro 13 - Exemplo LOOP FOR c) LOOP WHILE: este comando também precisa de uma instrução antes da palavra LOOP, esta instrução precisa ser uma condição que retorne TRUE ou FALSE. O ciclo será repetido até que o resultado da condição seja FALSE. Um exemplo é apresentado no quadro 14.

36 35 DECLARE v_nro_ordem item.nro_ordem%type := 100; v_contador NUMBER(2):= 0; BEGIN WHILE v_contador < 10 LOOP INSERT INTO (nro_ordem, seq) VALUES (v_nro_ordem, v_contador); v_contador := v_contador + 1; END LOOP; END; Quadro 14 - Exemplo LOOP WHILE Instruções SQL podem ser utilizadas no bloco executável de um código PL/SQL. Ele suporta integralmente a linguagem de manipulação de dados e comandos de controle transacional. Porém os comandos SQL não são abordados neste trabalho e portanto, não são detalhados. 2.7 TRABALHOS CORRELATOS Seibt (2001) abordou o cálculo de métrica de software, porém não para códigos procedurais, mas sim para códigos orientados à objetos (OO), codificados na linguagem Delphi. Neste trabalho a autora cita a complexidade ciclomática como uma métrica tradicional, porém alguns dos métodos implementados podem ser estudados e adaptados para análise de códigos-fonte. Profundidade da árvore de herança e contagem de métodos foram algumas das métricas OO implementadas neste trabalho. Possamai (2000) trata de métricas de software para códigos-fonte codificados na linguagem Pascal. Neste trabalho foram implementadas métricas como a ciência do software e a complexidade ciclomática. Adicionalmente podem ser exibidos os grafos e fluxogramas de

37 36 determinadas partes do sistema analisado. O autor utiliza-se de conceitos da UML como o diagrama de classes e o diagrama de seqüência para poder representar melhor a solução proposta. A métrica da complexidade ciclomática também é tratada de forma mais detalhada em VanDoren (1997), onde é descrita a forma de cálculo da complexidade e como interpretar os resultados obtidos. Neste artigo também são comentadas as limitações deste tipo de métrica, bem como outras métricas que se propõem a calcular a complexidade de um software, como por exemplo, a métrica de Bowles, a métrica de Ligies e a métrica de Halstead, também conhecida como ciência do software. Gonçalves (2003), tendo o objetivo de estudar os critérios de testes existentes para aplicações de banco de dados relacional que utilizam SQL, implementou um software batizado de STest for Delphi, onde são realizados testes estruturais e funcionais em softwares codificados em linguagem Delphi. Para representar os testes estruturais o autor implementou a métrica da complexidade ciclomática. Dolla (2001), estudou a estrutura dos códigos-fonte em PL/SQL e desenvolveu um aplicativo que reestrutura o código. Identificando palavras reservadas, literais, colunas de tabelas e demais estruturas, o aplicativo promove a reorganização do código, melhorando sua legibilidade. Embora desenvolvido em Delphi, a maneira de identificar estas estruturas é muito parecida com a utilizada neste trabalho.

38 37 3 DESENVOLVIMENTO DO SOFTWARE Neste capítulo estão apresentadas informações detalhadas inerentes à especificação e implementação do software. São descritos os requisitos do sistema, os diagramas criados para representá-lo, como foi realizada a implementação do software e quais as principais conclusões. 3.1 REQUISITOS PRINCIPAIS DO PROBLEMA TRABALHADO O software foi desenvolvido a partir das seguintes premissas: a) deve-se permitir a importação de arquivos de código fonte PL/SQL para análise (Requisito Funcional - RF); b) deve-se reconhecer as quebras de fluxo dos códigos PL/SQL para banco de dados Oracle e efetuar a soma das mesmas (RF); c) deve-se apresentar o resultado da análise, acompanhado de um texto explicativo sobre o nível de manutenibilidade que aquele código possui (RF); d) deve-se permitir gravar os resultados em arquivos externos ao sistema (RF); e) deve ser desenvolvido em linguagem Java (Requisito Não-Funcional - RNF); f) deve utilizar a métrica da complexidade ciclomática conforme proposto por McCabe (1976 apud SOMMERVILLE, 2003, p.384) (RNF). 3.2 ESPECIFICAÇÃO DO SOFTWARE Durante a especificação do trabalho, foram estudados vários pontos importantes. Entre eles a maneira como o software será manipulado. Chegou-se a conclusão de que para o

39 38 software ter alta operabilidade dentro de uma empresa, esta deveria ser executada no modo console do sistema operacional. Esta solução, porém, não seria adequada para uma apresentação acadêmica, portanto, foi trabalhada mais cuidadosamente a especificação de uma versão do software com uma interface gráfica para o usuário final. Por isso neste capítulo serão apresentados somente os diagramas da versão gráfica. Para efetuar a especificação do aplicativo foram utilizados os conceitos da linguagem Unified Modeling Language (UML) que segundo Fowler (2005, p. 25) é uma família de notações gráficas, apoiada por um metamodelo único, que ajuda na descrição e no projeto de sistemas de software. Para a modelagem foi utilizada a ferramenta Enterprise Architect da empresa Sparx Systems, e foram especificados os diagramas de caso de uso, o diagrama de classes e o diagrama de atividades Diagrama de Caso de Uso Os casos de uso são usados tipicamente para captar os requisitos funcionais e as interações do usuário com o sistema. Porém, devido às particularidades deste aplicativo, foi visualizado apenas um caso de uso, que é apresentado na figura 7. Figura 7 - Diagrama de caso de uso Este caso apresenta cinco cenários: Analisar Arquivos, Analisar Resultados, Gravar Resultados, Campo Arquivo Nulo e Campo Arquivo Inválido. Estes cenários são apresentados detalhadamente no quadro 15.

40 39 Quadro 15 - Cenários do Caso de Uso Diagrama de Classes O diagrama de classes, segundo Fowler (2005, p. 52), tem o objetivo de descrever os tipos de objetos presentes no sistema e apresentar os vários tipos de relacionamentos entre eles. A figura 8 apresenta o diagrama de classes completo do software implementado.

41 40 Figura 8 - Diagrama de classes Neste diagrama, a classe clstelaprincipal é o primeiro objeto a ser instanciado na execução do programa, é ela que controla todas as opções disponíveis no aplicativo. A partir dela são instanciadas as outras classes. Entre estas classes, estão os objetos clstelasobre, clstelaaviso e clstelaarquivos que são auxiliares e não apresentam contribuição relevante para o fluxo de execução do programa, portanto não serão detalhadas nesta seção. A classe clstelaresultado quando instanciada é responsável por iniciar a análise no arquivo para obter os resultados. É ela que instancia a classe clscalculo, e recebe o resultado para ser mostrado ao usuário. É também a partir dela que parte a ação de salvar o resultado em um arquivo externo, caso o usuário assim desejar, ação esta que é realizada efetivamente pela classe clsutilitaria.

42 41 A classe clscalculo é responsável por receber o arquivo da classe clstelaresultado e preparar este arquivo, para que posteriormente seu método geraresult possa efetuar o cálculo da Complexidade Ciclomática Diagrama de Atividades A seguir, na figura 9, é apresentado o diagrama que mostra o fluxo das atividades do software, desde a escolha do arquivo até a apresentação do resultado. ad TCC INICIO Escolhe arquiv o pra análise Notifica usuário [NÃO] Arquivo Válido? [SIM] Limpa Comentários [NÃO] É diretório? [SIM] Percorre arquiv os do diretório Separa os Tokens Reconhece Função ou Procedimento FIM Calcula Métrica Grav a resultado em arquiv o [SIM] [SIM] Gravar Fim Arquivo? Apresenta Resultado? [NÃO] [SIM] resultado [NÃO] Nova análise? Figura 9 - Diagrama de atividades

43 IMPLEMENTAÇÃO DO SOFTWARE Este capítulo tem por objetivo apresentar detalhes da implementação, com comentários sobre o código e os principais problemas enfrentados no decorrer desta etapa. Para tornar real este trabalho foi utilizada a linguagem Java em sua versão O aplicativo, que, como foi citado anteriormente, seria executado em modo console, foi codificado primeiramente, utilizando a ferramenta Eclipse na sua versão 3.1. Mas, no decorrer do trabalho, optou-se por utilizar a ferramenta NetBeans na sua versão 5.0, pelo fato da mesma facilitar em muito a criação de uma interface com o usuário. Ao ser iniciado o aplicativo, uma classe clstelaprincipal é instanciada, e a partir dela, de acordo com a ação do usuário podem ser instanciadas as classes clstelasobre, clstelaresultado e clstelaarquivos. Quando o usuário pressiona o botão para escolher um arquivo na tela principal, um objeto clstelaarquivos é instanciado, neste caso, a tela possui um componente JFileChooser da classe Swing do Java. Neste componente pode ser criado um filtro, para que o usuário somente possa escolher um tipo de arquivo. Porém, este filtro deixou a operabilidade da tela difícil, e por isso, todas as validações de arquivos passaram a ser realizadas pelo método ehvalido da classe clsutilitaria, classe esta instanciada pela clstelaprincipal quando o usuário pressiona o botão de cálculo. O código das validações dos arquivos pode ser observado no Quadro 16.

44 43 Quadro 16 - Validação dos arquivos Ainda no Quadro 16 pode ser observado que feitas as devidas verificações, a clstelaprincipal instancia a classe clstelaresultado. Esta por sua vez, instancia a classe clscalculo passando o caminho do arquivo ou diretório a ser analisado. Ao receber este arquivo, a classe clscalculo começa a tratar o arquivo chamando o método tratapathrecebido que tem a finalidade de verificar se o arquivo passado é um diretório ou um arquivo.sql. Se for um diretório, a classe percorre recursivamente os arquivos contidos neste diretório, como mostrado no Quadro 17, até encontrar um arquivo.sql para efetuar o cálculo. Durante este processo, a classe grava em uma variável, cada arquivo ou diretório válido encontrado.

45 44 Quadro 17 - Leitura recursiva de diretórios Após ter encontrado um arquivo.sql, a classe clscalculo chama o método analisaarquivo, que irá percorrer os dados do arquivo e fazer o tratamento dos mesmos. Antes de o método analisaarquivo analisar o código, o método limpacoments é chamado para suprimir do arquivo os comentários de linha da linguagem PL/SQL e também as linhas de PROMPT que possam existir no arquivo, conforme Quadro 18

46 45 Quadro 18 - Limpeza dos comentários Dentro do método analisaarquivo ainda é suprimido os comentários no fim de uma linha válida. Após garantir que irá analisar uma linha de código efetivamente, o método analisaarquivo, divide esta linha em tokens através do método StringTokenizer do Java, conforme trecho de código apresentado no Quadro 19.

47 46 Quadro 19 - Uso do método StringTokenizer Percorrendo o array gerado pelo StringTokenizer, o método avalia se o token é início ou fim de uma string ou de um comentário de bloco da linguagem PL/SQL, através dos métodos iniciocommentorstring e fimcommentorstring. Ainda avaliando o array, o método verifica se o token identifica o início de um procedimento ou de uma função, estruturas estas que caracterizam um subprograma na linguagem. A cada novo subprograma encontrado, o aplicativo manda o array de tokens montado até agora, para ser calculado pelo método geraresult, conforme mostra o trecho de código do Quadro 20.

48 47 Quadro 20 - Lógica de subprogramas O método geraresult é encarregado então de avaliar cada token recebido do array e identificar quais deles representam uma quebra de fluxo na execução de um programa PL/SQL. A cada quebra encontrada é incrementado o contador da CC. Esta verificação pode ser observada no Quadro 21, que apresenta o principal trecho de código do programa, pois é neste momento que é feito o cálculo da CC.

49 48 Quadro 21 - Cálculo da complexidade ciclomática Depois de efetuado o cálculo pela classe clscalculo, a mesma devolve uma variável do tipo String contendo o resultado, para a classe clstelaresultado, que apresenta os dados recebidos na tela. 3.4 OPERACIONALIDADE DA IMPLEMENTAÇÃO A seguir está descrita a seqüência de passos que o usuário deverá seguir para obter o valor da CC de um arquivo PL/SQL. Ao ser iniciado, o aplicativo apresenta ao usuário a tela principal do sistema, conforme Figura 10. Para efetuar o cálculo da CC, o usuário deverá primeiro escolher o arquivo ou diretório que deseja analisar, clicando no botão Abrir, após escolhido, deverá clicar sobre o botão Calcular Resultado e a análise terá sido iniciada. É importante ressaltar que os arquivos que o programa analisa devem ser arquivos com

50 49 extensão.sql, devidamente compilados, ou seja, este aplicativo não realiza a análise léxica ou sintática do código contido nos arquivos, apenas recebe o conteúdo e calcula a métrica. Figura 10 - Tela Principal Após o aplicativo terminar a análise do(s) arquivo(s), será apresentada para o usuário a tela de resultados, conforme mostra a figura 11. Nesta tela são mostrados os diretórios e programas válidos reconhecidos pelo aplicativo e o valor da CC de cada um deles, classificados pelo nível de complexidade. Figura 11 - Tela de Resultado

51 50 Nesta tela há a possibilidade do usuário salvar o resultado obtido, clicando sobre o botão Salvar e escolhendo o caminho e o arquivo de destino. Alguns exemplos usados na execução do programa para demonstração dos resultados podem ser observados no anexo A. O aplicativo também apresenta, como citado anteriormente, uma versão para execução do programa no modo console do sistema operacional, porém como este não é o foco deste trabalho, a implementação não está completa, porém efetua o cálculo como na versão gráfica. Na figura 12 é mostrada a tela de ajuda da versão console e na figura 13, um exemplo de um cálculo efetuado. Figura 12 - Opção de ajuda na versão console

52 51 Figura 13 - Resultado na versão console 3.5 RESULTADOS E DISCUSSÃO Com a finalização deste trabalho é possível notar que durante a realização do mesmo, após várias pesquisas, a idéia inicial para a implementação sofreu alterações, na verdade, a solução encontrada difere bastante da adotada por Possamai (2000), por exemplo. Inicialmente, pensava-se que seria necessária a criação de uma BNF simplificada e específica para realização do cálculo, porém no decorrer do trabalho, verificou-se que a solução seria alcançada simplesmente percorrendo o código, considerado válido, e contando as quebras no fluxo dos dados. Confrontando com o trabalho de Possamai (2000), que implementou um aplicativo para o cálculo de várias métricas para a linguagem Pascal, este trabalho apresentou-se de uma forma bem mais simples. Acredita-se que a solução adotada por Possamai (2000), foi escolhida baseando-se no fato de que ele desejava apresentar a estrutura de um projeto Pascal de modo gráfico para o