A Correlation Analysis betweenHalstead Complexity Measures and

other Software Measures

Rodrigo Tavares Coimbra, Antônio Maria P. de Resende and Ricardo TerraDepartamento de Ciência da Computação

Universidade Federal de LavrasLavras, Minas Gerais, Brasil

Email: rodrigotcoimbra@sistemas.ufla.br, {tonio,terra}@dcc.ufla.br

Abstract—Halstead Complexity Measures, proposed in 1977,analyze a software system independently of its underlying pro-gramming language (technology) based on the measures numberof operators and operands. From these two measures, it calculatesother measures namely vocabulary, length, volume, difficulty,programming effort, errors, and testing time. The problem,nevertheless, is that since then the Academy and Industry havebeen coming up with hundreds of new metrics that differ in theirassertions and calculations. Therefore, the objective of this paperis to present a correlation analysis between the eleven Halsteadmeasures and other 27 popular measures proposed over thedecades (e.g., LOC, cyclomatic complexity, and efferent coupling)through the inspection of 97 open-source Java systems in orderto (i) identify redundancy in measures and (ii) minimize the costsof monitoring and diagnosing software projects, facilitating thetask of making measurements. As a result, we identified strongcorrelations between Halstead measures and other measures,mainly related to size such as quantity of methods, packages,attributes, etc. We also identified direct correlation of Halsteadmeasurements with coupling measures named Afferent and Effe-rent Coupling, with values ranging from 0.802 to 0.931, which arequite close to the maximum value 1 for a correlation. These resultsdemonstrate that—although there is no perfect correlation—thereis enough correlation to hypothesize that there is an overlap ofmeasures with different denominations whose measured resultsare equivalent.

Keywords—Metrics; software measures; Halstead; CorrelationAnalysis.

I. INTRODUÇÃO

Nas últimas décadas, tem-se proposto várias medidas desoftware [8], [1], [4], [6], [9], [2], [11], [12], [13], [16], [20],[30] e ferramentas de medição automatizadas [7], [19], [28].Uma medida (métrica), conforme IEEE [22], pode ser definidacomo “uma medição quantitativa do grau em que um sistema,componente ou processo possui um determinado atributo”. Taismedidas são indispensáveis nas organizações, pois fornecemmeios para que engenheiros de software possam mensurar,avaliar, controlar e melhorar produtos, projetos e/ou processosde software. Portanto, medidas de software são importantespara mensurar e acompanhar quantitativamente a qualidade deum software e sua evolução.

Com os custos de desenvolvimento e manutenção cres-centes, o interesse em ferramentas de medição que auxiliamna quantificação e análise da complexidade de sistemas de

software cada vez maiores [8] também se eleva. Por meiodas ferramentas, é possível obter informações como comple-xidade, testabilidade, manutenibilidade, legibilidade, eficácia,qualidade, funcionalidade, usabilidade etc.

Dentre as centenas de medidas existentes, este trabalho des-taca as Medidas de Halstead propostas por Maurice H. Hals-tead em 1977 [12]. Essas foram uma das primeiras medidas asurgirem e estão entre as mais conhecidas, sendo utilizadas porpesquisadores para avaliar sistemas de software e linguagensde consulta ou até mesmo na incorporação de medições emcompiladores [3]. Essas medidas são aplicáveis a códigos fonteindependentes da linguagem de programação. Apesar de tersido proposta há 50 anos, ela ainda continua sendo usada eestudada pela comunidade científica [18], [21], [17], [14]. Oobjetivo de Halstead era medir atributos do software comocomprimento, vocabulário, volume, dificuldade, erros e tempode teste. Além disso, essas medidas são usadas para se obteroutras características como o esforço de programação.

Com a vasta quantidade de medidas propostas ao longodos anos, correlacioná-las se torna uma tarefa importante,porque possibilitaria uma medida mais simples ser substituídapor outra mais complexa de se calcular, além de ser possívelidentificar medidas de software com comportamento similarese/ou valores aproximados. Reduzir o número de medidas desoftware existentes, identificando similaridade através da aná-lise de correlação é uma tarefa trabalhosa que demanda muitaanálise. No entanto, pode reduzir o trabalho do Engenheiro deSoftware que sente dificuldades em escolher dentre as centenasde medidas de software existentes.

Portanto, o objetivo deste artigo é apresentar uma análisede correlação entre as onze medidas de Halstead e outrasvinte e sete medidas propostas ao longo das décadas, a fimde minimizar os custos envolvidos no acompanhamento ediagnóstico de projetos de software, facilitando a própria tarefade realizar medições.

O restante do artigo está organizado como a seguir. NaSeção II, “Medidas de Software”, apresenta-se uma descriçãodas medidas de Halstead e de outras utilizadas na análise decorrelação. Na Seção III, “Estudo Empírico”, são expostas asquestões que esta pesquisa visa responder; os sistemas queforam utilizados para se obter os dados a serem analisados;uma explicação de como a análise de correlação é aplicada ea metodologia, contendo as etapas da pesquisa. Na Seção IV,

“Desenvolvimento”, é detalhado o processo da pesquisa. NaSeção V, “Resultados e Discussões”, apresentam-se os resul-tados da análise e discutem-se seus impactos. Na Seção VI,"Ameaças à validade", apresentam-se as ameaças à validadedo estudo e as ações adotadas para mitigá-las. Na Seção VII,“Estudos Relacionados”, é feita uma observação das principaispublicações relacionadas ao tema deste artigo. Na Seção VIII,“Conclusão”, tem-se as considerações finais.

II. MEDIDAS DE SOFTWARE

Em 1977, Halstead propôs suas medidas a fim de explicitarcaracterísticas do software baseados em valores obtidos poroperadores e operandos [12]. Contudo, não definindo valoresde referência ou valores-limite para elas. Apesar disso, suasmedidas se tornaram bastante populares e fazem parte devários estudos e constam em aplicações que realizam a análisede códigos. De modo geral, as medidas de Halstead têm oobjetivo de determinar medidas quantitativas e fornecer fortesindicadores de complexidade diretamente do código fonte.

Shen et al. [23] criticaram o trabalho de Halstead devidoà dificuldade em se definir e contar operandos e operadores,criticaram também a derivação de fórmulas, a validade dosdados experimentais, a fórmula para o tamanho, dentre outras.Entretanto, os autores destacaram as medidas propostas porHalstead como uma das únicas teorias completas que tentamexplicar o processo de desenvolvimento de programação. Sali-entaram a necessidade de se verificar mais detalhadamente asdeficiências teóricas que os autores apontaram.

