software para cÁlculo da complexidade...
TRANSCRIPT
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 2006
2006/1- 27
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 2006
2006/1-27
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: Prof. Alexander Roberto Valdameri, Mestre - Orientador, FURB
______________________________________________________ Membro: Prof. Everaldo Artur Grahl, Mestre – FURB
______________________________________________________ Membro: Prof. Ricardo Alencar de Azambuja, Mestre – FURB
Blumenau, Junho de 2006.
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.
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.
“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)
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.
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.
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
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
SUMÁRIO
1 INTRODUÇÃO..................................................................................................................11
1.1 OBJETIVOS DO TRABALHO ........................................................................................13
1.2 MOTIVAÇÃO...................................................................................................................13
1.3 ESTRUTURA DO TRABALHO......................................................................................14
2 FUNDAMENTAÇÃO TEÓRICA....................................................................................15
2.1 MÉTRICAS DE SOFTWARE..........................................................................................15
2.1.1 Classificação ...................................................................................................................16
2.1.2 Métricas de Produto ........................................................................................................18
2.2 TESTE DE SOFTWARE ..................................................................................................19
2.2.1 Tipos de teste...................................................................................................................20
2.3 MANUTENIBILIDADE...................................................................................................21
2.3.1 Ciência do Software ........................................................................................................23
2.4 NOTAÇÃO DE GRAFO DE FLUXO..............................................................................24
2.5 COMPLEXIDADE CICLOMÁTICA...............................................................................26
2.5.1 Exemplo aplicado............................................................................................................28
2.6 A LINGUAGEM PL/SQL.................................................................................................30
2.6.1 A linguagem....................................................................................................................31
2.7 TRABALHOS CORRELATOS........................................................................................35
3 DESENVOLVIMENTO DO SOFTWARE.....................................................................37
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA TRABALHADO...................................37
3.2 ESPECIFICAÇÃO DO SOFTWARE...............................................................................37
3.2.1 Diagrama de Caso de Uso...............................................................................................38
3.2.2 Diagrama de Classes .......................................................................................................39
3.2.3 Diagrama de Atividades..................................................................................................41
3.3 IMPLEMENTAÇÃO DO SOFTWARE ...........................................................................42
3.4 OPERACIONALIDADE DA IMPLEMENTAÇÃO........................................................48
3.5 RESULTADOS E DISCUSSÃO ......................................................................................51
4 CONCLUSÕES..................................................................................................................53
4.1 EXTENSÕES ....................................................................................................................54
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................55
ANEXO A – Códigos utilizados para exemplificar o funcionamento do software...........57
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 1970.
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
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
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
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.
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,
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.
2.1.1 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.
17
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.
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;
Orientadas ao Tamanho
Orientadas à Função
Orientadas ao Ser Humano
de Produtividade
de Qualidade
Técnicas
Processo do Software
Decisões de gerenciamento
Medições de controle
Produtos de software
Medições preditivas
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.
2.1.2 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.
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
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.
2.2.1 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.
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 9126-1 (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;
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).
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.
2.3.1 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
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
Quadro 1 - Principais operadores básicos
Baseado nesta teoria são geradas as medidas mostradas no quadro 2 (PRESSMAN,
1995, p. 757).
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
25
uma notação específica para cada estrutura lógica de controle, como mostrado na figura 3
(PRESSMAN, 2002, p. 438).
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.
1
2
34
56
7
8
9
Ramo
Nó
Região
R2
R1R3
R4
Figura 4 - Ramos, nós e regiões
Um nó representa uma ou mais instruções procedimentais. Os arcos do grafo,
Fonte: adaptado de Pressman (2002).
Fonte: adaptado de Pressman (1995).
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.
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
Fonte: adaptado de Pressman (2002).
27
Fonte: Vandoren (1997)
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.
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.
28
Fonte: Vandoren (1997)
Neste quadro é apresentada uma escala para a medição.
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.
2.5.1 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(
Complexidade Ciclomática Avaliação do Risco 1 - 10 programa simples, sem muito risco. 11 - 20 programa mais complexo, risco moderado. 21 - 50 programa de risco elevado
maior que 50 programa incompreensível, risco muito alto.
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
30
arestas/ramos do grafo, neste exemplo 9. E N é o número de nós presentes, neste caso 7.
Tem-se: CC = 9 – 7 + 2, então, a complexidade ciclomática do programa apresentado é
igual a 4.
No exemplo apresentado, os caminhos linearmente independentes possíveis estão
apresentados no quadro 6.
Caminho 1 1 - 7 Caminho 2 1 -2 - 5 - 6 - 1 - 7 Caminho 3 1 - 2 - 3 - 5 - 6 - 1 - 7
Caminho 4 1 - 2 - 3 - 4 - 5 - 6 - 1 – 7
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,
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.
2.6.1 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:
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 instrução IF permite que o PL/SQL execute ações de modo seletivo com base em
A- Z ! $ * { } ' , /
a- z @ % ( ) ; '' . +
0 - 9 # & [ ] : <> ? -
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 11.
...
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
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 1..10 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.
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
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.
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
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.
3.2.1 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.
39
Quadro 15 - Cenários do Caso de Uso
3.2.2 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.
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.
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.
3.2.3 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
Escolhe arquiv opra análise
Arquivo Válido?Notifica usuário
É diretório? Percorre arquiv os do diretório
Limpa Comentários
Separa os Tokens
Reconhece Função ou Procedimento
Calcula Métrica
Fim Arquivo? Apresenta resultado
GravarResultado?
Grav a resultado em arquiv o
Novaanálise?
INICIO
FIM
[SIM][NÃO]
[NÃO]
[SIM]
[NÃO] [SIM] [NÃO]
[SIM]
[SIM]
Figura 9 - Diagrama de atividades
42
3.3 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 1.4.2. 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.
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.
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
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.
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.
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.
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
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
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
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
52
usuário, através de um fluxograma. Para tanto ele se utiliza de grafos para mapear o código e
realiza o cálculo pela contagem dos ramos e nós, conforme a fórmula já citada neste trabalho,
porém, analisando o trabalho, pode-se chegar à conclusão de que, caso o autor não desejasse a
apresentação gráfica, ele poderia ter optado pela mesma solução implementada neste trabalho.
Após o aplicativo pronto, e depois de vários testes de análise de alguns programas,
verificou-se que a simples contagem das quebras não gerava o resultado correto, pois ficaria
faltando a contagem do fluxo direto, ou seja, a opção onde o fluxo não entra em nenhuma
quebra, por isso o cálculo foi alterado para que antes de ser apresentado para o usuário, o
valor da CC fosse acrescentado em um, para considerar também o fluxo direto. Assim, ao se
observar um bloco de comandos sem nenhuma quebra, pode-se notar que o valor de sua
complexidade é 1.
53
4 CONCLUSÕES
O presente trabalho surgiu da necessidade real visualizada no cenário no qual a
acadêmica exerce atividade profissional. A empresa tem investido significativas cifras na área
de TI, em especial, na busca pela qualidade das atividades e produtos desenvolvidos pela
equipe de informática. Neste sentido, notou-se a necessidade de mensurar a complexidade dos
códigos das rotinas implementadas, em sem especial, na linguagem PL/SQL para o banco de
dados Oracle. Com a confecção deste trabalho, o analista de qualidade terá a sua disposição
uma ferramenta de apoio no diagnóstico e por conseqüência, na melhoria dos códigos
construídos.
Também com a conclusão deste trabalho, é óbvio que se volte no tempo e se lembre de
todas as etapas vencidas. Pode-se verificar ao longo das explanações dos assuntos, que os
objetivos estabelecidos foram atingidos em sua plenitude.
O aplicativo aqui implementado possibilita de fato a análise de um arquivo ou diretório
escolhido pelo usuário, que através do reconhecimento das quebras de fluxo do código
(estruturas condicionais), apresenta para o usuário o resultado do cálculo da complexidade
ciclomática e um parecer sobre o que este valor representa.
Ao longo do desenvolvimento, muitas idéias foram alteradas para que o trabalho
atingisse um nível satisfatório, entre elas o fato de desenvolver uma interface gráfica,
atividade esta, que não estava incluída no planejamento inicial, que por sua vez, apenas previa
a operação em modo console.
A escolha da ferramenta de implementação também foi um ponto decisivo, pois o uso
do software NetBeans facilitou muito a criação das telas e da navegabilidade do sistema, e a
atividade de debug disponibilizada pela ferramenta e utilizada na etapa de testes do aplicativo,
foi fundamental para a erradicação dos erros encontrados.
54
Outro ponto importante a destacar, é o fato de que todo o aplicativo foi construído
com base nas regras da linguagem PL/SQL para banco de dados Oracle. Se o arquivo
escolhido pelo usuário tiver a extensão .SQL, mas o código tiver sido escrito para o banco
Microsoft SQL Server, por exemplo, o aplicativo não reconhece esta diferença, procede com
o cálculo normalmente, mais o resultado, muito possivelmente será apresentado com erro.
4.1 EXTENSÕES
Nesta seção são apresentadas algumas sugestões de extensões e adaptações possíveis
para este trabalho.
a) adaptar o aplicativo, para que ao apresentar o resultado, as sub-rotinas críticas
fossem destacadas de outra cor, ou seja, chamaria a atenção do usuário para as
sub-rotinas que se encontram no quarto nível de complexidade;
b) acrescentar ao aplicativo, outras métricas aplicáveis a códigos-fonte procedurais,
como por exemplo, o número de linhas de código (LOC) e as métricas da ciência
do software;
c) implementar no aplicativo a opção do usuário escolher entre analisar os dados
buscando arquivos do sistema de diretórios ou efetuar conexão com um banco de
dados Oracle e ler as sub-rotinas diretamente do banco;
d) implementar a gravação dos resultados em tabelas do banco de dados, para
posteriormente efetuar consultas estatísticas;
e) e por fim, como o sistema de cálculo é baseado nas quebras de fluxo, poderia ser
criado um projeto novo, adaptando este trabalho para que efetuasse a análise de
outras linguagens procedurais.
55
REFERÊNCIAS BIBLIOGRÁFICAS
ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 13596: tecnologia de informação – avaliação de produto de software – características de qualidade e diretrizes para o seu uso. Rio de Janeiro, 1996.
AMBLER, Scott W. Análise e projeto orientados a objetos: seu guia para desenvolver sistemas robustos com tecnologia de objetos. Tradução Oswaldo Zanelli. Rio de Janeiro: Infobook, 1998.
BRUSAMOLIN, Valério. Manutenibilidade de Software. Revista Digital Online, [s.l.], v. 2, 2004. Disponível em: <http://www.revdigonline.com/revistas.asp>. Acesso em: 03 out. 2005.
D’ÁVILA, Márcio. SQL – Structured Query Language. Belo Horizonte, 2006. Disponível em: < http://www.mhavila.com.br/link/db/sql.html>. Acesso em: 05 mar. 2006.
DEMARCO, Tom. Controle de projetos de software: gerenciamento, avaliação e estimativa. Rio de Janeiro: Campus, 1989.
DOLLA, Dyckson Dyorgio. Ferramenta de apoio a reestruturação de código fonte em linguagem PL/SQL baseado em padrões de legibilidade. 2001. 61 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
FERNANDES, Aguinaldo A. Gerência de software através de métricas: garantindo a qualidade do projeto, processo e produto. São Paulo: Atlas, 1995.
FOWLER, Martin. UML Essencial: um breve guia para a linguagem-padrão de modelagem de objetos. Porto Alegre: Bookman, 2005.
GONÇALVES, Klausner V. Teste de software em aplicações de banco de dados relacional. 2003. 59 f. Dissertação (Mestrado em Computação) – Curso de Pós-Graduação em Engenharia da Computação, Universidade Estadual de Campinas, Campinas.
KAN, Stephen H. Metrics and models in software quality engineering. Reading: Addison Wesley, 1995.
KOCHHAR, Neena; GRAVINA, Ellen; NATHAN, Priya. Introdução ao Oracle: SQL e PL/SQL. São Paulo: Oracle Corporation, 2000.
MCDERMID, John A. Software engineer’s reference book. Boca Raton: CRC, 1993.
MÖLLER, K. H.; PAULISH, D. J. Software metrics: a practitioner’s guide to improved product development. London: Chapman & Hall, 1993.
56
ORACLE. Manual de referência. [S.l.], 2005. Disponível em: < http://ci.ufpel.edu.br/treinamento/apostilas/programacao/oracle.pdf>. Acesso em: 05 mar. 2006.
PRESSMAN, Roger S. Engenharia de software. Tradução José Carlos Barbosa dos Santos. 3. ed. São Paulo: Makron Books, 1995.
__________. Engenharia de software. Tradução Mônica Maria G. Travieso. 5. ed. Rio de Janeiro: McGraw-Hill, 2002.
POSSAMAI, Roque C. Ferramenta de análise de código fonte em Delphi. 2000. 71 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
SEIBT, Patrícia R. R. S. Ferramenta para cálculo de métricas em softwares orientados a objetos codificados em Delphi. 2001. 86 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
SOMMERVILLE, Ian. Engenharia de software. Tradução Maurício de Andrade. 6. ed. São Paulo: Addison Wesley, 2003.
SOUZA, Thiago B. A. Um modelo de avaliação da manutenibilidade de código-fonte orientado a objeto. 2005. 48 f. Trabalho de Conclusão de Curso (Graduação em Engenharia de Software) – Centro de Informática, Universidade Federal de Pernambuco, Recife.
VANDOREN, Edmond. Complexidade ciclomática: software technology roadmap. [S.l.], 1997. Disponível em: < http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html>. Acesso em: 14 set. 2005.
WEBSTER, Kênia P. B. et al. Priorização de riscos para manutenção de software. In JORNADAS IBEROAMERICANAS DE INGENIERIA DEL CONOCIMENTO, 4., 2004, Madrid. Anais eletrônicos... Madrid: JIISIC, 2004. Disponível em: <www.ucb.br/ucbtic/mgcti/paginapessoalprof/Nicolas/Publicacoes/jiisic-04b.doc>. Acesso em: 07 set. 2005.
WIKIPÉDIA. Teste de software. [S.l.], [2006]. Disponível em: <http://pt.wikipedia.org/wiki/Teste_de_software>. Acesso em: 08 mar. 2006
57
ANEXO A – Códigos utilizados para exemplificar o funcionamento do software
Arquivo: APLICA_AUMENTO.SQL
DECLARE X NUMBER := 100; BEGIN FOR i NIM 1..10 LOOP IF MOD(i,2) = 0 THEN INSERT INTO temp VALUES (i, X, 'i is even'); ELSE INSERT INTO temp VALUES (i, X, 'i is odd'); END IF; X:=X + 100; END LOOP; END;
Arquivo: BALANCO_MENSAL.SQL
DECLARE ACCT_BALANCE NUMBER(11, 2); ACCT CONSTANT NUMBER(4) := 3; DEBIT_AMT CONSTANT NUMBER(5, 2) := 500.00; BEGIN SELECT BAL INTO ACCT_BALANCE FROM ACCOUNTS FOR UPDATE OF BAL; IF ACCT_BALANCE >= DEBIT - AMT THEN UPDATE ACCOUNTS SET BAL = BAL - DEBIT_AMT WHERE ACCOUNT_ID = ACCT; ELSE INSERT INTO TEMP VALUES (ACCT ,ACCT_BALANCE ,'infficient funds'); END IF; COMMIT; END;
Arquivo: FUNCAO_VERIFICA_LUGARES.SQL
DECLARE V_NUMEROLUGARES SALAS.NUMERO_LUGARES%TYPE; V_COMENTARIO VARCHAR2(35); BEGIN SELECT NUMERO_LUGARES INTO V_NUMEROLUGARES FROM SALAS WHERE SALA_ID = 99999; IF V_NUMEROLUGARES < 50 THEN V_COMENTARIO := 'Pequena'; ELSIF V_NUMEROLUGARES < 100 THEN V_COMENTARIO := 'Grande'; ELSE V_COMENTARIO := 'Enorme'; END IF; END;
58
Arquivo: FUNCTIONS_EXEM.SQL CREATE OR REPLACE FUNCTION F_TCC_CALCULO (ICD_EMPRESA IN NUMBER ,SCD_FICHA_TECNICA IN VARCHAR2 ) RETURN NUMBER IS BEGIN DECLARE NCD_SEQ_CALC NUMBER; -- FT CD SEQ CALCU LO NNR_REVISAO_CALC NUMBER; -- FT NR_REVISAO C ALCULO DDT_ATUALIZA_CALC DATE; -- FT DT_ULTIMA_AT UALIZA NCALCULO_VALIDO NUMBER; BEGIN BEGIN IF NCD_SEQ_CALC IS NOT NULL THEN BEGIN EXCEPTION WHEN NO_DATA_FOUND THEN NCALCULO_VALIDO := 0; END; IF NCALCULO_VALIDO = 0 THEN NCD_SEQ_CALC := NULL; END IF; END IF; END; RETURN NCD_SEQ_CALC; END; END; CREATE OR REPLACE FUNCTION F_TCC_ACR_GRP_REV (VNM_GRUPO IN VARCHAR2 ,VID_GRUPO_USUARIO IN VARCHAR2 ,VDS_GRUPO IN VARCHAR2 := NULL ) RETURN NUMBER IS BEGIN DECLARE RETORNO NUMBER := 0; BEGIN IF VID_GRUPO_USUARIO = 'V' THEN IF VNM_GRUPO = 'FOLHA' THEN RETORNO := 1; END IF; ELSIF VID_GRUPO_USUARIO = 'P' THEN IF VNM_GRUPO = 'ANTES' THEN RETORNO := 1; END IF; ELSIF VID_GRUPO_USUARIO = '7' THEN IF VNM_GRUPO = 'DEPOIS' THEN RETORNO := 1; END IF; ELSIF VID_GRUPO_USUARIO IN ('E', '1', '2', '3') T HEN IF VNM_GRUPO = 'EM' AND (UPPER(VDS_GRUPO) LIKE '%COISA%' THEN RETORNO := 1; ELSIF VNM_GRUPO = 'EE' THEN RETORNO := 1; END IF; ELSIF VNM_GRUPO = 'COMP' THEN RETORNO := 1; END IF; RETURN RETORNO; END; END;