Instituto Tecnológico da Aeronáutica
Departamento de Engenharia Eletrônica e Computação CE-230: Qualidade, Confiabilidade e Segurança de Software
Professor Dr. Luis Alberto Vieira Dias Professor Dr. Adilson Marques da Cunha.
Exame Final
-Flávio Roberto Ianague Diniz
Novembro de 2008Objetivo
Cada Aluno deverá publicar um relatório impresso sobre os resultados da avaliação de sua métrica.
Métricas de Halstead
As métricas de complexidade de Halstead foram desenvolvidas por Maurice Halstead como um meio de determinar uma medida quantitativa da complexidade diretamente a partir dos operadores e os operandos contidos no módulo de um programa a partir do código fonte.
Porque são aplicadas ao código, são mais freqüentemente utilizadas como métrica de manutenção. Contudo, existem evidências de que as métricas de Halstead também são úteis durante o desenvolvimento para avaliar a qualidade do código em aplicações computacionais densas ou para acompanhar as tendências de complexidade.
As métricas de Halstead foram introduzidas em 1977 tendo sido usadas extensivamente desde então. Estão entre as mais antigas métricas de complexidade de programas computacionais. Através do IBM Rational Test RealTime é possível estimar pelas métricas de Halstead o tempo de teste de qualquer código-fonte C/C++.
As métricas de Halstead baseiam-se em interpretar o código-fonte como uma seqüência de tokens cada qual podendo ser um operador ou um operando. Os seguintes parâmetros são contabilizados:
Parâmetro Significado
n1 Número de operadores distintos
n2 Número de operando distintos
N1 Número de instâncias de operadores
Métrica Significa Formula n Vocabulário n1 + n2 N Tamanho N1 + N2 V Volume N * log2 n D Dificuldade n1/2 * N2/n2 E Esforço V * D B Erros V / 3000 T Tempo de teste E / k
Nota: na fórmula acima, k é o número de stroud, que tem um valor arbitrário de 18. Com a experiência, você pode ajustar o número de stroud para adaptar o cálculo do tempo estimado de teste (T) para as suas próprias condições de teste: background do time, nível de criticalidade, e assim por diante.
Teste do CSC CES
O Componente de Software Computacional denominado CES – Controle de Escalonamento – foi testado pelo RTRT tendo sido modelado no Rose RealTime (código fonte em C++).
A seguir, é descrita a seqüência de passos percorrida para execução dos testes no RTRT:
Passo 1 – Criado o projeto CES.rtp usando-se o wizard do
RTRT de acordo com as orientações contidas no tutorial “Configuração do Software Rational Test RealTime”, elaborado por Denis S. Loubach. A árvore de arquivos que compõem o projeto é mostrada na figura 1.
Passo 2 – O projeto foi compilado (Build) e todos os
módulos foram pré-processados, instrumentados, compilados e linkados pelo RTRT conforme pode ser observado na figura 2.
Passo 3 – Foram gerados os relatórios de teste contendo os
resultados calculados para as métricas estáticas conforme mostrado nas figuras 3,4 e 5.
Avaliação dos Resultados
A seguir são exibidas as métricas de Halstead para os principais módulos de código do componente CES:
Métricas de Halstead CES.cpp Coleta.cpp ConfiguracaoTarefa.cpp InterruptControl.cpp
Diculdade 64,00 30,00 15,00 15,00 Esforço 130634000000,00 162514,00 19250.6 18041.3 Estimativa de Erros 6,80 1,80 0,43 0,40 Tamanho 2608,00 769,00 238,00 226,00 Tempo de Teste 20:09:34 02:30:28 00:17:49 00:16:42 Volume 20411,60 5417,14 1283,36 1202,76 Vocabulário 227,00 132,00 42,00 40,00
Métricas de Halstead Tarefa.cpp TimerInterruptControl.cpp TopWin32.cpp Transmissao.cpp
Diculdade 33,00 10,00 45,00 32,00 Esforço 56296.9 19883.3 375380,00 174826,00 Estimativa de Erros 0,56 0,66 2,77 1,81 Tamanho 290,00 338,00 1145,00 772,00 Tempo de Teste 00:52:07 00:18:24 05:47:34 02:41:52 Volume 1705,96 1988,33 8341,79 5463,29 Vocabulário 59,00 59,00 156,00 135,00
Métricas de Halstead WindowsISRLayer.cpp Armazenamento.cpp BaseCustomIPCLayer.cpp Média Geral (14 módulos)
Diculdade 54,00 30,00 45,00 33,91 Esforço 787684,00 162514,00 252222,00 18662273591,43 Estimativa de Erros 4,86 1,80 1,87 2,16 Tamanho 1873,00 769,00 802,00 893,64 Tempo de Teste 12:09:20 02:30:28 03:53:32 04:40:43 Volume 14586,70 5417,14 5604,92 6493,00 Vocabulário 221,00 132,00 127,00 120,91
Como todas as métricas são calculadas com base em n1, n2, N1 ou N2, o módulo “CES.cpp” por
ser significativamente maior que os outros (705 LOC) apresentou a maior complexidade para todas as métricas.A tabela anterior dá uma boa idéia da complexidade de cada módulo de código do programa (arquivo .cpp) que representa uma cápsula conforme modelada no Rational Rose RT.
O volume de um arquivo deverá ser no mínimo 100 e no máximo 8000 por função (ou método). Estes limites são baseados em volumes medidos por arquivos cujos LOC e v (G) estão perto de seus limites recomendados. Os limites de volume podem ser usados para duplo check. Para a cápsula, como um todo a maior volume (~20K) é considerada uma medida razoável.
A dificuldade (D) do programa é proporcional ao número de operadores únicos no programa. D é proporcional à taxa entre o número total de e o número de operandos únicos (ou seja, se o mesmo operandos são muitas vezes utilizados no programa, ele é mais propenso a erros). É interessante notar que a dificuldade média dos módulos de código ficou em ~34.
O esforço para implementar (E) ou compreender um programa é proporcional ao volume e à dificuldade nível do programa. O valor de E para o módulo CES.cpp foi comparativamente elevado, resultado de um LOC significativamente maior que o dos outros módulos.
O tempo para executar um programa ou compreendê-lo (T) é proporcional ao esforço. Experimentação empírica pode ser utilizada para calibrar essa quantidade. Halstead verificou que dividindo por 18 o esforço pode dar uma aproximação do tempo em segundos. Temos um tempo médio de testes de 4 horas, puxado pra cima pelo elevado tempo do componente CES.cpp (20 horas). Veja que somando-se todos os tempos de teste temos um total de 51 horas.
O número de erros entregues (B) se correlaciona com a complexidade global do software e é uma estimativa para o número de erros na implentação. Em um arquivo B deve ser inferior a 2. As experiências têm demonstrado que arquivos de programas em C ou C + + geralmente contém mais erros que o sugerido por B. O número de defeitos tende a crescer mais rapidamente que B. O valor médio dos módulos encontrado foi de ~2, portanto dentro do esperado.
Em testes dinâmicos, a métrica de Halstead mais importante é o número de erros entregues. O número de erros entregues se aproxima do número de erros em um módulo. Assim o objetivo deve ser garantir que os testes encontrem no mínimo B erros em cada módulo.
Considerações Finais
A integração entre o Rational Rose RT e o RTRT permite o desenvolvimento de sistemas baseados em modelos, gerando código C++ automaticamente e permitindo a instrumentação dos testes também de modo automática.
O RTRT foi usado para gerar métricas estáticas de Halstead para o CSC CES – Controle de Escalonamento – do projeto MPCD-SAT-RAF-CEL. Estas métricas servem ao propósito de indicar a complexidade do código dos vários módulos do componente CES e para gerar uma estimativa do tempo de testes.