Jensen et al. [15] concordaram com Shen et al. [23] emrelação à imprecisão da fórmula de Tamanho, mas reafirmaramque Volume e Esforço são indicadores razoáveis para o tama-nho do programa. Por outro lado, autores como Smith [24],acreditam que a medida do tamanho de um programa é válidae pode ser relacionada comprovadamente quando o vocabulárioé conhecido.

Apesar de haver críticas sobre as medidas de Halstead,este estudo mostrou haver correlações entre algumas medidasde Halstead e outras medidas. Além disto, ressalta-se que asmedidas de Halstead são independentes de paradigmas, estilosde programação e de tecnologias. Por isso, mesmo atualmentecom novas linguagens de programação com paradigmas distin-tos, não foram encontrados estudos que propõem novas versõesdas medidas de Halstead. As entradas utilizadas nas medidasde Halstead são o código fonte independente da linguagem emque foi programado. Para Halstead, um programa de compu-tador é a implementação de um algoritmo, considerando umacoleção de tokens que podem ser classificados como operandose operadores (Tabela I). A partir dessa consideração, Halsteadpropôs medidas baseadas nos operandos e operadores. Asmedidas propostas são vocabulário, comprimento (tamanho),volume, dificuldade, esforço, erros e tempo de teste, comomostra a Tabela II. Essas medidas são computadas estatica-mente por meio de quatro variáveis descritas na Tabela I.

Tabela I. VARIÁVEIS PROPOSTAS POR HALSTEAD

n1 Número de operadoresn2 Número de operandosN1 Número de operadores distintosN2 Número de operandos distintos

Tabela II. VARIÁVEIS PROPOSTAS POR HALSTEAD

Medida Sigla DescriçãoVocabulário n Essa é uma estimativa do tamanho do

vocabulário do programa (o número deelementos que devem ser conhecidospara entender o programa), uma espé-cie de léxico ou dicionário. É calculadopor [Número de Operadores Distintos] +[Número de Operandos Distintos].

Comprimento(tamanho)

N Essa é uma estimativa dotamanho do programa. É calculadapor [Número de Operadores] +[Número de Operandos].

Volume V Essa é uma estimativa do tamanho doprograma. Pode ainda ser vista comoo número de comparações mentais ne-cessárias para escrever um programade comprimento N. É calculada por[Comprimento] ∗ log2([Vocabulário]).

Dificuldade D Essa medida é calculada por ([Númerode operadores distintos]/2) ∗ ([Númerode operandos] / [Número de OperandosDistintos]).

Esforço E Essa medida é utilizada para se prevero custo de desenvolvimento do software.Pode ainda ser entendido como o esforçonecessário para se compreender um pro-grama. É calculada por [Dificuldade] ∗[Volume].

Erros B Essa é uma estimativa de erros. É calcu-lada por [Volume]/3000.

Tempo deteste

T Essa é uma estimativa para o tempo detestes. É a habilidade de relacionar asmedidas básicas ao tempo real de exe-cução. É calculada por [Esforço]/k. emque k tem o valor constante 18. Essaconstante é conhecida como Número deStroud e significa o número de decisõeselementares por segundo.

A. Outras medidas

As outras medidas utilizadas na análise de correlação comas medidas de Halstead, são definidas na Tabela III. A tabeladetalha cada uma das medidas conforme documentação doGoogle CodePro Analytix1 que as agrupam como medidasbásicas, de complexidade, de herança, de proporção e dedependência. O objetivo é tentar correlacionar medidas deHalstead com medidas de software populares, tais como asimplementadas pela ferramenta supracitada. Embora correlaci-onar alguns pares de medidas (e.g., tamanho do código commétricas de hierarquia) podem não fazer sentido, optou-sepor correlacionar todos os possíveis pares de medidas paraconfirmar tais sensos comuns. A motivação é verificar – inde-pendente da categoria – se um conjunto de medidas poderia sersubstituído por uma única. Para facilitar futuramente a escrita,foram criadas siglas baseadas no nome original em inglês.

1CodePro Analytix 7.1.0, http://developers.google.com/java-dev-tools

Tabela III. MEDIDAS DE COMPLEXIDADE UTILIZADAS NA ANÁLISE

MEDIDAS BÁSICAS

Média de linhasde código pormétodo (ALCM)

Essa é a média do número de linhas de código emcada método definido no código fonte. Essa medidainclui detalhes dos números mínimo e máximo delinhas de código em qualquer método.

Média do númerode construtorespor tipo (ANCT)

Essa é a média do número de construtores definidospor cada tipo definido no código fonte. Essa medidainclui detalhes dos números mínimo e máximo deconstrutores definido por um tipo.

Média do númerode campos (atri-butos) por tipo(ANFT)

Essa é a média do número de campos (atributos)definidos para cada tipo definido no código fonte.Essa medida inclui detalhes dos números mínimo emáximo de campos definidos por um tipo.

Média do númerode métodos portipo (ANMT)

Essa é a média do número de métodos definidospara cada tipo no código fonte. Essa medida incluidetalhes dos números mínimo e máximo de métodosdefinidos por um tipo.

Média do númerode parâmetros(ANP)

Essa é a média do número de parâmetros definidospara métodos (não construtores) definidos no códigofonte. Essa medida inclui detalhes dos númerosmínimo e máximo de parâmetros definidos por ummétodo. Também provê detalhes sobre o número demétodos de cada tamanho particular.

Linhas de código(LOC)

Essa é uma contagem do número de linhas no códigofonte que possua caracteres diferentes de espaços embranco e comentários.

Número decaracteres(NCHAR)

Essa é uma simples contagem do número de carac-teres no código fonte. O código fonte associado àmedição pode conter algum comentário Javadoc.

Número decomentários(NCOM)

Essa é uma simples contagem do número de co-mentários. Não é a contagem do número de linhasque contenham comentários; comentários de múlti-plas linhas são contados como uma única linha nãoimportando quantas linhas eles ocupam. Essa medidaé dividida pelo tipo de comentário: fim de linha,múltiplas linhas e Javadoc.

Número de cons-trutores (NCT)

Essa é uma contagem do número de construtoresdefinidos no código fonte. Essa medida inclui umadivisão baseada na visibilidade do construtor (pú-blico, pacote, protegido ou privado).

Númerode campos(atributos) (NOF)

Essa é uma contagem do número de atributos no có-digo fonte. Essa medida inclui uma divisão baseadatanto no escopo do atributo (estático ou instância)quanto a visibilidade do atributo (público, pacote,protegido ou privado).

Número de linhas(NOL)

Essa é uma simples contagem do número de linhasdo código fonte, incluindo linhas em branco.

Número de méto-dos (NOM)

Essa é uma contagem do número de métodos defini-dos no código fonte. Essa medida inclui uma divisãobaseada tanto no escopo do método (estático ouinstância) quanto na visibilidade do método (público,privado, pacote ou protegido).

Número de paco-tes (NOP)

Essa é a contagem do número de pacotes definidosno código fonte.

Número depontos e vírgulas(NOSC)

Essa é uma simples contagem do número de pontose vírgulas no código fonte. Pontos e vírgulas emcomentários não são contados, mas são contabiliza-dos os pontos e vírgulas do final do pacote e emdeclarações de importação.

Número de tipos(NT)

Essa é uma contagem baseada no número de tiposdefinidos no código fonte. Essa medida inclui umadivisão baseada na definição do tipo ser uma classeou uma interface.

MEDIDAS DE COMPLEXIDADE

Média da profun-didade do bloco(ABD)

Essa é a média da máxima profundidade do blocode cada um dos métodos definidos no código fonte.

MEDIDAS DE HERANÇA

Média da profun-didade da hierar-quia de herança(ADIH)

Essa é a média da profundidade de tipos definidosno código fonte. A profundidade de uma interface édefinida para ser um (1). A profundidade da classejava.lang.Object é definida para ser um (1). Aprofundidade de qualquer outra classe é definida paraser uma unidade a mais que a profundidade de suasuperclasse.

Média do númerode subtipos(ANS)

Essa é a média do número de subtipos para os tiposdefinidos no código fonte.

MEDIDAS DE PROPORÇÃO

Proporção de co-mentários (CR)

Essa é a razão dos comentários pelonúmero de linhas de código. Especifica-mente, é calculada da seguinte maneira:[Número de comentários]/[Linhas de Código].

Média da com-plexidade ciclo-mática (ACC)

Essa é a média da complexidade ciclomática de cadamétodo definido no código fonte. A complexidadeciclomática de um único método é a medição donúmero de caminhos distintos de execução pelométodo. É medida se adicionando um caminho únicodo método com cada caminho criado por estruturascondicionais (tais como if e else) e operadores(como o ternário).

Métodos ponde-rados (WM)

Essa é a soma da complexidade ciclomática decada um dos métodos definidos no código fonte.A complexidade ciclomática de um único métodoé a medição do número de caminhos distintos deexecução com o método. É medida se adicionandoum caminho único do método com cada caminhocriado por estruturas condicionais (tais como if eelse) e operadores (como o ternário).

MEDIDAS DE DEPENDÊNCIA

Abstração (ABS) Essa é a razão entre o número de tipos abstratos(classes abstratas e interfaces) e o número totalde tipos no código fonte. Essa medida inclui umadivisão baseada em se o tipo é abstrato ou concreto.

Acoplamentoaferente (CA)

Esse é o número de tipos fora do alvo da mediçãoque dependem de tipos dentro do mesmo.

Distância (DIST) Essa é a distância normalizada do código da sequên-cia principal. A distância normalizada é calculadapor [Abstração] + [Instabilidade]− 1.

Acoplamentoeferente (CE)

Esse é o número de tipos dentro do código fonte quedepende de tipos fora do mesmo.

Instabilidade(INST)

Essa medida corresponde à instabilidade no códigofonte. A instabilidade é calculada por [AcoplamentoEferente] / ([Acoplamento Aferente] + [AcoplamentoEferente]).

III. ESTUDO EMPÍRICO

A. Questões de Pesquisa

As questões a serem respondidas neste artigo são:

• Há correlação entre as medidas de Halstead e cadauma das outras medidas?

Nesse caso, analisa-se a correlação de cada medida deHalstead com as demais medidas. Por exemplo, analisa-se acorrelação entre as medidas Volume (Halstead) e LOC, Volumee Acoplamento Aferente, Comprimento e LOC, Comprimentoe Acoplamento Aferente e assim sucessivamente para todos ospares de medidas de Halstead e as demais medidas.

• Havendo correlação, essa é considerada forte ou fraca?

Baseando-se na teoria e em intervalos presentes na litera-tura, mede-se o quão intensa é a correlação.

B. Sistemas alvo

Os sistemas utilizados para coleta das medidas foramdesenvolvidos em Java e transferidos do Qualitas.class Cor-pus [29], que é uma versão de 111 projetos compilados dediferentes domínios e aplicações do Qualitas Corpus [27].Esses sistemas compõem um benchmark usado em estudosempíricos de artefatos de software.

C. Análise de Correlação

Para verificar a correlação entre cada par de medidas,utiliza-se tradicionalmente a correlação de Pearson para dis-tribuição normal ou de Spearman em caso contrário.

Independente da correlação aplicada, deve-se estabelecer oscritérios para se determinar a magnitude de uma correlação.Alguns estudos que investigam a existência de correlação entreelementos a classificam de três maneiras: baixa, moderadaou alta. Quando se pressupõe a relação existente entre oselementos e há o interesse em quantificar a magnitude dessarelação, alguns intervalos são propostos como em Succi etal. [26]. Neste trabalho de pesquisa, apenas as correlaçõesclassificadas como altas segundo o critério de Succi foramanalisadas e discutidas.

D. Metodologia

A metodologia do trabalho estruturou-se em cinco etapasdetalhadas a seguir.

A. Selecionar ferramenta de medição: Nessa etapa,realizou-se o levantamento das ferramentas que cal-culam as Medidas de Halstead e outras medidas desoftware.

B. Selecionar sistemas: Nessa etapa, realizou-se o levanta-mento do conjunto de sistemas a serem analisados. Essaetapa é influenciada pela etapa anterior, pois os sistemasselecionados devem ser compatíveis com a ferramentaescolhida.

C. Coletar dados: Nessa etapa, realizou-se a aplicação daferramenta escolhida nos sistemas selecionados na etapaanterior.

D. Análise de correlação: Nessa etapa realizaram-se aná-lises estatísticas sobre os dados coletados.

E. Análise e discussão dos dados: Nessa etapa, os resul-tados obtidos com a etapa anterior foram analisados ediscutidos.

IV. DESENVOLVIMENTO

A. Selecionar ferramentas de medição

Para selecionar a ferramenta utilizada na medição dossistemas, foi realizada uma busca pelas principais ferramentasque calculassem as Medidas de Halstead e fossem compatíveiscom a plataforma em que a medição fosse realizada. Dessaforma, encontrou-se: JHawk 6, Krakatau Essential Metrics,Halstead Metrics Tool, Prest e Google CodePro Analytix 7.1.0.

A JHawk 6 e a Krakatau Essential Metrics são ferramentaspagas para acesso ilimitado e por isso foram descartadas daseleção. A ferramenta Krakatau é incompatível com o sistemaoperacional da máquina em que foram feitas as medições.Halstead Metrics Tool e Prest são gratuitas, calculam asmedidas de Halstead, mas dispõem de pouca quantidade deoutras medidas.

Definiu-se então, o plug-in Google CodePro Analytix comoa melhor opção. Os motivos dessa escolha foram a gratuidade,a compatibilidade com o sistema operacional, a facilidade deuso (concomitante ao IDE Eclipse) e principalmente por disporda maior quantidade de medidas, calculando Halstead e váriasoutras (38 no total).

B. Selecionar sistemas

Com a definição da ferramenta, o próximo passo foi coletaros sistemas a serem analisados. Como o CodePro Analytixexecuta em conjunto com o IDE Eclipse, estabeleceu-se que ossistemas deveriam ser códigos escritos em linguagem Java. As-sim, realizou-se uma pesquisa por plataformas que reunisseme disponibilizassem sistemas de código aberto, encontrando oQualitas Corpus. Essa plataforma é uma coleção de sistemasdestinados a serem usados em estudos empíricos de artefatosde software.

Uma vez que importar e compilar o código fonte nãoé uma tarefa trivial quando se tem sistemas com muitasdependências, encontrou-se o Qualitas.class Corpus que é umaversão do Qualitas Corpus, mas fornecendo 111 sistemas Javajá compilados, reduzindo esforços.

Com a amostra definida, a etapa seguinte foi estabelecer umlimite de tamanho dos sistemas, já que o esforço da máquinade teste poderia impor limitações ao desempenho. Assim,o limite escolhido foi de 900.000 linhas de código. Alémdisso, sistemas com mais de um projeto foram excluídos daanálise, por tornarem a medição mais complexa. Dessa forma,a amostra original se reduziu em um total de 97 sistemasreportados na Tabela IV.

C. Coletar dados

Além dos sistemas, o Qualitas.class fornece também umdocumento contendo resultados de medições para os mesmos.

Tabela IV. SISTEMAS ANALISADOS

Projeto Versão Projeto Versão

1. ant 1.8.2002 50. jhotdraw 7.5.2001

2. antlr 3.4 51. jmeter 2.5.2001

3. aoi 2.8.2001 52. jmoney 2000.4.4

4. argouml 0.34 53. joggplayer 1.1.4s

5. axion 1.0-M2 54. jparse 0.96

6. azureus 4.7.0.2 55. jpf 1.5.2001

7. c jdbc 2.0.2 56. jrefactory 2.9.19

8. cayenne 3.0.1 57. jruby 1.7.3*

9. checkstyle 5.6* 58. jsXe 04 beta

10. cobertura 1.9.4.1 59. jspwiki 2.8.2004

11. collections 3.2.2001 60. jtopen 7.8*

12. colt 1.2.2000 61. jung 2.0.1

13. compiere 330 62. junit 4.1

14. derby 10.9.1.0* 63. log4j 2.0-beta*

15. displaytag 1.2 64. lucene 4.2.0*

16. drawswf 1.2.2009 65. marauroa 3.8.2001

17. drjava 20100913-r5387 66. maven 3.0.5*

18. emma 2.0.5312 67. megamek 0.35.18

19. exoportal 1.0.2 68. mvnforum 1.2.2-ga

20. findbugs 1.3.2009 69. nakedobjects 4.0.0

21. fitjava 1.1 70. nekohtml 1.9.14

22. fitlibraryforfitnesse20110301* 71. openjms 0.7.7-beta-1

23. freecol 2000.10.3 72. oscache 2.3*

24. freecs 1.3.20100406 73. picocontainer2.10.2002

25. freemind 0.9.0 74. pmd 4.2.2005

26. galleon 2.3.2000 75. poi 3.6

27. ganttproject 2.1.1* 76. pooka 3.0-080505

28. hadoop 1.1.2* 77. proguard 4.9*

29. heritrix 1.14.4 78. quartz 1.8.2003

30. hibernate 4.2.0* 79. quickserver 1.4.2007

31. hsqldb 2.0.0 80. quilt 0.6-a-5

32. htmlunit 2.8 81. roller 5.0.1*

33. informa 0.7.0-alpha2 82. rssowl 2.0.5

34. ireport 3.7.2005 83. sablecc 3.2

35. itext 5.0.3 84. sandmark 3.4

36. jag 6.1 85. squirrel sql 3.1.2002

37. jasml 0.1 86. struts 2.2.2001

38. jasperreports 3.7.4* 87. sunflow 2000.07.02

39. javacc 5 88. tapestry 5.1.0.5

40. jboss 5.1.2000 89. tomcat 7.0.2

41. jchempaint 3.0.1 90. trove 2.1.2000

42. jedit 4.3.2002 91. velocity 1.6.2004

43. jena 2.6.2003 92. wct 1.5.2002

44. jext 5 93. webmail 2000.7.10

45. jfreechart 1.0.13 94. weka 3.6.9*

46. jgraph 5.13.0.0 95. xalan 2.7.2001

47. jgraphpad 5.10.0.2 96. xerces 2.10.2000

48. jgrapht 2000.8.1 97. xmojo 5.0.0

49. jgroups 2.10.2000

Tais resultados foram obtidos de coletas usando duas ferra-mentas, sendo uma delas a própria CodePro Analytix. Noentanto, dentre as medidas oferecidas pelo documento não sãoentregues as de Halstead. Por isso, optou-se por realizar novamedição nos códigos compilados, contendo todas as medidasque uma única ferramenta contemplasse.

Nessa etapa, aplicou-se a medição do Google CodeProAnalytix nos 97 sistemas escolhidos, mantendo-se os parâme-tros padrões. Essa ferramenta realiza computa as medidas pormeio de análise estática do código.

D. Análise de Correlação

Para verificar se há relação entre cada uma das medidasde Halstead e cada uma das outras, calculou-se o coeficientede correlação de Spearman para cada par de medidas. Aescolha desse coeficiente se deu devido à amostra não ser umadistribuição normal, necessitando de testes não paramétricos. Ocoeficiente de Spearman não utiliza o valor das observações,mas sim a ordem das observações, o que o torna imune aassimetrias, não exigindo que os dados sejam modelados poruma distribuição normal [10].

O coeficiente de Spearman varia de [−1,+1], sendo ossinais positivo e negativo, os indicativos da direção da relação.A relação positiva (+) significa que quando a variável inde-pendente cresce, a variável dependente também cresce. A regratambém vale do contrário: quando a variável independentedecresce, a variável dependente tem o mesmo comportamento.Por sua vez, a relação negativa (−) indica que quando avariável independente cresce, a variável dependente decresceou vice-versa. A correlação perfeita, isto é, contendo os valoresextremos é rara, por isso valores que mais se aproximam aoslimites, são levados em maior consideração. Ainda, o valor 0aponta a ausência de correlação e quanto mais próximo a ele,menor é a correlação.

O cálculo do coeficiente foi feito com auxílio da lingua-gem R. A tabela inicial contendo os dados brutos foi exportadapara o formato CSV e através de um script contendo a funçãodo cálculo de Spearman. A função em questão é a funçãocor do pacote stats. A função é calculada passando-se comoparâmetros os dados a serem correlacionados e especificando-se o coeficiente de correlação. Obteve-se o valor da correlaçãopara 297 testes (referentes às 11 medidas de Halstead e às 27outras medidas).

E. Análise e discussão dos dados

Para se compreender como os valores do coeficiente decorrelação de Spearman (r) afetam a amostra, primeiramentedeve-se analisar os valores críticos de significância (α) para serejeitar a hipótese nula, isto é, confirmar a hipótese alternativade que realmente existe relação entre as variáveis. É facilmenteencontrado na literatura tabelas que fornecem os valores crí-ticos já calculados de acordo com o tamanho da amostra. Nocaso deste estudo, a amostra contém 97 sistemas e para estaquantidade, com α = 0,025 e α = 0,05, o r resulta 0,199, oque já indicaria a existência de correlação entre a maioria dasmedidas.

Este trabalho de pesquisa propõe identificar correlaçõesfortes, ou seja, valores que mais se aproximam dos limites do

intervalo [−1, 1]. Assim, buscou-se na literatura intervalos quecomumente correspondem a um alto grau de correlação. Succiet al., por exemplo, classifica a correlação de três maneiras:

(i) r < 0.499 (correlação baixa)

(ii) 0.500 ≤ r < 0.799 (correlação moderada)

(iii) r > 0.800 (correlação alta)

Desse modo, apenas as correlações classificadas como altassegundo o critério proposto por Succi et al. foram discutidase analisadas.

V. RESULTADOS E DISCUSSÕES

As medidas de Halstead se referem principalmente aotamanho do código. Suas principais variáveis, números deoperadores e operandos utilizados para calcular as outrasmedidas, comprovam a intenção de se descobrir aspectos docódigo baseando-se em seu tamanho.

Após a realização dos testes e da aplicação do coeficientede correlação de Spearman, constatou-se como esperado queas medidas de Halstead possuem as correlações mais fortescom outras medidas que também dizem respeito ao tamanho,como é possível se observar no mapa de calor (Figura 1).

Considerando os resultados em que o coeficiente de corre-lação é maior ou igual a 0.800, as medidas Linhas de Código,Número de Caracteres, Número de Comentários, Número deConstrutores, Número de Campos (Atributos), Número deLinhas, Número de Métodos, Número de Pontos e Vírgulasapresentaram alta correlação direta com as seguintes medidasde Halstead: Comprimento, Erros, Esforço, Número de Ope-randos, Número de Operadores, Número de Operandos Distin-tos, Vocabulário e Volume. Tais medidas tratam exclusivamenteda contagem de algum aspecto do código (linhas, caracteres,etc.) e, de maneira clara, com seus valores aumentados progres-sivamente, aumentam-se as chances de possuírem os operandose operadores definidos por Halstead.

Observa-se por exemplo, que quanto maior o número delinhas de código, maior a possibilidade de conter operandose operadores e, portanto, a correlação entre as duas medidasé direta. Registrou-se ainda forte correlação dessas medidasde Halstead com Acoplamento Aferente (Ca) e AcoplamentoEferente (Ce). Em seus cálculos, Ca e Ce utilizam a quantidadede tipos que dependem de outros dentro ou fora da classe. Parase obter valores de acoplamento, operadores que caracterizamessa dependência são utilizados pelas linguagens orientadas aobjeto, como é o caso de Java e, por isso, a alta correlação entreesses pares. Considerando-se o excessivo acoplamento comoum ponto negativo no código, os altos valores das medidasde Halstead podem por exemplo indicar características do quese conhece como “bad code smell”, ou seja, indícios de umdesign que deve ser evitado e que muitas vezes é indicadopelos resultados de Ca e Ce, talvez mais complexos de secalcular comparando-se a um simples Número de Operadores,por exemplo. A complexidade explicitada por uma combinaçãode medidas Ca, Ce e Halstead podem indicar que o código éum forte candidato a um processo de refatoração.

Métodos Ponderados é outra medida em que se identificoualta correlação com as medidas de Halstead supracitadas. Essa

medida é a soma da complexidade ciclomática de cada métododefinido no código analisado. A complexidade ciclomática, porsua vez, é a medida do número de caminhos de execuçãodistintos criados por estruturas condicionais e por operadores.

Apenas três das medidas de Halstead não registraramvalores de alta correlação: Dificuldade, Número de OperadoresDistintos e Tempo de Teste. Apesar de o Número de Operado-res possuir valores altos de correlação, de maneira estranha oNúmero de Operadores Distintos, isto é, o total de ocorrênciasde cada tipo de operador, não obteve valores consideravelmentealtos de correlação. Talvez, por uma questão de linguagem, avariedade desses operadores tenha sido pequena, já que todosos códigos utilizados na análise foram escritos na linguagemJava. A Dificuldade é uma fórmula na qual um de seus ele-mentos é o Número de Operadores Distintos e provavelmenteisso explica a baixa correlação encontrada para essa medidatenha afetado diretamente os seus coeficientes de correlação.No caso do Tempo de Teste, os resultados foram extremamentebaixos, não possuindo correlações consideráveis com nenhumadas outras medidas.

A principal conclusão deste trabalho é de que todo par demedidas que apresentou correlação acima de 90% tornou-seum forte candidato a receber outras análises e investigações, afim de confirmar a redundância/similaridade de medições que,poderiam ser – de alguma forma – substituídas por apenas umamedida equivalente.

VI. AMEAÇAS À VALIDADE

Alguns sistemas Java disponibilizados pelo Qualitas.classapresentaram erro de dependência quando foram importa-dos para o IDE Eclipse, mesmo ambiente utilizado peloQualitas.class para coleta de dados. Os sistemas referidossão: Cayenne, Derby, Drjava, Fitlibrary, Hadoop, Hibernate,iReport, JBoss, JFreeChart, JREFactory, Jung, Quilt, Rssowl,Smark3, Tomcat e Velocity. Os erros, em sua maioria, foramcorrigidos com a mudança da versão da JRE. Em outros casos,classes tiveram de ser importadas e pequenas mudanças nocódigo foram realizadas, o que poderia impactar de algumaforma nos resultados das medições desses 16 sistemas. Porém,as alterações foram pontuais como, por exemplo, comentaruma chamada de método inexistente ou cuja biblioteca nãofoi possível encontrar.

Outro ponto a ser destacado se refere ao processo de medi-ção. A ferramenta Google CodePro Analytix provê o resultadogeral de cada medida e, também, a opção de visualizar o valorda medida detalhada por classes. Excepcionalmente, no casoda medida Acoplamento Aferente, o resultado geral forneciao valor 0 ou outro que não correspondia ao somatório dossubvalores contidos nas classes como nos sistemas Joggplayer,nakedobjects, quartz, argouml, freecol, htmlunit, javacc, jena,jext, lucene, struts, weka, jgraphpad, jhotdraw, jruby, cayenne,sandmark, hibernate e hadoop. A equipe de pesquisa decidiu,então, descartar o valor apresentado pela ferramenta e optoupor somar os valores de cada classe e adotar o somatóriocomo o resultado para a medida posta sob dúvida. No casoda medida Acoplamento Aferente, além do somatório, adotou-se também uma outra medida que corresponde à média doAcoplamento Aferente das classes. O Acoplamento Aferente esua média apresentaram alta correlação na análise, considerada

-1

-0.8

-0.6

-0.4

-0.2

0

0.2

0.4

0.6

0.8

1

Abstração

Aco

pla

me

nto

afe

ren

te

Mé

dia

do

aco

pla

me

nto

afe

ren

te

Mé

dia

da

pro

f. d

o b

loco

Mé

dia

Co

mp

l. C

iclo

má

tica

Mé

dia

da

pro

f. d

a h

iera

rqu

ia d

e h

era

nça

Mé

dia

de

lin

ha

s d

e c

ód

igo

po

r m

éto

do

Mé

dia

do

nú

me

ro d

e c

on

stru

tore

s p

or

tipo

Mé

dia

do

nú

me

ro d

e c

am

po

s (a

trib

uto

s) p

or

tipo

Mé

dia

do

nú

me

ro d

e m

éto

do

s p

or

tipo

Mé

dia

do

nº

de

pa

râm

etr

os

Mé

dia

do

nº

de

su

btip

os

Pro

po

rçã

o d

e c

om

en

tário

s

Distância

Aco

pla

me

nto

efe

ren

te

Instabilidade

Lin

ha

s d

e c

ód

igo

Nº

de

ca

ract

ere

s

Nº

de

co

me

ntá

rio

s

Nº

de

co

nst

ruto

res

Nº

de

ca

mp

os

(atr

ibu

tos)

Nº

de

lin

ha

s

Nº

de

mé

tod

os

Nº

de

pa

cote

s

Nº

de

po

nto

s e

vír

gu

las

Nº

de

tip

os

Mé

tod

os

po

nd

era

do

s

Comprimento

Dificuldade

Erros

Esforço

Nº operadores distintos

Nº operadores

Nº operandos distintos

Nº operandos

Vocabulário

Volume

Tempo de teste

-0.07

0

-0.05

-0.06

-0.08

-0.08

-0.07

-0.07

-0.08

-0.07

0.03

0.89

0.59

0.86

0.87

0.88

0.56

0.9

0.88

0.89

0.89

0.01

0.58

0.54

0.54

0.58

0.58

0.42

0.58

0.53

0.53

0.57

-0.03

0.09

0.22

0.09

0.11

0.11

0.11

0.09

0.05

0.04

0.09

0.03

0.18

0.25

0.15

0.21

0.21

0.32

0.17

0.13

0.12

0.18

0.01

0.19

0.16

0.17

0.19

0.19

0.12

0.18

0.16

0.17

0.19

-0.27

0.18

0.2

0.14

0.19

0.19

0.2

0.16

0.13

0.13

0.17

0.05

-0.05

0.21

-0.02

-0.02

-0.04

0.11

-0.05

-0.1

-0.12

-0.05

0.04

0

0.05

0.01

0

0.03

0.11

-0.01

-0.02

-0.03

0

0.08

0.24

0.31

0.27

0.25

0.25

0.2

0.24

0.19

0.19

0.24

-0.07

0.07

0.18

0.07

0.09

0.05

0.24

0.06

0.04

0.03

0.06

0.05

0.18

0.2

0.22

0.2

0.18

0.16

0.19

0.18

0.19

0.19

-0.09

0.01

0.11

-0.02

0.03

0.01

-0.02

0.01

-0.05

-0.05

0.01

0.1

-0.02

0.06

-0.01

0

-0.03

-0.05

-0.02

-0.04

-0.04

-0.02

0.1

0.92

0.55

0.89

0.89

0.91

0.58

0.93

0.93

0.93

0.92

0.02

-0.58

-0.47

-0.56

-0.57

-0.56

-0.4

-0.59

-0.55

-0.55

-0.58

0.03

0.99

0.69

0.95

0.97

0.99

0.66

0.99

0.96

0.97

0.99

0.05

0.98

0.66

0.95

0.96

0.97

0.66

0.98

0.96

0.97

0.98

0.06

0.9

0.56

0.87

0.88

0.89

0.64

0.9

0.9

0.91

0.9

0.1

0.95

0.67

0.92

0.93

0.94

0.64

0.95

0.92

0.92

0.95

0.08

0.97

0.63

0.94

0.94

0.97

0.69

0.97

0.96

0.97

0.97

0.05

0.98

0.66

0.95

0.96

0.97

0.65

0.98

0.96

0.96

0.98

0.05

0.97

0.64

0.94

0.95

0.96

0.62

0.97

0.95

0.96

0.97

0.04

0.7

0.38

0.71

0.66

0.68

0.42

0.71

0.72

0.72

0.71

-0.02

1

0.7

0.96

0.98

0.99

0.67

1

0.96

0.97

1

0.06

0.92

0.58

0.89

0.9

0.91

0.58

0.92

0.92

0.92

0.92

0.04

0.99

0.72

0.95

0.98

0.99

0.68

0.98

0.95

0.95

0.98

0.06

Figura 1. Mapa de calor dos resultados de todas as correlações entre as medidas de software analisadas

uma correlação descartável, pois uma medida foi o somatórioe a outra medida a média, o que matematicamente resultaráem correlação.

VII. ESTUDOS RELACIONADOS

Zuse [31] considera as medidas de Halstead um assuntomisterioso. Usando o conceito de estrutura extensiva da teoriade medição (axiomas ou condições qualitativas) para investigara fundo as medidas de Halstead, Zuse conclui que o mesmonão conhecia a teoria de medição a fundo e, por essa razão,Halstead não saberia da dificuldade em se explicar, por exem-plo, que a medida Volume muda sua estrutura de medição ea escala depende da estrutura e do tamanho do programa (daescala de razão para a escala ordinal e novamente para a escalade razão).

Para Sommerville [25], o método de Halstead não é capazde medir a estrutura do código, a herança e a interaçãoentre módulos. As medidas podem ser melhoradas atravésda criação de novos parâmetros para a medição. De acordocom Al-Qutaish [3], há um problema em distinguir operandose operadores porque Halstead não se utilizou de definiçõesgenéricas para qualquer contexto de programa. Isto é, Halsteadnão descreveu de maneira explícita os conceitos mensuráveis

de operandos e operadores. Pesquisadores propõem sua própriainterpretação ou utilizam estratégias propostas por outros. As-sim, é esperado que diferentes estratégias de contagem venhama produzir diferentes quantidades de operandos e operadores.

Relacionado às questões de cálculo das medidas de Hals-tead, Jensen et al. [15] propuseram uma nova fórmula para otamanho do programa, após revisar as definições das medidasde software, que se mostrou uma melhor aproximação para osdados obtidos de sistemas de tempo real por eles estudados.

Uma das hipóteses de Halstead sugeriu que o Volume([Comprimento]∗ log2([Vocabulário])) é fortemente correlacio-nado à quantidade de erros (Volume]/3000). Entretanto, Baileyet al. [5] indicaram que erros de software não resultam emuma função linear com a medida de volume, sendo resultadode outros fatores além dos que compõem a fórmula de volume.

Shen et al. [23] criticaram o trabalho de Halstead devidoà dificuldade em se definir e contar operandos e operadores,criticaram também a derivação de fórmulas, a validade dosdados experimentais, a fórmula para o tamanho, dentre outras.Entretanto, destacaram as medidas propostas por Halsteadcomo uma das únicas teorias completas que tentam explicar oprocesso de desenvolvimento de programação. Salientaram a

necessidade de se verificar mais detalhadamente as deficiênciasteóricas que os autores apontaram.

Jensen et al. [15] concordaram com Shen et al. [23] emrelação à imprecisão da fórmula de Tamanho, mas reafirma-ram que Volume e Esforço são indicadores razoáveis para otamanho do programa. Por outro lado, autores como Smith [24]acreditam que a medida do tamanho de um programa é válida epode ser relacionada comprovadamente quando o vocabulárioé conhecido.

Apesar de haver críticas sobre as medidas de Halstead,este estudo mostrou haver correlações entre algumas medidasde Halstead e outras medidas. Além disto, ressalta-se queas medidas de Halstead são independentes de paradigmas,estilos de programação e de tecnologias. Se for consideradoque atualmente nossa sociedade está envolvida em centenas delinguagens de programação novas sendo propostas frequente-mente, os autores deste artigo acreditam que a comunidadecientífica e tecnológica deva considerar um novo olhar sobreas medidas de Halstead e um aprofundamento do estudo delasdeveria ser refeito, a fim de verificar o real potencial de usodessas medidas. Prover para a comunidade científica e tecnoló-gica medidas independentes de tecnologia, propiciando estudoscomparativos entre projetos diferentes tecnologicamente.

VIII. CONCLUSÃO

O objetivo deste trabalho foi realizar uma análise decorrelação entre onze medidas de Halstead e outras vinte esete medidas de software presentes na indústria e na literatura,a fim de minimizar os custos envolvidos no acompanhamentoe diagnóstico de projetos de software, facilitando a própriatarefa de realizar medições.

Para consecução deste objetivo, 97 sistemas – totalizandomais de 107.662 classes e 10.041.100 linhas de código –tiveram suas medidas coletadas durante o período de doismeses e uma análise de correlação de Spearman foi realizadaapós a obtenção dos dados.

Descobriu-se que as medidas Número de operadores, Nú-mero de Operandos, Número de Operandos Distintos, Com-primento, Erros, Esforço, Vocabulário e Volume apresentaram,cada uma, alta correlação com as seguintes medidas: Acopla-mento Aferente, Acoplamento Eferente, Linhas de Código,Número de Caracteres, Número de Comentários, Númerode Construtores, Número de Campos (atributos), Número deLinhas, Número de Métodos, Número de Pontos e Vírgulas,Número de Tipos e Métodos Ponderados.

A principal conclusão deste trabalho é de que a maioriados pares de medidas possuem correlação forte. Novas análisese investigações devem ser conduzidas, principalmente para ospares de medidas com correlação acima de 90% para confirmaro resultado. Além disso, é necessário avaliar o impacto quepoderia ocorrer na gerência de projetos de software ao sesubstituir dez medidas por apenas uma, considerando que sãoaltamente correlacionadas, induzindo a existência de redun-dância de informação. Para isso, entretanto, pretende-se comotrabalho futuro prover uma investigação estatística mais focadaa fim de definir uma ordem de importância das medidas ou deprover um diagrama de relação entre as medidas.

Embora possuindo correlação alta e sua respectiva substi-tuição possa parecer óbvia, como é o caso do par Número deOperadores e Linhas de Código, é importante notar algumassutilezas. Na indústria de desenvolvimento de software, di-ferentes organizações adotam diferentes estruturas de código.Um mesmo código, em uma mesma linguagem pode, porexemplo, possuir LOC diferentes, dependendo da maneira peloqual foi implementado. Por ser independente de linguagem eimplementação, Halstead produziria os mesmos valores parasas contagens de operadores e operandos e consequentementepara as outras medidas. E uma vez que um código podeconter um número consideravelmente grande de linhas, usaralguma medida de Halstead para atestar esse quesito podeser menos custoso no processo de medição. Talvez essa sejaa grande contribuição de Halstead: minimizar os custos dedesenvolvimento baseando-se em indicadores quantitativos.

Como trabalhos futuros, recomenda-se investigar a fundoa correlação para a medida Número de Operadores Distintos.Nesta pesquisa, a correlação encontrada para tal foi baixa.Ao contrário do que se esperava, uma vez que a correlaçãopara o Número de Operadores foi alta. Outra recomendaçãoé encontrar thresholds para as medidas, o que traria umamelhoria no diagnóstico de problemas relacionados a esforço ecusto de desenvolvimento para as organizações. É importanteressaltar que deve-se definir qual o fator de qualidade deseja-seavaliar e o que significa qualidade no contexto desejado, o quesignifica um código fácil de se avaliar e manter. Em suma, éimportante definir bem os objetivos para que a medição tenhasentido e a partir daí verificar quais medidas utilizar e quaispodem ser simplificadas, suprimidas ou substituídas.

Outra recomendação é relacionada à visualização de me-dições. Uma barreira na criação de código com qualidade ouum bom design é a dificuldade em enxergar o todo. De modogeral, os profissionais da área estão restritos à visão que oeditor de código fornece ou que relatórios textuais informam.São poucas as opções de visualização abstrata mais adequada ede mais alto nível de medição software, que poderiam produzirindicadores importantes da qualidade do código. As medidasestão relacionadas com o código, sua qualidade, reflete tambéma qualidade do processo de desenvolvimento e manutenção,podendo ser grande aliada do arquitetos, engenheiros e pro-gramadores de software.

Agradecimentos: Esse trabalho foi apoiado pela CNPq, CA-PES e FAPEMIG.

REFERÊNCIAS

[1] Fernando Brito Abreu and Rogério Carapuça. Object-oriented softwareengineering: Measuring and controlling the development process. In4th International Conference on Software Quality, pages 1–8, 1994.

[2] Jehad Al Dallal and Lionel C Briand. A precise method-methodinteraction-based cohesion metric for object-oriented classes. ACMTransactions on Software Engineering and Methodology, 21(2):1–34,2012.

[3] Rafa E Al Qutaish and Alain Abran. An analysis of the design anddefinitions of halstead’s metrics. In 15th International Workshop onSoftware Measurement (IWSM), pages 337–352, 2005.

[4] Allan J Albrecht. Measuring application development productivity. In1st IBM Application Development Symposium, pages 83–92, 1979.

[5] CT Bailey and WL Dingee. A software study using halstead metrics.In ACM Workshop/Symposium on Measurement and Evaluation ofSoftware Quality, pages 189–197, 1981.

[6] James M Bieman and Byung-Kyoo Kang. Cohesion and reuse in anobject-oriented system. In Symposium on Software Reusability (SSR),pages 259–262, 1995.

[7] CCCC. Software metrics investigation. http://cccc.sourceforge.net/,2015.

[8] Prachi Chhabra and Lalit Bansal. An effective implementation of im-proved halstead metrics for software parameters analysis. InternationalJournal of Computer Science and Mobile Computing, 3(8):146–161,2014.

[9] Shyam R Chidamber and Chris F Kemerer. A metrics suite forobject oriented design. IEEE Transactions on software engineering,20(6):476–493, 1994.

[10] Eudes de Castro Lima. Uma análise dos valores de referência dealgumas medidas de software. Master’s thesis, Universidade Federalde Lavras, 2014.

[11] Gui Gui and Paul D Scott. New coupling and cohesion metrics forevaluation of software component reusability. In 9th InternationalConference for Young Computer Scientists (ICYCS), pages 1181–1186,2008.

[12] Maurice H Halstead et al. Elements of Software Science. Elsevier, NewYork, NY, USA, 1977.

[13] Sallie Henry and Dennis Kafura. Software structure metrics basedon information flow. IEEE transactions on Software Engineering,7(5):510–518, 1981.

[14] Yoshiki Higo, Shinsuke Matsumoto, Shinji Kusumoto, Takashi Fuji-nami, and Takashi Hoshino. Correlation analysis between code clonemetrics and project data on the same specification projects. In 12thInternational Workshop on Software Clones (IWSC), pages 37–43, 2018.

[15] Howard A. Jensen and K Vairavan. An experimental study of soft-ware metrics for real-time software. IEEE Transactions on SoftwareEngineering, 11(2):231–234, 1985.

[16] Mark Lorenz and Jeff Kidd. Object-oriented software metrics. PrenticeHall, Englewood Cliffs, NJ, USA, 1994.

[17] M Madhan, I Dhivakar, T Anbuarasan, and Chandrasegar Thirumalai.Analyzing complexity nature inspired optimization algorithms usinghalstead metrics. In International Conference on Trends in Electronicsand Informatics (ICOEI), pages 1077–1081, 2017.

[18] Md Abdullah Al Mamun, Christian Berger, and Jörgen Hansson.Correlations of software code metrics: an empirical study. In 27thInternational Workshop on Software Measurement and 12th Internatio-nal Conference on Software Process and Product Measurement (IWSMMensura), pages 255–266, 2017.

[19] McCabe. McCabe IQ metrics. http://www.mccabe.com/pdf/McCabe IQ Metrics.pdf, 2015.

[20] Thomas J McCabe. A complexity measure. IEEE Transactions onsoftware Engineering, 2(4):308–320, 1976.

[21] Jesús Moreno-León, Gregorio Robles, and Marcos Román-González.Comparing computational thinking development assessment scores withsoftware complexity metrics. In Global Engineering Education Confe-rence (EDUCON), pages 1040–1045, 2016.

[22] Standards Coordinating Committee of the IEEE Computer Society.IEEE standard glossary of software engineering terminology. IEEEStd 610.12, 1990.

[23] Vincent Yun Shen, Samuel D. Conte, and Hubert E. Dunsmore. Soft-ware science revisited: A critical analysis of the theory and its empiricalsupport. IEEE Transactions on Software Engineering, 9(2):155–165,1983.

[24] Charles P Smith. A software science analysis of programming size. InACM 1980 annual conference, pages 179–185, 1980.

[25] Ian Sommerville. Engenharia de Software. Pearson Addison Wesley,São Paulo, SP, Brazil, 8 edition, 2007.

[26] Giancarlo Succi, Witold Pedrycz, Snezana Djokic, Paolo Zuliani, andBarbara Russo. An empirical exploration of the distributions ofthe chidamber and kemerer object-oriented metrics suite. EmpiricalSoftware Engineering, 10(1):81–104, 2005.

[27] Ewan Tempero, Craig Anslow, Jens Dietrich, Ted Han, Jing Li, MarkusLumpe, Hayden Melton, and James Noble. The Qualitas Corpus: Acurated collection of Java code for empirical studies. In 17th Asia

Pacific Software Engineering Conference (APSEC), pages 336–345,2010.

[28] Antonio Terceiro, Joenio Costa, João Miranda, Paulo Meirelles,Luiz Romário Rios, Lucianna Almeida, Christina Chavez, and FabioKon. Analizo: an extensible multi-language source code analysis andvisualization toolkit. In Brazilian conference on software: theory andpractice (Tools Session), pages 1–6, 2010.

[29] Ricardo Terra, Luis Fernando Miranda, Marco Tulio Valente, andRoberto S. Bigonha. Qualitas.class Corpus: A compiled version of theQualitas Corpus. Software Engineering Notes, 38(5):1–4, 2013.

[30] Hironori Washizaki, Hirokazu Yamamoto, and Yoshiaki Fukazawa. Ametrics suite for measuring reusability of software components. In 9thInternational Software Metrics Symposium, pages 211–223, 2003.

[31] Horst Zuse. Resolving the mysteries of the Halstead measures. Te-chnische Universität Berlin, Fakultät IV-Elektrotechnik und Informatik,2005.